const session = require('express-session');
const RedisStore = require('connect-redis').default;
const { createClient } = require('redis');
let redisClient = createClient({ url: 'redis://localhost:6379' });
redisClient.connect().catch(console.error);
app.use(session({
store: new RedisStore({
client: redisClient,
ttl: 30 * 24 * 60 * 60 // 30 de zile în secunde (AICI era buba, default era mult mai mic!)
}),
secret: 'secretul-nostru-foarte-sigur',
resave: false,
saveUninitialized: false,
cookie: {
secure: true,
httpOnly: true,
maxAge: 30 * 24 * 60 * 60 * 1000 // 30 de zile în milisecunde
}
}));Salutare, comunitate. Am dat peste o problemă destul de bizară săptămâna trecută pe un proiect cu vreo 12.000 de utilizatori activi. Oamenii se plângeau că sunt delogați din senin după doar câteva minute de inactivitate. Partea ciudată? În browser, cookie-ul de sesiune avea Max-Age setat corect pe 30 de zile.
Dacă ai pățit asta sau treci acum prin asta, nu ești singur. E genul de bug care te face să te îndoiești de tot ce știi despre HTTP. După vreo trei ore de debugging și câteva cafele băute pe grabă, m-am prins unde era buba. Hai să vă zic unde să căutați când cookie-ul zice una, dar serverul face alta.
Suspectul nr. 1: Server-side Session Store (Marele vinovat)
Degeaba îi spui browserului să păstreze cookie-ul connect.sid (sau cum se numește la tine) timp de o lună, dacă serverul tău uită cine e acel ID după 5 minute.
La noi, problema era la integrarea dintre Express-session și Redis. În cod, setasem cookie: { maxAge: 30 * 24 * 60 * 60 * 1000 } (adică 30 de zile). Totuși, uitasem să configurăm corect parametrul ttl (Time to Live) în Redis store client. Default-ul din librăria pe care o foloseam expira cheile din Redis mult mai repede dacă nu existau interacțiuni scrise. Practic, browserul trimitea cookie-ul valid, dar serverul se uita în Redis și zicea: "Nu știu cine ești, cheia asta nu mai există".
Suspectul nr. 2: Cluster mode fără store centralizat
Am pățit asta acum câțiva ani pe un VPS simplu. Rulam o aplicație Node.js în PM2 cu modul cluster activat pe 4 nuclee.
Dacă folosești store-ul default în memorie (MemoryStore), fiecare proces Node.js are propria lui memorie izolată. Când userul făcea primul request, nimerea pe procesul 1 (unde se crea sesiunea). La al doilea request, load balancer-ul intern din PM2 îl trimitea la procesul 2. Procesul 2 habar n-avea cine e userul, așa că îl deloga instant.
Soluția simplă: Nu folosi niciodată MemoryStore în producție. Pune un Redis sau un Postgres în spate, chiar dacă ai o singură instanță momentan. Te scapă de dureri de cap când scalezi.
Suspectul nr. 3: Sliding Expiration și Reverse Proxy-ul
Dacă ai un Nginx în față sau folosești Cloudflare, ai grijă la headerele de cache. Uneori, proxy-ul poate face cache la headerul Set-Cookie sau, din contră, să curețe headerele pe care le consideră inutile.
De asemenea, verifică dacă ai activat "sliding expiration". Asta înseamnă că sesiunea se prelungește la fiecare request. Dacă ai un script în background (un poll de notificări sau un apel de analytics la fiecare 10 secunde) care nu updatează corect timestamp-ul sesiunii, poți avea surprize.
Trade-off-ul pe care trebuie să-l accepți
Să ții sesiuni lungi pe server are un cost. Dacă ai 100k de useri și le ții sesiunile active 30 de zile în Redis, amprenta de RAM o să crească vizibil. Noi am rezolvat-o prin setarea unui TTL rezonabil în Redis de 7 zile, cu sliding expiration. Dacă userul e activ, sesiunea se tot amână. Dacă e inactiv complet timp de 24 de ore, îl dăm afară, chiar dacă acel cookie de 30 de zile încă mai e în browser. E mult mai sigur așa și din punct de vedere al securității (previi session hijacking).
Voi cum gestionați treaba asta? Mergeți pe sesiuni scurte și JWT-uri cu refresh token, sau rămâneți la clasicele sesiuni stateful în Redis?