Tildele $PHPSESSID en værdi

Gem $PHPSESSID i en sessioncookie før at at du forlader dit eget site. Når du returnere til dit eget site, fra betalingsstedet, aflæser du værdien... ikke ind i $PHPSESSID, men i stedet for ind i en anden variabel $minPHPSESSID. Hver gang at du skal bruge værdien fra $PHPSESSID, starter du først med at kigge i $minPHPSESSID og kun hvis den er tom så prøver du med værdien i $PHPSESSID.

Jeg er ikke helt sikker på jeg forstår det korrekt, men lad mig prøve alligevel.

Hvis du vil have din session med over på betalingsserveren så er det et no-go, da en session altid (ok der findes tilfælde med ude af process håndtering i eksempelvis ASP.NET) er bundet til serveren og ikke kan flyttes. Med andre ord giver det ikke mening at sende et session-id til en anden server end den som har skabt dette id.

Hvis det du mener er at du mister session-id fordi du har været forbi den anden server så vil jeg anbefale dig at du sørger for at dine sessions bliver håndteret med cookies (sæt session.use_only_cookies http://baheyeldin.com/drupal/how-to-get-rid-of-phpsessid-in-drupal-and-other-php-applications.html). Disse skrives således at de kan hentes af serveren (domænet) hvorfra de blev skrevet, det vil sige at du godt kan forlade en side, så længe som session-timeout er sat, og stadigvæk vende tilbage til samme server med din session intakt.

Ellers læs http://dk2.php.net/ref.session om ikke andet.

Mange betalings-gateways har i øvrigt en mulighed for at du kan sende noget med, som et hidden-felt, og som de så returnere til dig ved deres callback. Dette kunne f.eks. være ordrenummeret, eller det kunne være dit $PHPSESSID. Grunden til denne fecilitet er at der jo som regel skal laves noget mere i din ende når det er konstateret at betalingen er blevet godkendt.

Tak for jeres inputs. Jeg HAR mulighed for at medsende hidden variables, og gør det også. Når der returneres, skrives de ind i url'en, og jeg kan på den måde få fat i mit session_id. Det er bare de to ting jeg skal have parret med hinanden - $_GET[sid] og $PHPSESSID

Umiddelbart ser dit forslag, nielle, ud til at kunne virke. Og så burde det jo være lige til. Det kunne virke. Det eneste er bare, at jeg så skal lave alle mine queries om, hvor der indgår en WHERE sessionid = '$PHPSESSID' i forespørgslen. Kunne man nu registrere $PHPSESSID til at være det sessionid der blev brugt før, var det selvfølgelig nemmere.

Du bliver nok nødt til at omskrive noget af dit SQL.

Når du nu er i gang med det, så bør du vide at det er en meget dårlig ide at bruge session-id som primary key i en tabel! Den er nemlig ikke garanteret til at være unik, og det kan sagtens ske at den går igen senere. Den er velegnet til at skelne mellem unikke brugere her og nu, men ikke over meget lang tid.

Når det så er sagt så synes jeg at du simpelthen skal lave en funktion som indkapsler funktionaliteten med at hente fra den ene og derefter muligvis fra den anden:

function GetPHPSESSID()
{
    return (isset($minPHPSESSID)) ? $minPHPSESSID : $PHPSESSID;
}

- og så simpelthen bruge den i dine SQL-kald i stedet for $PHPSESSID;

Jeg bruger ikke session_id som primary key. Det er bare som ekstra felt, for at tjekke ekstra godt. Sådan var det i hvert fald tænkt....

Jeg er ikke helt med på linien
return (isset($minPHPSESSID)) ? $minPHPSESSID : $PHPSESSID;

Kan du eventuelt oversætte den til "dansk". Skal det sættes ind i toppen af siden eller hvad?

GetPHPSESSID() er en funktion du selv definere. Du må selvom hvor på siden du vil placere den, men jeg ville personligt placere den i en php-fil som jeg includede på de sider hvor jeg havde brug for funktionen.

Alle dine SQL-kald rettes så fra noget med:

... WHERE sessionid = '$PHPSESSID' ...

- til noget med:

... WHERE sessionid = '" . GetPHPSESSID() . "' ...

Hvis det er selve kodestumpen:

return (isset($minPHPSESSID)) ? $minPHPSESSID : $PHPSESSID;

- du ikke kan gennemskue, så er forklaringen at:

return (isset($minPHPSESSID)) ? $minPHPSESSID : $PHPSESSID;

- simpelhen er en genvej for at skrive:

$returnValue = "";
if (isset($minPHPSESSID)) {
    $returnValue = $minPHPSESSID;
} else {
    $returnValue = $PHPSESSID;
}
return $returnValue;

Hvis du ikke på forhånd kendte til ?:-operatoren så er det en meget god ide at lære den at kende - den er ekstremt brugbar.

Ja det giver selvfølgelig mening at include der hvor den skal bruges, men jeg var bare i tvivl om det SKULLE være i toppen... Det er der styr på nu :-)

