Network errors on session timeout when using SSO

I’m currently working on integrating Discourse with our website as a internal discussion board for senior users of the system. We are obviously using the SSO feature for this, and that bit is working just fine.

One of the requirements of this integration is that we need to implement a short session timeout to match the main site. Currently I have the maximum session length set to Discourse’s minimum of 1 hour. It seems like setting this does work and the session does expire, however, the way this interacts with the SSO feature seems to be a bit broken – if I leave my browser tab idle for over an hour, coming back and clicking on any of the links (such as “Top” or “Latest”) results in a network error:


Network Error

while trying to load /latest.json?order=default

Please check your connection.

Go Back Try Again

In the Chrome console, there are a few errors, the most notable one appearing to be the one relating to a CORS pre-flight check:

Access to XMLHttpRequest at '' (redirected from '') from origin '' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

{readyState: 0, getResponseHeader: ƒ, getAllResponseHeaders: ƒ, setRequestHeader: ƒ, overrideMimeType: ƒ, …}

Error while processing route: discovery.latest


That forum_signon URL is the SSO endpoint. It looks like what Discourse is doing is responding to the AJAX request for /latest.json with a 302 redirect to the SSO URL, which then fails because the SSO provider doesn’t allow the CORS request. In fact according to the Network panel the requests go /latest.json/session/sso

Note that I did also try modifying the SSO provider to set an Access-Control-Allow-Origin header, but this didn’t seem to help either.

Have I managed to mess up the configuration somewhere, or is this a bug in Discourse’s SSO / AJAX handling?

We’re running a couple of minor releases behind the latest stable at 2.1.2 (although I couldn’t see anything relevant in the git logs between that and 2.1.6).

I believe this is a known issue, perhaps @sam can offer some thoughts.

1 Like

Hi, just wondering if anyone’s had chance to look at this? Is there anything I can do to my config or the way my SSO works to sort out this behaviour? We have full control over the code behind the SSO endpoint, so in theory we can do pretty much anything we need to in response to the SSO requests – e.g. is there a way we can provide the required SSO response and redirect back to the AJAX endpoint from the original request?