[php] sessions komen terug na destroy/unset

[ViNyL]

Volgens het voorbeeld van dit artikel: http://www.byte.nl/docs/Php-Sessies.html heb ik een session handler gemaakt die die sessies opslaat in een database.

Nou loop ik tegen wat aan wat ik niet kan verklaren. Ik heb een index.php gemaakt waar ik een nieuwe sessie laat starten stop er wat in en ik check in de database of de sessie er is (juiste session_id). So far so good.

Om dit te testen gooi ik de sessie in kwestie handmatig uit de database, en vervolgens als deze niet meer in de database voorkomt doe ik een session_destroy. Na een refresh is de sessie in eerste instantie verdwenen maar deze komt na de 2de refresh terug inclusief de inhoud die er in stond.

Ik kom verschillende dingen tegen, bijvoorbeeld dat het aan Safari ligt (wat ik ook gebruik).

[ Voor 4% gewijzigd door ViNyL op 08-08-2010 14:46 ]

[Verwijderd]

Je kunt niet verklaren dat als een client een PHPSESSID cookie meestuurt dat er een sessie wordt aangemaakt met dat id? Er wordt een lege sessie gestart als de client een request variabele meestuurt met de juiste naam.

Het zou alleen onverklaarbaar zijn als er sessies worden aangemaakt met waarden daarin die bij de client niet bekend zijn. Kijk eens goed naar welke HTTP headers over en weer gestuurd worden.

[ViNyL]

Dat zou je dus uit moeten zetten als je dat niet wilt? Want hoe verwijder je anders een sessie die je niet meer wil?

Ik clear zelfs de inhoud en toch komen ze terug..

[Verwijderd]

$_SESSION = array ();
setcookie ( session_name (), null, time () - 86400, ... );
session_destroy ();

Dit vernietigt een sessie volledig. In de rest van de code is $_SESSION niet meer gevuld, de cookie wordt bij de response vernietigd (als de client daarnaar luistert), en de sessiegegevens worden uit de store verwijderd (bestand, database (mits goed geïmplementeerd)).

Als hierna nog steeds rare dingen gebeuren moet je echt de HTTP headers eens onder de loep nemen.

[gertvdijk]

Doe je de session_destroy() wel vòòrdat er content wordt gestuurd? Dus voordat je ook maar een karakter output naar de browser moet je dit in het script hebben. Er kunnen niet nog headers verstuurd worden nadat je content (en dus al headers) naar de browser hebt gestuurd.

Hmm in dat voorbeeld wat je aanhaalde wordt het hele wiel opnieuw uitgevonden; je maakt een hele eigen session handler. Is dit echt wat je wil? Waarom voldoet die van PHP zelf niet?

[ Voor 25% gewijzigd door gertvdijk op 08-08-2010 14:13 ]

[ViNyL]

Mijn pagina ziet er als volgt uit:

index.php

PHP:

require_once('sessions.inc.php');
session_start();
$_SESSION['test'] = '1';
echo "session_id = ".session_id()."<br/>";
echo "<a href='logout.php'>logout</a>";

de logout.php

PHP:

require_once('sessions.inc.php');
session_start();
$_SESSION = array();
session_destroy();

[Verwijderd]

Wat weerhoudt de client ervan om gewoon de volgende keer dezelfde PHPSESSID mee te sturen?

[ViNyL]

Hmm niets? Omdat de headers nog dezelfde informatie hebben?

[Voutloos]

De Session class bij de link die je gaf doet helemaal niets in de destroy() method en met close() doet hij ongerelateerd opruimwerk. Dat had je ook wel gezien als je de werking van die class uitgezocht zou hebben...

[ViNyL]

Voutloos schreef op zondag 08 augustus 2010 @ 14:43:
De Session class bij de link die je gaf doet helemaal niets in de destroy() method en met close() doet hij ongerelateerd opruimwerk. Dat had je ook wel gezien als je de werking van die class uitgezocht zou hebben...

Dat is mijn fout het artikel staat hier: http://www.byte.nl/docs/Php-Sessies.html. De destroy en close functies daar in doen wel degelijk wat, dus dat is het probleem niet.

Ook al werkt het zoals het moet, hoe kun je dan iemand toch bijvoorbeeld uitloggen en de sessie data vernietigen? Stel ik zet in die sessie een variable die aangeeft dat je bent in gelogd, als ik die destroy maar hij komt gewoon terug, dan kun je toch niet uitloggen?

[ Voor 30% gewijzigd door ViNyL op 08-08-2010 14:48 ]

[Voutloos]

Ok, die doet al iets meer. Dan hoef je enkel de cookie tip van Cheatah op te volgen en klaar is ViNyL.

[ViNyL]

Ok, dat is dus de truc, om ook die cookie leeg te maken.

Wordt dit met de session handler van PHP altijd gedaan zodra je een session_destroy doet?

[ Voor 45% gewijzigd door ViNyL op 08-08-2010 14:51 ]

[Voutloos]

Test het eens. Bijvoorbeeld met de Firebug addon van Firefox. Als je er nog niet eerder mee gewerkt heb kost het je misschien wel 5 minuten van je eigen tijd, maar die zijn wel bijzonder leerzaam.

[ViNyL]

Als ik naar de headers kijk zie ik dit op mijn logout pagina:

code:

Set-Cookie: PHPSESSID=deleted; expires=Sat, 08-Aug-2009 13:13:55 GMT

Ga ik dan terug naar mijn index.php en ververs, dan komt alles gewoon terug. Andere cookies zie ik niet langs komen. Dit is zowel met als zonder custom session handler.

Ik zou verwachten dat er dan een nieuw sessie id gemaakt wordt ipv dat de oude weer terug komt inclusief de inhoud, of moet ik op de inlog pagina dan altijd session_regenerate_id() gebruiken en oude sessies opruimen?

[ Voor 10% gewijzigd door ViNyL op 08-08-2010 15:23 ]

[Borizz]

ViNyL schreef op zondag 08 augustus 2010 @ 14:50:
Ok, dat is dus de truc, om ook die cookie leeg te maken.

Wordt dit met de session handler van PHP altijd gedaan zodra je een session_destroy doet?

Kijk eens in de PHP manual zou ik zeggen. Daar staat haarfijn uitgelegd wat session_destroy doet. Maar ook wat je zelf moet doen:

In order to kill the session altogether, like to log the user out, the session id must also be unset. If a cookie is used to propagate the session id (default behavior), then the session cookie must be deleted. setcookie() may be used for that.

Er staat zelfs een voorbeeld bij dat je probleem oplost.

[ViNyL]

Dat had ik inderdaad moeten kunnen vinden. Ik had hetzelfde gedaan n.a.v. Cheetah's opmerking, maar daar had ik een foutje in zitten. Dit lost inderdaad het sessie probleem op!

Dank voor de hulp, volgende toch iets beter lezen!