Skip to main content ↑ ↓
Topic: Minutes to stay logged in (Read 1879 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Minutes to stay logged in

This is another feature that I'm not sure is that useful, or not really used very often.  I get why it was there at one point. 

I was thinking to drop that user option and just set it to the default of 60 mins (or whatever you have entered into the ACP for cookie length)

Looking around I don't really see that option in other software packages, just seems like form clutter at this point.

So again, does anyone use this and if so why?
 

Re: Minutes to stay logged in

Reply #1 –

Personally I dropped it in favour of an 'always stay logged in' option - no tick: log out at end of browser window/60 minutes (but not just dropping people at 60 minutes, only after some inactivity), tick: keep them logged in for at least a month and let the cookie + session renew through that time.

There are various strategies for how this might work; the default solution in SMF is awful and if you're still using it, please kill with fire. (The method they (still) use is to make a long life cookie that really is long life, a year or more IIRC, and the basis of the cookie is username + password hash, rehashed, so that the cookie supplier can be reauthenticated.)

Re: Minutes to stay logged in

Reply #2 –

I just finished removing that option in favor of only the "stay logged in".   If you don't check that then its whatever the admin set in the control panel for TTL.  At least the login form now looks normal.

Setting the "forever" sets the cookie for some very long period of time, TBH I'm not sure what that is, 1 year sounds right.  I remember in some areas it was in seconds and other minutes.

It still uses that same basic data scheme, the cookie is a hash of the hashed password + user salt.  Probably the only deltas are type of hash and salt length.  Now i'll be looking into this a bit as well.

Re: Minutes to stay logged in

Reply #3 –

So what I have is a persistence token; it contains a server-generated alphanumeric string plus the user id, generated and stored when the user logs in (if they ticked 'always stay logged in'), and I let whatever session cleanup Symfony does do its thing - so that when the user presents a session ID that isn't recognised, we can look for this persistence token and if it's still valid, repopulate the session. Naturally, all the usual keepalives will keep the session alive, and will renew the persistence token if it's getting close to expiry.

Re: Minutes to stay logged in

Reply #4 –

Quote from: Spuds – I just finished removing that option in favor of only the "stay logged in".   If you don't check that then its whatever the admin set in the control panel for TTL.  At least the login form now looks normal.

Setting the "forever" sets the cookie for some very long period of time, TBH I'm not sure what that is, 1 year sounds right.  I remember in some areas it was in seconds and other minutes.

It still uses that same basic data scheme, the cookie is a hash of the hashed password + user salt.  Probably the only deltas are type of hash and salt length.  Now i'll be looking into this a bit as well.

FWIW My log-in defaults to 240 minutes (4 hours) and my session timeouts just under that - us old guys may take a nap mid-session  :D 
(More than 4 hours, you ain't nappin any more,)
I guess the user having the option to change the default log-in time is a nice thing in theory (at least they know what it is..), but I suspect nobody exploits it if they even pay attention to it..
// Deep inside every dilemma lies a solution that involves explosives //

Re: Minutes to stay logged in

Reply #5 –

By persistence token, you mean you are creating a token/hash and then storing that in the DB under that userid, at least for forever logins?

Re: Minutes to stay logged in

Reply #6 –

Quote from: Spuds – By persistence token, you mean you are creating a token/hash and then storing that in the DB under that userid, at least for forever logins?

Yes, it’s a token attached to the user id. It doesn’t last forever but if it’s in use it will renew periodically to keep the user logged in. Once it expires, it’s gone and any further use of the token is rejected

I also intend to separate admin entirely and create full separate admin sessions rather than escalating the current session, but haven’t got to that yet.

Re: Minutes to stay logged in

Reply #8 –

That's a thing I wanted to remove since a while, so huge +1!
Actually, my idea was to rely only on the session cookie in case of not checked, but I think I never managed to understand how to do it, so I ended up never touch it. :-[

Re: Minutes to stay logged in

Reply #9 –

If you're leaving the cookie contents alone so it just submits what it currently does (which is enough to reauthenticate), you just make the duration of the cookie 0 and the browser will keep submitting it until it expires when the tab is closed. (You usually put in a negative time to force expire, e.g. -3600 is used everywhere)

It gets trickier relying on that if what you're passing as the cookie is not sufficient on its own to reauthenticate (e.g. you're just passing a token) because you have to make a decision how long you want to allow that token to live for and adjust session garbage collection appropriately because once the session is GC'd, the user is gone and that's that.