Session Timeout

Data & reporting
41

I can understand your reasoning Stephen but it is not alarmist.

IT people deal with the unaware and/or the so called dumb user every day. We try to put in place systems that will cope with every eventuality and that is not easy. Identity is a big thing these days and it was only testing that found out we had this issue - a heads up would have been nice especially considering this has been discussed (and once fixed) since 2016.

My hope was that I had missed something or something was mis configured but I now know that it is working as designed. We will look at external ways around this and document it for our users and hopefully at some point in the future others will add pressure to have this problem addressed within Discourse.

42

But what if the user forgets to close the browser? How does that work?

I am curious though @falco why was the 2016 patch reverted? Is it an unsafe change?

43

Some fair points.

Iā€™m rather shocked by a couple of your examples, though:

Hospitals: The ones Iā€™ve been in in the last few years most certainly do have unique lockouts, to the point that the nurse thatā€™s running bloodwork has to log in again after stepping away for a couple of seconds.

In ER, there may be some specialized systems that have access to emergency-relevant data, but they shouldnā€™t have access to PII, or to the department chat forum.

Library:
All of my local public libraries (Including some very small towns/non-tech-savy personnel) have a generic login ID. (Same for all patrons, posted right on the monitor) They also have a Restart-on-walkaway policy, and everyone, including the kids, is expected to comply. The restart sequence includes automatically clearing browser history/cache/cookies.

Not saying that a more careful policy on the discourse side would be a bad thing, itā€™s just that some of the ā€œincitingā€ situations listed in this topic alarm me because mis-attributed forum posts are the least of their problems.

1 Like
44

Timeline is:

  • 2012 - May 2016: Discourse session cookie is always set to forever

  • May 2016 - July 2016: Discourse session cookie is set to forever by default, site setting can make it go away on browser close.

  • July 2016 - Today: Discourse session cookie is set to 1440 hours, refreshes on use. Site setting can control max life time. Browser session cookie setting removed.

It was mostly removed because

I can understand that sharing computers with strangers is a really alien concept in some parts of the world, more even so with mobile personal devices and now COVID-19, but it is really common for some places like school libraries, workplaces, etc.

Most of the time what they do is to turn off the computer after using it. Turning off the computer will close the browser, so turning off a computer will indirectly end logged-in session in the web apps.

When the next employee comes for the next shift the computer is started again and the browser will not contain the more session based cookies.

1 Like
45

Right but I also think setting this to a value like 0 should possibly (if it doesnā€™t cause too many support issues, or is too technically difficult) do the ā€œcookie only works for duration of browser sessionā€ behavior. So the description of the site setting could indicate that.

maximum session age [default 1440 hours]

User will remain logged in for n hours since last visit. When set to 0, user will be logged out when the browser is closed.

3 Likes
46

Hospitals: I only share what I know is done through experience. I agree screens lock quickly, but thatā€™s not a logout of the browser, much less the OSā€™s user. Can you imagine what people would do if the computer had to login, apply policies, setup network connections, all before loading some application to do whatever doctors and nurses do while somebody was dying? In a similar vein, the logins are not usually username/password as much as badge plus a short PIN for the same reason. ERs, ORs, and most other rooms, still need to document patient information, so where Iā€™ve done work it has been consistent everywhere.

Library: Restart-on-logout policies exist, and are effective as long as the admins manually clean out caches for everything on the box, but Iā€™ve seen as many places do otherwise (one of many reasons I never used shared workstations, at all, ever, with my credentials). Iā€™ve seen the same unfortunate setup in hotels and Internet cafes (or coffee shops) regularly, for what itā€™s worth.

It seems odd to me that any application would default to this setting for all users in all installations. Security isnā€™t the focus of most people when they first setup computers, and itā€™s complex enough generally that itā€™s peopleā€™s full-time professions. Those who setup computers for the public should know better, but browsers have the idea of session cookies to make it easy for application developers to have sessions when when intuitive for users.

Requiring users to understand that they must manually clear a siteā€™s cookies in order to log out, when many sites will both time out session as well as kill them on browser close, seems like requiring too much of people. Not allowing the alternative at all so that a user must remember to use the specific Discourse logout link becomes an issue when users miss the link for any reason; off the top of my head:

