Questions about session expiry about lua-resty-session

[bungle]

@jgreub,

Hi, thanks for this.

1a: I agree. The session cookies in browsers have no expiry, but we store expiry in cookie value.
1b: I agree
1b: It is not correct. lifetime is used to calculate expiry that is store in cookie value. same is done for idle time (which is internally called usebefore). expiry and usebefore are thus absolute times, whereas lifetime and idle time represent duration.

The expiry is calculated as part of the signature, so you cannot just modify it.

There is caveat though with cookie storage. It means there is no way for you to invalidate valid ones on server side. You can change session secret, but that will invalidate all the existing sessions. With server side storage you can delete individual sessions, and there we also expire sessions in server side too.

2a. I think you missed that we store the expiry in cookie value, did I understand that right?
2b. You understood persistence wrong. Persistent here means that cookies are stored on disk, instead of memory. The difference between session cookies and persistent cookies is that persistent cookies have expiry. On browsers it also means that persistent cookies survive the browser process restarts whereas the session cookies don't. Persistent cookies are in many cases used to implement so called remember me functionality (or adverticing cookies).

3a. currently there is a bug with idletime that it does not work with server side storages, but it works with cookie storage. The difference is that lifetime can be say 1 hour, but idle time can be say 10 mins. The idea was to make it so that only the cookie is modified, and we don't need to update possible database (e.g. redis). But it is currently broken as it breaks signature (see: #123). So you can think this as a soft-expiry, as we just trust the browser on this. To fix it we could take idle time away from signature, but then anybody could freely modify it. Alternatively we need to calculate different checksum for that, but that will break cookie format, thus these are going to be fixed in 4.0.

3b. currently at least not tested or documented. session is expanded on usage (depending on the renew), perhaps if you set renew to 0 or -1 you may get the same effect, which means session is not renewed. I have not tested it though. Session lifetime is also expanded on save.

3c. using ssl_session_id aka binding session to ssl session id makes it really hard to steal the session cookies, but it has turned out to be cumbersome in practice (as you need to tune the mentioned directive, and I think there are other issues with that too - does it work with async js, does session id change sometimes unexpectedly etc.). While the idea in theory is nice, it is not that practical. Also there is no session ids when using session tickets. It would be better to bound session to client certificate or something like that.

If you are interested here is a list of possible enhancements that I plan for 4.0:

• add support for absolute lifetime of the session (without relying on renew)
  • session is not renewed beyond this
  • new authentication flow is required after this
• fix the idle time to work with server side session storages
  • the idle time is increased on cookie only which breaks signature verification
• allow same session cookie to be used with multiple authentication flows
  • session data needs to support "buckets" and new configuration option is needed to give name of the bucket
  • allow limiting number of buckets with LRU/LFU type of logic
• associate sessions with some arbitrary user identifier (given to lib)
  • allows implementation of n-number of active sessions per user
  • allows deletion/revoking the sessions by the specific user without affecting other users' sessions
• implement session secret rotation
  • allows rotation of session secret with fallback to old secret (for limited time)
• client certificate bound sessions?
• use more modern defaults and deprecate/remove some of the old stuff

I hope to activate on this at some point this year.

[jgreub]

Hey, thanks for responding with all this information. This information did ultimately help me accomplish my goal on the project I was working on. I think this also showed that I didn't understand all these topics clearly enough as well.

Thanks again, and since I don't have any more questions, I'll close this issue.