Maybe I am missing this in the Admin settings somewhere – but is there a way to set session expiration times so that if a user is not active for a specified length of time they will have to log in again? I would use such a feature if it were available.
1 Like
What’s your use-case that you would use it for?
At this point, you’d basically need to set a custom CurrentUserProvider in a plugin. Check out the default current user implementation to get an idea of how they currently set the current user. You could probably copy most of that but set an expiry on the cookie.
2 Likes
I have a topic open regarding the lack of a required password for invites from a trusted user: https://meta.discourse.org/t/require-password-for-trusted-user-invites/13750
One of the possible solutions is a limitation on how long the tokenized invite link will work. Expiring sessions would be an indirect way of addressing the issue(s) I raised. Although, it seems like clicking on the original invite link would just initiate a new session regardless.
Totally open to having an option in core, however there would need to be a few changes made.
I am comfortable with the keep me logged in forever, feel it complicates stuff for no great reason having people logged off randomly. Google keeps you logged on “forever”, facebook the same.
Facebook allows you to have a “temporary” session, with the “keep me logged on” option.
I am open to:
- Adding a “keep me logged on” option to the login dialog (enabled via site setting)
- Adding an option to auto expire sessions after N hours of inactivity (enabled via site setting)
We are way too busy to work on this at the moment, would have to come from the community.
1 Like
Thanks to everyone for your responses.
I figured I should be prepared to answer that. 
I’m hosting a forum where committee members, accountability partners, etc. across our churches can discuss options for computer / mobile device security. Some folks who have access will be visiting for how-to guides; how can I disable browsing on my son’s smart phone? or how can we force a laptop to run its web traffic through a filtering proxy? etc. Obviously some of this is more secure if the methods used are not open to everybody; not as easy to scheme ways to circumvent them. I like the option of being logged in indefinitely, but some of my users might appreciate if their session expired after some time so that not just anyone can come along to their computer, hit the forum address, and have access to everything. Not that the forum’s content is that private, necessarily; just the security reasons I mentioned above. For now I’m encouraging users to log out when done. Make sense?
No rush. And I’m not going to make much noise about it. Not a huge deal, just another feature for you to implement when you run out of ideas and time lies heavy on your hands. 
I’m not sure Google does what you are saying; I have tabs open to Google Mail and Google Calendar, and periodically (every few weeks) I am required to log in again.
As we discussed months ago, for our deployment we’ll need to be able to expire active login sessions if the authentication provider indicates that the identity used for the session is no longer valid. Anyone using a corporate auth provider for Discourse will likely require this.
Ya, same here. I don’t know how often it is, but Gmail keeps booting me out and asking for my password every once in a while. Almost seems sort of random. Anyway, I need to re-enter my password, log in again, and carry on.
If this is still being considered - I would love to be able to set a universal “keep me logged in forever” setting.
At the very least duration of login should be editable in site settings. Not sure how hard this is to make a site setting variable @sam but it should be there.
4 Likes
I think session expiration is required for anyone using SSO as access control.
If you only think of SSO as another way to get a verified email address and then the user is part of the Discourse community forever and ever, then non-expiring sessions are great. But if you’re using SSO to control who has access to your Discourse, so that when your SSO system says they’re not a member anymore they no longer can access Discourse, then you need expiring sessions and/or a requirement to check back with the SSO system to ensure the person is still in good standing.
When the SSO says that an existing Discourse user is not in good standing, then all existing email subscriptions in Discourse should also be disabled. Only users in good standing should be able to get information out of my Discourse forum.
If there is another solution to my controlled access problem, I’d love to hear about it.
1 Like
I will need this same sort of thing; we plan to use our OAuth provider to allow our employees to login with extra privileges, but if an employee’s account is deactivated, then any existing Discourse sessions need to be terminated.
1 Like
This is pretty straight forward using the API there is an Admin API endpoint for logging out a user, you would issue it from your end.
Unfortunately we cannot issue API calls from our authentication provider, there will have to be some sort of ‘pull’ mechanism to notice that a session is no longer valid.
Yes, the Oauth provider isn’t the right place for this, it’s typically the role of identity management. The only alternative is to set a very short Discourse session expiration so that Oauth is being hit very regularly to check if it’s still valid.
Depending upon your scale and the value of that setting though that could lead to Discourse hammering your authentication provider quite unpleasantly.
1 Like
Ok, logging them out solves part of the problem. What is the right way to also disable their notifications?
Is redis handling the session for Discourse users? If so, the memory will be eaten all.
Any one know whether there is any news?
I’m currently working on a website SSO integration with Discourse. One problem we found is when the user login expired on the website itself, the session is still valid in Discourse. It seems Discourse still don’t set a login expiration time at least for SSO, while the website defaults to 1 month.
This cause confusing user experience. A user found out he was auto logged out on website due to login expired, however when he switched to forum he’s still displayed as logged in.
Don’t we have a login cookie expiration time site setting now @sam?
I can’t find a login expiration site setting yet. And even if it exists, it can’t solve the problem.
Imaging that a user logged in on the website today, and only navigate to forum tomorrow. He won’t get the forum cookie until he navigates to it. So even though we can set cookie from both side to a same period, there still is one day difference.
I think we need to be able to specify the expiration time on a per login basis. When the SSO login happens, the web site is able to check when the user’s website cookie is going to expire, and set the Discourse cookie expire time to that exact same time.