User browses away from Discourse following a link.
User browses away from Discourse because they use the tab to go somewhere else explicitly.
User closes the tab in a hurry leaving to go to class/meeting/etc.
Browser crashes for any reason.
SSO implementer has SAML for login, but does not know the application requires explicit logout to kill the application session.

Also, two (2) months seems like a REALLY long time for a login persist. I know some other sites these days may do that, or even be longer, but users can usually control these with those ā€œPublic computerā€ checkboxes which does not apply with SSO, or maybe at all (Iā€™m not a Discourse guru).

Just more thoughts to consider.

47

I also have this problem and I donā€™t know how to solve it.

48

Thanks for this @codinghorror what would be the process and timescales for having this evaluated and implemented?

49

I donā€™t know, it depends how technically difficult the change is. @sam what are your thoughts on difficulty of what is proposed in my above post?

50

I think this would be a cool feature as well because it would allow people to know who is actually online and who is just afk.

51

We really need a new site setting here, cause this is conceptually decoupled and it would make the code hard to reason about.

Specifically we would have to add minimums here:

https://github.com/discourse/discourse/blob/468417a7162a5337fe99a4fdbea51cd51c4ad49a/app/models/user_auth_token.rb#L103-L103

And in a few other places to ensure that the code continues to work.

The setting we want is a discreet ā€œautomatically log users off when browser is closedā€ type setting.

The session length still applies even if you use session cookies (aka omit the expires)

So for example you could sayā€¦

  1. If people close laptop and then open it 3 hours later you want them logged off
  2. If people quit chrome you want the logged off

They are different concerns.

Maybe we add persistent_sessions default true? ā€œwhen set to true session is persisted when browser is closedā€. This change is a 20 minute change.

4 Likes
52

Ok if a separate site setting is better and it is an easy 20 minute change then I say letā€™s go for it.

2 Likes
53

Maybe in the future this good idea can be expanded for a ā€œper userā€ setting instead of only a ā€œper siteā€ setting?

1 Like
54

This is now done as a per site setting.

Feels to me like an admin choice really. It is a security feature. Long term we may consider an allow list of IP addresses that bypass the limitation (so for example computers in the corporate network stay logged in, computers out get auto logged out)

4 Likes
55

I think, by the nature of this request, it is a per user feature.

Some users are on their computers in their home or office and they do not need a cookie to expire; and so it should be their choice.

Other users might be those ā€œnomadsā€ in cafes on shared computers, and they would want their sessions to expire.

The nature of this feature is the security of a user account, so this setting has been typically implemented as a user setting or user checkbox when they login.

vBulletin, for example, had this feature OOTB over a decade ago, and when we logged in we simply checked a box if we ā€œthe userā€ wanted our session to persist.

The ā€œsecurityā€ is for users accounts, so this has typically been a per user setting in the past, FYI.

Update: When the user has a privileged account (admin, moderator, leader, etc) then there is also the larger issue of overall site security.

2 Likes
56

I have seen this implemented on many many sites, typical implementation is:

Keep me logged in for 30 days

[ LOGIN ]

Not sure when we will get to this, but when we do this but when we eventually get to this we will probably require a site setting to enable this. There are complications around where to even show a checkbox like this if you have social logins enabled.

5 Likes
57

Thank you everyone your help and understanding is much appreciated

1 Like
58

Thanks.

Yeah, social logins have never been ā€œour thingā€ due to behavior tracking; so my perspective is much more narrow than your much larger and complex requirement to support social.

Thanks for all your teams good work. Well done.

4 Likes
59

First of all: Thank you very much for the quick fix. I do have one question however: Would it be possible to make this into a per-user setting with a specific default, so that users can opt out through their preferences?

1 Like
60

Thatā€™s exactly what was discussed above as possible future work, due to both taking more effort and having some nasty UI design problems.

Plus, we want to let the feature be available for a bit to see if anyone finds a technical problem with how weā€™re doing it.

3 Likes