How to avoid "Account login timed out, please try logging in again" when the payload had expired in SSO


(Mohit Gupta) #4

@fbender, I looked into admin panel for the SSO setting on a failed login but I cannot find it. Can you please tell me where is this setting.

(Felix Freiberger) #5

I think he is referring to sso not approved url.

(Mohit Gupta) #6

@fefrei thats not working either

(Florian Bender) #7

Yeah I tested it myself and it did not work. Question is whether it actually should work. @techAPJ

(Arpit Jalan) #8

sso not approved url setting is used when the SSO login is successful but the Admin has enabled must approve users setting and the user has not been approved yet.

(Arpit Jalan) #9

Looking at the current code:

I don’t think it’s possible to redirect user to any other page.

EDIT: I may wire up a setting that could make this possible. @sam should I go ahead and add a setting sso_timeout_expired_url for this case? Is this something we should have?

Implementing SSO, nonce immediately expires
(Sam Saffron) #10

First fix is to present a proper error page there as opposed to 1 line of text

(Felix Freiberger) #11

Wouldn’t a proper reaction be to just redirect back to the SSO login URL?

Assuming my login on the external site is still valid (e.g. I was just taking too long to log in there), this would actually log me in immediately, just with an additional roundtrip. If the login on the external site expired in the meantime, I have to authenticate again – but this is what I want to to, since I was just trying to login anyway.

SSO Plugin Account login timed out, please try logging in again
(Florian Bender) #12

What’s the status here? I like the proposal of @fefrei though it might lead to an infinite redirect loop somehow, so that should be safe-guarded. @techAPJ did you impelement something yet?

(eriko) #13

How long does the nonce last and is that configurable? Depending on if the user is authenticated in the the SSO provider already it may take them to long if they have to actually log in.

(Felix Freiberger) #14

Per the spec, the nonce is valid for 10 minutes:

(eriko) #15

Ok that is interesting. Because I have gotten that message in less than 30 seconds.

(Dean Peterson) #16

This has become a systemic problem for me. When the server first comes up things are ok. With any kind of load, every new user registering with sso is getting this Account Login timed out error. I tried upgrading to the latest version of Discourse today. The problem is still occurring.

(Sam Saffron) #17

This sounds very odd to me, we only show that message if it took upwards of 10 minutes to run through stuff in your side. What forum is this happening on? Can it be reproduced on demand?

(Dean Peterson) #18

If you register at, the first thing I do is initiate the sso to discourse on successful login. That transitions to then back to once registration in discourse is complete. That flow is often blocked with the timeout error. It is happening sporadically now throughout the day.

(Dean Peterson) #19

It seems every time I mention I run discourse for I get no more responses. Would it help if I mention I am also lead architect for the State of MN at DEED; in charge of making technology buying decisions?

(Sam Saffron) #20

Well, we could diagnose this for you if you signed up for our hosting, we host 100s of discourse sites and I have not seen this particular issue.

Reason I stopped responding is that I am stumped and need access to the system, logs, and a repro

(Dean Peterson) #21

Figured out the issue. I switched to running containers in Openshift a while back. We have multiple containers running for restful backend services. In the login process I store an authorized token generated in an initial call to the backend in application scope. That token is used to finalize account creation in discourse on a subsequent call. One call to generate the token occurs on one container. The subsequent call happens on the other container that doesn’t have the token or an old token stored. My REST services need to be stateless.


I am experiencing the same issue on our hosted instance of Discourse. I am using CAS as my auth protocol and using CASino as my SSO server. I also have GitHub - eriko/discourse_cas_sso: An app that proxy connects CAS authentication to discourse via the discourse sso api running as a separate service to mediate the handshakes between my SSO server and Discourse.

Every now and then, a random log in throws the error above. There is nothing recorded logged under /logs endpoint.

The flow between systems is as follows:
Discourse -> Nginx 1 -> discourse_cas_sso Rails app -> Nginx 2 -> CASino Rails App

(Mattias Petter Johansson) #23

I ran into this problem and I had a similar problem as @depeters. I was using connect-ensure-login which was storing the url containing the payload and sig in req.session.returnTo, thus the system tried to reuse an already used nonce. The problem went away after I started clearing the returnTo session value after using it once. I.e.

    passport.authenticate('auth0', { failureRedirect: '/' }),
    function(req, res) {
      const redir = req.session.returnTo
      req.session.returnTo = null
      res.redirect(redir || '/user')