session cookies verwijderen

Marlies Maalderink op 15/02/2017 17:01:02

Als ik een sessie verwijder met session_destroy(); dan wordt de session cookie helemaal leeg gemaakt, maar het bestandje zelf blijft wel staan. Hoort dat zo?

Ja, dat hoort zo. Het bespaart namelijk heel wat uitstapjes naar het bestandssysteem. Er wordt niet aan de lopende band steeds maar één sessiebestand gewist, maar in één keer een heleboel sessiebestanden.

De kans dat deze garbage collector wordt geactiveerd, kun je regelen met session.gc_probability en session.gc_divisor in php.ini. De kans is daarbij gelijk aan session.gc_probability / session.gc_divisor.

Waarom zou je een session map de rechten geven om te lezen/schrijven/en UITVOEREN?
Is dat niet teveel van het goede?

Als www-data er in kan schrijven en lezen is dat voldoende.
Ook vraag ik me af of session_destroy() ook niet te veel van het goede is?
Kan je niet beter het onderdeel van de session wat niet meer nodig is unsetten?

Ward, dank je voor de uitleg! Dat moet je ook maar net weten zeg!

Bart, ja, misschien is dat idd wel wat veel van het goede. Had het nu klakkeloos overgenomen omdat mijn hostingprovider aangeeft dat je het zo moet doen. Vraag me wel af waarom ze dat dan zeggen.

Wat betreft session_destroy(), is dat niet een normaal onderdeel van uitloggen? In de praktijk zal dat trouwens niet eens zo heel veel voorkomen, maar het lijkt mij logischer om een log uit af te sluiten met een session_destroy(). Of zijn er goede redenen om dat niet te doen?

Nou, dan is de hostingprovider wel erg enthousiast met advies geven.
Chmodden naar 777 werkt inderdaad altijd, maar technisch gezien laat je nu een iedereen en dan bedoel ik de goede, maar ook de slechte lezen, schrijven, en uitvoeren.
Op zich is lezen en schrijven (heel voorzichtig gezegd) niet zo heel erg. Maar uitvoeren is een potentieel gevaar. Daarmee kan je hele stoute dingetjes doen. En dat zou ik als zowel gebruiker, als provider toch minder vinden als ik zomaar van alles mag doen op een server.

Dus wat ik zou doen is chown www-data:en_jou_gebruiker /var/www/html/weet_ik_niet_welkemap/sessions/

Wat betreft session_destroy(), dat het een hele normale actie is, en vrijwel overal op het net gebeiteld staat klopt. Maar als je wat verder er over nadenkt is het net zoiets als een mug met een kanon proberen af te schieten. Ik weet natuurlijk niet wat voor applicatie dat je aan het schrijven bent, maar ik zou me zomaar kunnen voorstellen bij een webshop bijvoorbeeld dat je een $_SESSION['ingelogd'] aanmaakt om bestellingen in te zien, maar in die zelfde session_start() kan bijvoorbeeld ook een $_SESSION['bewaar_winkelwagen'] of $_SESSION['favoriet'] in zitten. Met session_destroy() schiet je dus ook met dat zelfde kanon de rest van de bewaarde waardes in je $_SESSION af.
Dus waarom zou je de als je alleen het inloggen wilt opheffen alles weggooien?

Toegeven, ik gebruik voor enkel inloggen en uitloggen het ook session_destroy(), maar zou ik wat meer opties hebben dan doe ik dat niet.

Ik beheer een site waar sessiebestanden inderdaad een probleem waren. Dat was niet omdat ze niet werden verwijderd (want dat gaat gewoon automatisch), maar omdat ik er een megabyte aan tijdelijke data in opsla. Slaat de garbage collector niet tijdig aan, dan loopt zo'n site vast op onvoldoende schijfruimte.

De oplossing is niet alleen session_destroy() aanroepen, maar éérst niets opslaan in het sessiebestand door $_SESSION op een lege array in te stellen. Bijvoorbeeld uitloggen bestaat dan uit drie stappen:

<?php
$_SESSION = array();
if (ini_get('session.use_cookies')) {
    $cookie_params = session_get_cookie_params();
    setcookie(session_name(), '', time() - 42000, $cookie_params['path'], $cookie_params['domain'], $cookie_params['secure'], $cookie_params['httponly']);
}
session_destroy();
?>

Bart, ik ga het inderdaad even aanpassen. De hele boel staat wel buiten de root folder maar als het niet nodig is dan is het een beetje onzin om die map op 777 te zetten.

In dit geval gaat het alleen om in en uitloggen.

Ward, dan telt het inderdaad snel op. Maar als je een session_destroy() doet, wordt hij dan ook niet leeg gemaakt? (als ik een session cookie bekijk van een session die ik heb ge-destroyed, dan staat er ook niets meer in namelijk...) Of is er dan nog verborgen data of maakt hij hem niet altijd leeg?

session_destroy() zorgt er denk ik effectief voor dat je niet meer naar het sessie-bestand (niet te verwarren met $_SESSION) kunt schrijven totdat je session_start() opnieuw aanroept. Het eerst leegmaken en vervolgens uitzetten van de wegschrijfmogelijkheid zijn dus stappen die garanderen dat een sessie leeg is en leeg blijft tijdens het afbouwen hiervan.

Indien het gaat om uitloggen, wat een "state change" is, loont het misschien ook de moeite om:
- het sessie-id te verversen met session_regenerate_id()
- direct na dit alles de pagina te verversen met header('Location: xyz') gevolgd door een exit-statement zodat de nieuwe toestand ook meteen van kracht is

Ok, duidelijk, dank je wel voor de uitleg.

Thomas van den Heuvel op 16/02/2017 10:20:15

Indien het gaat om uitloggen, wat een "state change" is, loont het misschien ook de moeite om:
- het sessie-id te verversen met session_regenerate_id()
- direct na dit alles de pagina te verversen met header('Location: xyz') gevolgd door een exit-statement zodat de nieuwe toestand ook meteen van kracht is

Dat laatste doe ik al. Wat betreft het eerste, op welke plek de je dat? Na het leegmaken van de session maar voor session_destroy? Klopt het dat je dan dit krijgt?

<?php
public function uitloggen() {
		
	$this->lifetime = -4200;
	$_SESSION = array();
		
	$cookie_params = session_get_cookie_params();
    	session_set_cookie_params( $this->lifetime, $cookie_params[ 'path' ], $cookie_params[ 'domain' ], $cookie_params[ 'secure' ], $cookie_params[ 'httponly' ] );
	session_regenerate_id(true);

        session_destroy();
		
	}
?>

Goede vraag, geen idee wat een goede plek is :). De sessie is in principe toch leeg + onschadelijk gemaakt.

Maar als je dit (aanroep van session_regenerate_id()) op zijn minst bij het inloggen doet (ook een state change) is dat misschien al wel genoeg.

Ik doe het bij inloggen en dan nog in 10% van de gevallen bij het aanroepen van session_start();

Dus in principe wordt het session_id regelmatig geregenereerd. Het lijkt overigens prima te werken zoals het hierboven staat, alleen betwijfel ik of session_regenerate_id hier uberhaupt iets toevoegd of er een beetje voor niets tussen staat.