My problem is when using SSO, so I really need to be a site setting.
When we detect that the SSO is down we nuke the cookies, but if the user left the pc with a valid SSO session, and other user opens it, he can be logged as someone else.
Setting expires to session may solve this.
Guys, I traced down making the _t cookie having a smaller expires.
The problem is that Discourse doesnât seen to handle this very well atm.
We get a /login redirect but the it results in a ajax error instead of rendering the /login page properly.
Should I add special code to handle this expiration on the $.ajax function?
Probably best to consult with @sam first before proceeding, but in general, I would like it if people could set their siteâs cookies to expire, say, weekly if they want that to happen.
The _t cookie is the wrong spot imo, we should start off by adding a column to user table that specifies when the auth token was created
Then it is trivial to expire cause a site setting can check for stale tokens when doing current user resolution
I do not like the idea of having this logic up to clients, cause clients can cheat
https://github.com/discourse/discourse/pull/4226
Since a timed cookie is a very bad idea, I have done a switch between Session and Permanent. Permanent still default, so no changes for most people.
My use case is enterprise communities, where sharing computers happen very often. People are used to services not persisting trough a browser restart or a computer restart and are posting on each other account 
.
Keep in mind we have 100k+ non tech employees 
Sure @sam will need to review.
The feature provided by @Falco got removed by commit a9207dafa
It would be great to bring back this feature. Because some users donât perform an explicit logout by hitting the button. Theyâll just close the browser assuming this would terminate their session as well. But the session will be still alive.
Please let the admin decide whether or not to use permanent sessions. It is a valuable feature for specific communities and use cases.
Now that my auth changes are all done a ton of stuff is easily on the table.
Personally I think the best change we can make here is:
We already have âmaximum session ageâ which is set to 1440 hours, by heavily reducing it we can âsort ofâ approximate a session based cookie, except that unlike a session based cookie, closing and opening tabs will keep you logged on.
These 3 site settings and bits of UI needed for âstay signed inâ option are probably doable in 1-2 days of work.
@codinghorror your call if
We only need the 1440 value as a site setting the other stuff can be ignored.
Does anyone know if this was ever implemented? I would like the ability to control when a userâs session times out if possible.
I canât recall if we added the session duration site setting, do you remember @sam?
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
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.
Totally non-Discourse question:
How does this even happen? Presumably:
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.
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:
I only know of one client environment in the last two decades where the top option wouldnât have been possible.