Am dat recent de o problemă destul de bizară la un proiect cu vreo 12k utilizatori activi. Teoretic, totul e simplu: cookie-ul de sesiune e configurat să expire peste 30 de zile. Practic, o parte din utilizatori sunt deconectați după doar 5-10 minute de inactivitate.
E genul de bug frustrant care nu apare la mine pe localhost, dar în producție face ravagii în tichetele de suport. Am început să sap și am zis să scriu aici pașii mei, poate vă loviți și voi de asta.
Ce am verificat deja și pare în regulă
În primul rând, m-am uitat în DevTools la tab-ul Application. Cookie-ul de sesiune are parametrul Expires/Max-Age setat corect, undeva prin luna următoare. Deci browserul nu îl șterge de capul lui.
Am bănuit că e de la server. Folosim Redis pentru stocarea sesiunilor, rulat pe un nod separat în AWS. Am intrat cu redis-cli în producție și am dat un TTL pe câteva chei de sesiune. Surpriză: cheile chiar au TTL-ul setat corect la nivel de Redis. Și totuși, după câteva minute de stat degeaba, la primul refresh userul primește redirect la login.
Suspecții principali pe care îi am în vizor
După două zile de documentat și analizat log-uri, am redus cercul de suspecți la trei scenarii posibile.
1. Politica de evicțiune din Redis (maxmemory-policy)
Asta e o capcană clasică în care am mai căzut în trecut. Dacă instanța de Redis rămâne fără memorie (de exemplu, din cauza cache-ului de baze de date care împarte aceeași instanță cu sesiunile), Redis începe să șteargă chei ca să facă loc.
Dacă politica e volatile-lru sau allkeys-lru, Redis va șterge cele mai vechi sesiuni, chiar dacă ele mai aveau 29 de zile de viață. Trade-off-ul aici e de buget: pui sesiunile și cache-ul în aceeași instanță ca să economisești vreo 15 dolari pe lună, dar riști să-ți trimiți userii la login când ai spike-uri de trafic.
2. Validarea IP-ului sau a User-Agent-ului în middleware
Multe framework-uri moderne au o opțiune de securitate care serializează IP-ul userului în payload-ul sesiunii. Dacă IP-ul se schimbă la următoarea cerere, sesiunea e considerată invalidă și e distrusă automat pentru a preveni atacurile de tip session hijacking.
La noi, infrastructura e în spatele unui Cloudflare și a unui Application Load Balancer. Dacă IP-ul real al clientului nu este trimis corect prin header-ul X-Forwarded-For (sau dacă IP-ul se schimbă des din cauza conexiunilor mobile 4G/5G ale userilor), aplicația vede o neconcordanță și dă wipe la sesiune. Am verificat config-ul de trusted proxies, dar parcă tot aici aș mai săpa puțin.
3. Session Garbage Collection în PHP
Dacă folosiți session storage-ul clasic pe fișiere (nu e cazul meu acum, dar merită menționat pentru alții), PHP are propriul mecanism de curățenie controlat de session.gc_maxlifetime.
Dacă în php.ini valoarea asta e lăsată pe default-ul de 1440 de secunde (24 de minute), PHP va șterge fișierele de sesiune de pe disc, ignorând complet ce scrie în cookie-ul userului. Pe serverele Debian și Ubuntu există chiar și un cron job separat care face curățenie în /var/lib/php/sessions și care ignoră setările din codul tău Laravel sau Symfony.
Voi cum ați rezolvat-o?
Momentan înclin spre o problemă de proxy-uri și validare de IP la nivel de middleware, fiindcă deconectările par să se întâmple mai des la cei care accesează aplicația de pe telefoane mobile în mișcare.
A mai pățit cineva asta pe infrastructură cu load balancer? Ce tool-uri de debugging ați folosit ca să prindeți momentul exact în care cheia de sesiune dispare sau este invalidată?