const session = require('express-session');
const RedisStore = require('connect-redis')(session);
app.use(session({
store: new RedisStore({
client: redisClient,
// BUG: TTL-ul în Redis e în secunde, dar unii pun din greșeală milisecunde
// 300 de secunde înseamnă exact 5 minute!
ttl: 300
}),
secret: 'super-secret-key',
cookie: {
// Aici e setat corect pe 30 de zile (în milisecunde)
maxAge: 30 * 24 * 60 * 60 * 1000
},
resave: false,
saveUninitialized: false
}));Salutare. Am dat recent peste o problemă care a mâncat vreo două zile din viața unui coleg mai junior și m-am gândit că merită documentată aici. Dacă vă sună cunoscut scenariul în care userul bifează "Remember me", cookie-ul din browser arată clar 30 de zile valabilitate, dar după exact 5 minute de inactivitate omul e trimis direct la login, citiți mai departe.
Unde e ruptura? (Hint: Nu e în browser)
Când browserul trimite cookie-ul corect la fiecare request, dar serverul zice totuși "401 Unauthorized", e clar că problema e pe backend. Am avut exact cazul ăsta la un proiect cu vreo 12k useri activi, o platformă de e-learning built pe Node.js cu Express și Redis. Clientul se plângea că studenții erau deconectați în mijlocul testelor dacă stăteau mai mult de câteva minute pe o pagină fără să dea click.
În DevTools totul arăta impecabil: cookie-ul connect.sid expira peste o lună. Și totuși, după 5 minute de inactivitate, sesiunea murea.
Suspectul 1: Redis TTL vs Cookie Max-Age
Cea mai comună greșeală este discrepanța dintre durata de viață a cookie-ului și TTL-ul (Time To Live) din baza de date de sesiuni.
Multe biblioteci (cum e connect-redis în Node sau diverse pachete în Laravel/PHP) au un TTL implicit destul de agresiv dacă nu îl configurezi explicit pe store. Degeaba îi spui browserului să țină cookie-ul 30 de zile, dacă Redis șterge cheia de sesiune după 5 minute de inactivitate. Când vine requestul cu acel session ID, serverul caută în Redis, nu găsește nimic și generează o sesiune nouă, goală.
Mai există și capcana unităților de măsură: în Express-session, cookie.maxAge se exprimă în milisecunde, în timp ce în Redis store, parametrul ttl se exprimă adesea în secunde. O simplă confuzie aici și te trezești cu sesiuni care expiră instant.
Suspectul 2: Restarturi silențioase în fundal
Dacă folosești store-ul implicit în memorie (cum e MemoryStore în Express, destinat doar pentru development), orice restart de proces șterge toate sesiunile.
Am pățit asta pe un cluster Kubernetes unde un container avea un memory leak subtil. Docker făcea restart la container cam la fiecare 5-10 minute din cauza limitelor de resurse. Userii activi își pierdeau sesiunea instantaneu, deși cookie-ul lor era perfect valid. Din perspectiva lor, era un logout complet random.
Trade-off-uri când configurezi sesiunile
Dacă muți sesiunile în Redis ca să scapi de probleme, ai grijă la setări. Redis e extrem de rapid, dar dacă nu ai persistență configurată (AOF/RDB) și se restartează nodul, ai dat log out la toată lumea deodată.
Pe de altă parte, să ții sesiunile în baza de date relațională (Postgres/MySQL) e safe și persistent, dar la 12k useri concurenți o să îți explodeze numărul de query-uri doar pentru citirea sesiunii la fiecare request. Nu merită overhead-ul pe DB pentru asta.
Voi cum gestionați sesiunile la proiectele voastre? Mergeți pe JWT-uri complet stateless (cu toate riscurile lor legate de revocare) sau tot pe bătrânul Redis cu session ID în cookie?