? kender jeg ikke, og brugen af return kender jeg heller ikke, men det kan jeg finde på php.net... Der er mange ting i PHP og hvis ikke man ved at noget findes, så søger man jo heller ikke efter det. Det er derfor eksperten og lignende fora er fede :-)

Hvor kan jeg læse mere om ?

Hvis du ikke kender "return" så må det jo være fordi at du ikke har prøvet at lave funktioner før - det er da i hvertfald er meget godt sted at starte idet det vil betyde en hel del for din produktivitet:

http://us2.php.net/manual/en/function.return.php

BTW Operatoren hedder ikke "?" men "?:". Du kan læse lidt mere om den her:

http://php.codenewbie.com/articles/php/1480/The_Ternary_Operator-Page_1.html

Det vil jeg kigge lidt nærmere på :-)

Vil det ikke sige, at når jeg skal lave ovenstående script, så skal jeg et eller andet sted sætte $minPHPSESSID (som jeg kalder $sid)?

Min kode tjekker i øjeblikket følgende:
if(($_GET[menu] == 'kortbetaling') AND (isset($_GET[side]))) {
  $q_foresp = mysql_query("SELECT * FROM bla bla bla WHERE sessionid = '$_GET[sid]'");
} else {
  $q_foresp = mysql_query("SELECT * FROM bla bla bla WHERE sessionid = '$PHPSESSID");
}

Jeg kan ikke lige gennemskue hvad jeg skal skrive funktionen om til, for den funktion du laver, skal kun bruges, når jeg er på $_GET[menu] == 'kortbetaling'

Den variabel du kalder $minPHPSESSID er det samme som min $_GET[sid] ikke?

Jeg har lige arbejdet lidt med det du foreslog ovenfor, med at tjekke efter den ene session eller den anden. Jeg støder på et problem, hvis man i bestillingsprocessen - hvor man ER kommet over på serveren med SSL - klikker sig væk og ind på den "normale side", fordi der så igen skiftes server. Derved mister jeg igen min session.

Hvis klienten accepterer cookies fra dit site, bør der ikke være nogen problemer i at besøge en anden server undervejs

ellers bruger du vel session_id(nyt_id); til at skifte?

Jeg bruger ikke cookies i systemet nu, og vil som udgangspunkt helst undgå det, da ikke alle ønsker at tillade brugen af cookies.

Kan det ikke klares på en anden måde?

Når du hopper mellem sites så mistes sessionen automatisk. Det er bl.a. grunden til at $PHPSESSION får en ny værdi når du vender tilbage til ”dit eget site” efter at have været over på ”det andet site”:

”dit eget site” -> ”det andet site” -> ”dit eget site”

Det er ikke noget du kan gøre noget ved.

Hvis du derfor har behov for at huske data på tværs af hver hop må du have en ordning med ”det andet site” om at hvis du sender data til dem, så sender de det tilbage. Sådan noget har du jo allerede.

Problemet er så bare at ”de andet site” jo kun sender data til dig én gang, nemlig ved deres callback. Hvis du derefter ønsker at hoppe videre rundt på dit site så har du selv ansvert for at gemme data. Dette gøres f.eks. ved at gemme dem i en session-cookie:

$_SESSION["sid"] = $_GET["sid"];

Men, hvis dette ikke er en mulighed så har du i stedet for en mulighed for at bruge cookies til at klare opgaven for dig:

http://www.phpfreaks.com/tutorials/120/1.php

Frygten for at bruge cookies er stærkt overdrevet!

Hvis du skal skifte session, skal du gøre det sådan:

$id = <hentid>
session_id($id);
session_start(); // nu benyttes den valgte session


Det med at gemme session id i en (session)cookie sker helt automatisk, det klarer serveren. Så det er ikke noget du selv skal kode. Og her vil klienten automatisk sende det rigtige id med, når du vender tilbage.

Jeg er godt med på hvad I siger. Jeg tror måske bare ikke helt, at det er det der er fejlen.

Når jeg er på siden, hvor der skal indtastes kortdetaljer, så er det på en fremmed server med SSL, og hvis jeg gennemfører betalingen, så er jeg stadig på deres side, og der er heller ingen problemer. Problemet opstår først, hvis der klikker på eksempelvis en varegruppe, eller hvis der klikkes på tilbage-knappen i browseren. Det vil sige - steder hvor der ikke bliver sendt informationer med GET eller POST.

Har jeg ikke ret I at DET er problemet?

Hvis der ikke bliver sendt informationer tilbage via GET og POST så har du *kun* cookies at falde tilbage på.

... på nær et lille alternativ, nemlig at forsøge at genkende brugere ud fra hans IP adresse.

Hmmmm.....

ip'en er vel for usikker, er den ikke? Alle der løbende kalder op til min shop fra samme computer på den samme skole (eller lignende), vil have samme ipadresse, er det ikke rigtigt?

Det kan godt være at min frygt for brug af cookies er overvurderet. Jeg har bare hele tiden søgt henimod at holde HELE siden serverside.

Det kunne jo også være, at jeg bare skulle forsøge at snakke med mit webhotel for at høre om mulighederne...

Den situation du beskriver klares sådan her:

