Does anyone know if this was ever implemented? I would like the ability to control when a userās session times out if possible.
Yep, itās there in admin:
The default is quite generous ā around two months. Iām not sure if it supports fractional values, though ā I can see that some people would prefer very short sessions (five to fifteen minutes), but the setting itself is in hours.
Yeah we have āmaximum session ageā: User will remain logged in for n hours since last visit
Set to 1440 by default
5 Likes
I cannot find anything more up to date on this. The maximum session age can be set to 1 hour as a minimum.
This is no use when the computer is being used in a shared environment.
Has there been anything on this recently which solves the problem. Essentially I need the user forgotten when the browser is closed and the user has logged in with SSO.
Thanks
That is exactly my patch did, but that was reverted 
You can check the code and port it to a plugin.
2 Likes
Totally non-Discourse question:
How does this even happen? Presumably:
- Each user has a separate UserID for the computer system itself at the OS level
- Walking away from a work computer requires logging out/locking their desktop session
- Next co-worker needs to log in using their own desktop id, so their own sandboxed browser session, etc. Discourse cookies should not even be available to the wrong co-worker.
OK so this is a security threat - I will start a new thread
Luke the whole world does not live in strictly controlled office environments.
Take open access sites within an academic institution and machines within libraries etc. Many do not see supplying a browser interface as a security risk.
I totally agree that people can configure their hardware and software to not have this problem, but not everyone does that configuration. So, by providing a forum to our users where we know that there are security flaws if the hardware and software it runs on is not configured in a certain way makes us responsible I would say.
1 Like
Thatās a fair question. Environments which commonly use a shared desktop experience include libraries, schools, and hospitals, though there are others. As you might imagine, driving factors include a focus on ease of use (asking first grade children to remember their username is hard enough, but now adding on a password that doesnāt include their username or personal name, and has numerals, and special characters? ha!), lack of unique users (libraries commonly lack usernames because that could be a form of user tracking, and that rubs many in library settings the wrong way), and a requirement for very fast responses from the system (hospitals donāt have time for windows to login when somebody is dying in the emergency room, so they (in my experience) never have unique logins per doctor/nurse/assistant).
As a result, it is up to applications to be secure (defense in depth should apply anyway), and when one application does not provide that security, it just isnāt used because security is still required.
Some of these environments may not be the primary target of something like Discourse, but it could easily be used to facilitate the operations in any of these environments if setup properly. Kids and adults can share information on a class within a group specific to a class. While people in libraries may not have library logins, they still use those computers to login to systems all over with their own usernames/passwords (though I would never do such a thing). Hospitals could use it for intra-hospital or inter-hospital communications, sharing ideas on given topics, procedures, etc., and in all those cases Discourse would presumably have a full login for posting users.
In many of these cases, Single Sign-On (SSO) may also apply, bringing both increased security and convenience when setup properly. The problem here is that a persistent cookie defaulting to two (2) months (!!) means anybody coming to that computer in the next couple months will magically get in as the user who was there last. The setting can be turned down to as little as one (1) hour, but thatās still plenty of time for accidental or malicious problems. What can you do in a couple months?
Loan your computer to a friend.
Give it away to somebody who needs it when you do not (donation)
Get tired of a computer, turn it off, sell it on eBay, ship it around the world, and have somebody use it.
Suffer a break-in and theft at your home or workplace.
Have a coworker compromise your computer overnight, booting to external media and pulling out helpful persistent cookies.
Be targeted by somebody with an agenda, on Craigslist/social meda, etc. offering to buy your computer for some insane amount to get what is on there with your permission.
Some of those sound far-fetched, but theyāre also easy, and relatively cheap. Some people who should know better might be willing to āloseā their three (3) year old work computer, and get a new one as a result, in exchange for $1,000 from somebody online. Many on these forums might see through that, but not everybody is honest, or financially secure.
Itās a little alarmist to call this a security threat. Environments with shared computers already have options to ensure one user canāt enter the session of another whilst moving between computers:
- incognito tabs
- fast user switching
- thin client
I only know of one client environment in the last two decades where the top option wouldnāt have been possible.
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.
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?
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
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
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
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.
I also have this problem and I donāt know how to solve it.
Thanks for this @codinghorror what would be the process and timescales for having this evaluated and implemented?
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?