Chamilo LMS
vr, 09/26/2025 - 04:04

Sessiebeheer in PHP

Sessies in PHP

Sessies in PHP worden beheerd door verschillende elementen die samen kunnen werken of met elkaar in conflict kunnen komen.

Alle onderstaande PHP-instellingen kunnen worden geconfigureerd in php.ini, in de vhost (als je modPHP van Apache gebruikt) of in .htaccess (als .htaccess-bestanden zijn toegestaan).

Algemene uitleg

Wanneer we een PHP-site in een browser laden, start de site standaard een sessie. Dat is een klein opslaggebied voor informatie over onszelf dat kan worden hergebruikt op de volgende pagina's. Dit stelt de server in staat ons “te onthouden”. Zo hoeft een pagina bijvoorbeeld niet telkens te vragen wie we zijn via een gebruikersnaam en wachtwoord.

Aan de serverzijde worden deze waarden opgeslagen (meestal in een apart bestand per gebruikerssessie). Om de browser te herkennen die eerder een pagina heeft bezocht, slaat de server een sessienummer op in de browser via een cookie. Een cookie is ook een manier om informatie in de browser op te slaan, maar om veiligheids- en privacyredenen worden er meestal alleen korte en niet-persoonlijke gegevens in bewaard, zoals een sessienummer.

Het cookie wordt vervolgens gebruikt voor elke aanvraag naar dezelfde site (URL): de browser stuurt het cookie automatisch mee bij het bezoeken van andere pagina’s van de site, en de server leest het cookie met de juiste sessienaam, vindt het bijbehorende bestand op de schijf en laadt het in het geheugen voordat de PHP-code verder wordt uitgevoerd.

Dit mechanisme is niet uniek voor PHP; elk programmeertaal beheert dit op zijn eigen manier.

In PHP kunnen we variaties van het sessiebeheermechanisme instellen via serverconfiguraties. Zo kan bijvoorbeeld worden gekozen om sessies op een Redis-server op te slaan (handig bij meerdere webservers zodat elke gebruiker een uniforme ervaring heeft, ongeacht welke server zijn verzoek verwerkt).

Standaard slaat PHP sessies op in een map (meestal /var/lib/php/sessions op Linux) en geeft ze een levensduur van 24 minuten (1440 seconden, omdat parameters in seconden worden opgeslagen).

Bij elk gebruik van deze sessie (bijvoorbeeld bij het laden van een pagina) wordt de teller bijgewerkt zodat de sessie opnieuw 24 minuten geldig blijft.

Aan de cliëntzijde

Als er gedurende 24 minuten geen activiteit is (bijvoorbeeld geen pagina wordt geladen), verloopt het cookie (dat oorspronkelijk 24 minuten geldig was) en stuurt de browser het niet meer naar de server bij een nieuw verzoek. We zeggen dan dat de sessie is verlopen, en de site zal de gebruiker waarschijnlijk opnieuw laten inloggen.

Aan de serverzijde

Het is vergelijkbaar aan de serverzijde en dient als voorzorgsmaatregel: de server beschouwt alle sessiebestanden die de laatste 24 minuten niet zijn aangeraakt (gelezen of gewijzigd) als verlopen.

Belangrijk: de bestanden worden niet automatisch verwijderd na 24 minuten. Dit hangt af van het aantal bezoeken en van de kans dat de garbage collector (GC) wordt gestart, een proces dat bij elk nieuw bezoek aan de site kan worden uitgevoerd. De volgende instellingen bepalen dit mechanisme:

  • session.gc_probability
    Bepaalt de kans (in procent) dat de garbage collector wordt uitgevoerd bij elk verzoek. Standaard is dit 1. Moet ≥ 0 zijn.

  • session.gc_divisor
    Wordt samen met gc_probability gebruikt om de kans te berekenen dat de garbage collector wordt gestart. Bijvoorbeeld 1/100 betekent 1% kans per verzoek. Standaard is 100.

  • session.gc_maxlifetime
    Geeft de levensduur van sessiegegevens op de server in seconden. Na deze periode worden gegevens als verouderd beschouwd en kunnen ze worden verwijderd door de garbage collector. Standaard is 1440 seconden (24 minuten).

  • session.save_path
    Bepaalt waar sessiebestanden op de server worden opgeslagen. Als je hierbij het aantal submappen gebruikt (bijv. "2;/tmp"), wordt de standaard garbage collector niet uitgevoerd.

Aan de cliëntzijde

  • session.cookie_lifetime
    Bepaalt de vervaltijd van het cookie dat de sessie identificeert. Kan op "0" worden gezet, zodat het cookie vervalt bij het sluiten van het browservenster of tabblad.

Goede praktijk

Ideaal gezien moeten session.cookie_lifetime en session.gc_maxlifetime dezelfde waarde hebben, of kan gc_maxlifetime een specifieke waarde krijgen als cookie_lifetime op 0 staat (zodat het sluiten van het venster het cookie verwijdert, maar de server nog een extra veiligheidsmaatregel kan hebben).

De keerzijde van cookies

Dit mechanisme werkt al tientallen jaren goed, maar er zijn enkele aandachtspunten:

  • Cookies worden aan de clientzijde opgeslagen en kunnen gemakkelijk worden aangepast. Sessies moeten daarom moeilijk te raden zijn (lange, complexe tekenreeksen).

  • Cookies kunnen worden gelezen of gewijzigd via JavaScript of browserextensies, of door een hack (XSS/CSRF). Sommige sites controleren de authenticiteit van cookiegegevens om ongewenste wijzigingen te voorkomen.

  • Cookies worden bij elk verzoek meegestuurd. Om session hijacking te voorkomen, is HTTPS-encryptie noodzakelijk.

  • Vermijd het opslaan van grote hoeveelheden gegevens in cookies; gebruik de server voor opslag om dataverkeer te beperken en de site sneller te laten laden.

Commercieel advies

Hoewel we gespecialiseerd zijn in open-source e-learning, zijn we eerst webtechnologie-experts. BeezNest kan complexe problemen oplossen op het gebied van beveiliging en optimalisatie van sites.

Contacteer ons via het webformulier.