$IP = $_SERVER("REMOTE_ADDR");
$FIP = $_SERVER("HTTP_X_FORWARDED_FOR");
if ($FIP != "") $IP = $FIP;

Damn... du kender altså til nogle ting, som i den grad får mig til at føle mig som en nybegynder...

Kan du forklare HTTP_X_FORWARDED_FOR lidt nærmere? Det er noget med at der tages højde for proxy, eller sådan noget....?

Hvis jeg bruger ipadresse til at tjekke med op i mod min varekurv-tabel, så vil jeg jo finde brugerens gamle varekurv frem, næste gang han besøger min side, ikke?

Jeg kan altså ikke få ind i mit hoved, at ip'en skulle være smart til en shoppingfunktion... Sorry :-)

Det er så småt ved at være tid til U2 koncerten, så jeg smutter.

Jeg har som bekendt ikke helt fået løst mit problem, men synes snart at I har fortjent nogle point....

Det må vi kigge på. Tak indtil videre - de har trods alt kastet et par gode fifs af sig :-)

Tingen ved IT er at der heldigvis altid er noget nyt at lære. :^)

Pointen mht. HTTP_X_FORWARDED_FOR er at brugerne jo sommetider sidder bag en proxy, eller en NAT router, og at de udadtil verdenen derfor har det samme IP-adresse. Da de requests som de sender ud jo gerne skal resulterer i et reply tilbage, er de derfor også nødt til at medsende deres lokale IP. I de tilfælde finder man det globale IP via REMOTE_ADDR og det lokale IP via  HTTP_X_FORWARDED_FOR. Tricket er derfor først at kigge efter om de har sendt et lokalt IP, og hvis de ikke har det, så at kigge videre efter om de har sendt et globalt IP.

På den måde kan man skelne brugere bag samme proxy. Men, men, men... Det lokale IP er som regel ikke vildt fedt at kende i sig selv. Det er jo bare et IP nummer inden for et af de IP-ranges man anvender til LAN's. En bedre løsning ville måske være at kombinere det globale og det lokale IP nummer i en land streng som et kunde-ID.

IP numre er ikke en god teknik til at genkende gamle kunder med. Godt nok får flere og flere et fast IP-nummer, men der er stadig mange brugere som har dynamiske numre.

Min pointer var mere at hvis en kunde sidder og surfer rundt på dit site, går til et andet site, og så kommer tilbage igen til dit site, ja så er odds meget gode for at hun ikke har fået noget nyt IP-nummer i mellemtiden. På den måde ville du derfor kunne genkende kunden. Altså med mindre at du var uheldig og kundens ISP i mellemtiden har trukket et nyt IP-nummer til kunden. Dette er dog ikke særligt sandsynligt.

Hvis kunden derimod slukker sin computer og vender tilbage dagen efter, så er der meget større chancer for at det er under et nyt IP nummer.

Hvis du spørger mig, kan HTTP_X_FORWARDED_FOR ikke benyttes til ret meget andet end statistik. Og en almindelig NAT router vil aldrig tilføje den header

ksoren> Rent faktisk er det ikke routeren som tilføjer den, men derimod webserveren som danner den. Det gør den ud fra hvad den får medsendt af oplysninger og dem er NAT routrene nødt til at medsende idet den ellers ikke ved hvor requesten skal returneres til.

serveren tilføjer intet. Det er altid klienten som tilføjer den header.

Routeren holder styr på sine klienter via en port-liste

Derfor hedder det faktisk en NApT router, hvis det er helt korrekt

Undskyld den sene tilbagemelding - der kom lige en masse i vejen.

Jeg synes I begge har nogle gode pointer, og jeg har lært en del, synes jeg faktisk. Løsningen har jeg dog klaret på en anden måde - ved at kunden gennemfører ordren, og efterfølgende indtaster sine kortdetaljer. Hvorefter der endelig registreres en ordre. På denne måde, kan jeg omgå problemet, fordi jeg afslutter EN ting på den ene server, og EN ting på den anden server. På denne måde, kan jeg skelne tingene fra hinanden.

Smid et svar begge to, og så deler jeg pointene.

Tak for hjælpen trods alt.

Det lyder da bestemt også som om det er den rigtige måde at gøre tingene på.

... og et svar :^)

Var det en ironisk kommentar eller hvad? :-)

Overhovedt ikke - det er da den måde jeg selv plejer at gøre det på. :^)

Jeg troede egentlig at det allerede var det du gjorde, og at dine problemer skyldes nogle helt bestemte omstændigheder som ikke kunne gøres anderledes i det konkrete tilfælde.

Haha - så kunne vi have snakket forbi hinanden i lang tid, hvad :-)

Cool nok. Tak for det i hvert fald - jeg fik nogle gode pointer alligevel.

Jeg syens at vi skal give ksoren lidt mere tid til at lægge et svar:

http://www.eksperten.dk/spm/637739

Ups - ja det var ikke meningen at jeg ville have givet dig alle pointene. Det skrev jeg også, så den smuttede bare. Godt du var vågen :-)

Jeg havde nok overlevet alligevel :)

Nå ja, jo jo. Men sådan skal det nu engang være.