User logins are not persisted forever
Many of our customers and myself included are experiencing that we have to log in again very often.
I'm guessing this could be related to server update rollouts, in which the sessions are purged maybe? Seems like an alternative solution is needed in which the cookies/session storage data will be used instead to keep the authentications valid.
Is there a setting somewhere that we can change or is it a bug?
KajMagnus @KajMagnus2018-10-07 08:40:33.484ZIs this still happening? In the new version, released last Thursday (3 days ago), I changed the session cookie expiration time to two weeks. ...
... Previously, the session cookie's expiration time was set to int-max-value, which in Chrome Dev Tools appeared as one second before year 1970. I'm wondering if maybe an integer overflow resulted in Chrome / some-other-browser interpreting int-max-val as should-have-expired-1970.
(There's no config setting you can change.)
- CChristian Scheuer @chrscheuer
It seemed to still happen yes, but re-checking it from now. I've now logged in to my main browser (using Chrome) via Facebook on our custom domain (forum.soundflow.org) and so I'll see if it keeps working or not.
I do believe 2 weeks is probably too short though. We will have customers who have not been to the forum for maybe a month and they'll want to still be logged in. But I'm guessing all that will go away anyway once we enable the SSO, so not a big problem for us.- CChristian Scheuer @chrscheuer
This seems to work a lot better now. I think I did just hit the 2 weeks timeout a couple of days ago, which makes sense given when this was implemented and pushed out.
Note that because access tokens on major sites are stored indefinitely until the server decides to log you out, some people might think something's wrong when they get "logged out" (the tokens expiring per default after 2 weeks)
For instance, a short while ago Facebook decided to invalidate access tokens for a number of users who were logged out of their services. That definitely caught my suspicion, and correctly a little while later it turned out this was as a response to a hack of Facebook user data.
So I think you should definitely consider have the access tokens only invalidate per manual request from the server - not as a default after 2 weeks - mostly because of the signal it's sending to the users.
If you want to keep it at a fairly low setting as 2 weeks, I would recommend writing to the users that they've been logged out or that persisted logins are only valid for 2 weeks, so they won't think something's wrong.
Just my 2 cents :)- In reply tochrscheuer⬆:
KajMagnus @KajMagnus2018-11-01 10:53:47.417ZOk thanks for explaining how people can think about this. ... Now when I think about it, I too would get worried, if I had to login, suddenly, to Facebook :- P
There could be a config value, and the default can ... hmm yes like you write, maybe it should be indefinitely. And then there could be admin-getting-started instructions that tells new admin(s) that they can change this setting to something shorter, if they think that's needed, for their community.
Setting this to status Planed then (that is, I plan to add a config value).
- Progresswith handling this problem
- KajMagnus @KajMagnus2019-06-09 13:00:43.779Z
Now there's a config value, here:
(your-talkyard-server)/-/admin/settings/login: Logout idle user after minutes.