# Session timeout with SSO
**URL:** https://meta.discourse.org/t/session-timeout-with-sso/110211
**Category:** Bug
**Created:** [February 27, 2019, 6:55am UTC](https://meta.discourse.org/t/session-timeout-with-sso/110211 "2019-02-27T06:55:53Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@Michal\_Spak](https://meta.discourse.org/u/Michal_Spak)
#### Post date: [February 27, 2019, 6:55am UTC](https://meta.discourse.org/t/session-timeout-with-sso/110211/1 "2019-02-27T06:55:53Z")
Hello guys! I’m presently working on integrating Discourse with our site as an inward dialog board for senior clients of the framework. We are clearly utilizing the SSO include for this, and that bit is working fine and dandy.
One of the necessities of this combination is that we have to actualize a short session timeout to coordinate the primary site. As of now I have the most extreme session length set to Discourse’s base of 60 minutes. It appears as though setting this does work and the session expires, be that as it may, the manner in which this collaborates with the SSO highlight is by all accounts somewhat broken – on the off chance that I leave my program tab inert for over 60 minutes, returning and tapping on any of the connections, (for example, “Best” or “Most recent”) results in a system mistake:
System Error
while endeavoring to stack/latest.json?order=default
That forum\_signon URL is the SSO endpoint. It would seem that what Discourse is doing is reacting to the AJAX ask for/latest.json with a 302 divert to the SSO URL, which at that point comes up short in light of the fact that the SSO supplier doesn’t permit the CORS ask. Truth be told by the Network board the solicitations go/latest.json →/session/sso → [Do My Management Homework - Do My Homework Online Do My Homework Online](https://domyhomeworkonline.net/do-my-management-homework.php)
Note that I did likewise take a stab at adjusting the SSO supplier to set an Access-Control-Allow-Origin header, yet this didn’t appear to help either.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [March 1, 2019, 4:01am UTC](https://meta.discourse.org/t/session-timeout-with-sso/110211/2 "2019-03-01T04:01:28Z")
Interesting bug, we usually send an HTTP header back saying you have been logged out, but if that redirects and the client can not follow the redirect it is probably not getting the header.
@david can you add to your list to investigate this.
- Site requires login
- Site has SSO defined (you can point local at meta or something)
- You are on latest page
- You delete cookies
What should happen is we should pop up the dialog saying you were logged out. But maybe the redirect is throwing the internals off.
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [April 15, 2019, 3:45pm UTC](https://meta.discourse.org/t/session-timeout-with-sso/110211/4 "2019-04-15T15:45:57Z")
I followed the steps @sam listed, and got the popup error:
But I did manage to reproduce the OP. The error very specifically happens when the auth tokens **expire** on the server. If you delete the cookies on the client, it works fine. Recategorizing this to #Contribute > Bug
To repro easily, set session length 1 hour, and log in via SSO. Fake the expiring tokens using:
```plaintext
time = 2.hours.ago
UserAuthToken.update_all(rotated_at: time, created_at: time, updated_at: time, seen_at: time)
```
---
### Author:  [@jamesh](https://meta.discourse.org/u/jamesh)
#### Post date: [April 16, 2019, 3:48am UTC](https://meta.discourse.org/t/session-timeout-with-sso/110211/5 "2019-04-16T03:48:37Z")
For me, the error happens even when just deleting the cookies, due I believe to the CORS failure as @Michal_Spak mentioned (GET latest.json 302 → GET sso 302 → OPTIONS primary site → failure).
@david - could your attempt to repro have failed because you have some exciting CORS options which means [meta.discourse.org](http://meta.discourse.org) allows your request?