3 ms·
You'll find that the isolation goes out of the window when you need sessions; they need to be stored somewhere that persists across requests.
by JulianMorrison 5y ago
You'll find that the isolation goes out of the window when you need sessions; they need to be stored somewhere that persists across requests.
- laurencerowe 5y agoWhere sessions are too large to store in signed cookies (which should usually be preferred when possible since they require no extra infrastructure and avoid any risk of session data mixups) they normally end up in some kind of database or memcache since you likely want to support multiple processes. It's much less likely you'll lookup the wrong user's session than accidentally store some user data in a module or closure variable shared between requests which may come from different users.
- JulianMorrison 5y agoThat is literally what session hijacking is. A uses the session created for B, various ways. Do not store sessions in signed cookies, because those can be stolen, and they bloat your requests and responses shipping all the data up and down each time. Store sessions in a database, tie them to an IP, and time them out. Transmit only an opaque ID. Ideally, re-create a different ID with each new request. If you are using a web framework, it should have tried and tested mechanisms to do all this for you. This is the kind of thing you lose cooking your own CGI.