Session Timeout

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


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 :laughing:.

Keep in mind we have 100k+ non tech employees :older_man:


Sure @sam will need to review.

1 Like

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.

1 Like

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:

  • (default disabled) “Stay signed in” option for sign in page.
  • choose default behavior for sign in (session based vs permanent) - default to permanent
  • Add site setting for “maximum session age for session cookie” which should be way lower than 1440 hours which we use for permanent one (probably 24 hours would be a reasonable default), this is a safeguard for people who forget a tab opened

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

  1. you want these options in core
  2. you want us to build it vs a community pr

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.


That is exactly my patch did, but that was reverted :confused:

You can check the code and port it to a plugin.


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.