Cookie should expire immediately when session is destroyed
See original GitHub issueI believe that the session cookie should be forced to immediately expire when the session is destroyed (i.e. when the user logs out) on the server-side.
While the Session Store I am using is correctly handling this such that a subsequent request from the same client would create a new cookie/session, having the existing cookie for the now-destroyed session be forcibly expired keeps things much cleaner and clearer on the client-side.
Doing so also avoids wasting some bytes on the network bandwidth of every outgoing request from the client by not including the irrelevant cookie. If the session has been destroyed but the cookie’s normal expiration date has not yet been reached, this can contribute an undesirable amount of unnecessary upload bytes incurred from the client’s outgoing requests due to always being required to include that irrelevant cookie in the Cookie
header until it naturally expires.
When combined with my changes in PR #240 to fix the interaction between rolling: true
and saveUnitialized: false
, fixing this would keep things significantly cleaner on the client-side.
Issue Analytics
- State:
- Created 8 years ago
- Reactions:12
- Comments:25 (16 by maintainers)
Top GitHub Comments
What is the state of this PR? I’d love to see a express-session version where this works, as we are experiencing quite some database requests with session IDs from expired sessions.
The hacks mentioned above do not apply for us, because sessions can expire at any point without the user hitting logout (e.g. user being locked, etc.), so an automatic cookie cleanup mechanism would be very helpful here.
Looking forward to this. Right now, I manually delete the client’s cookie on logout like this:
appName
is equal to thename
option ofexpress-session
. Maybe there’s a more elegant way than going through theCookie
constructor.