Detecting user already logged in when using SSO

Hi all

We are using the SSO mechanism, which is working great, with one exception.

If a user is logged in to our main site, then clicks a link to go to the forums, they are not logged in when they hit Discourse. They then hit login and transparently become logged in. This is a bit confusing.

It would be nice if Discourse could detect that the user is logged in to the main site. There are a couple of ways that this could be done, but the most straight forward is a redirect of all non-logged-in users via an SSO URL which will return indicating whether the user is logged in or not. This URL could be the existing SSO url with a parameter to indicate that a reply should come immediately even if the user isn’t logged in, or it could be a completely separate URL. Given that the reply in the case of the user being logged in should look like the reply for a successful SSO login, my gut feel would be to hit the same SSO URL with an extra parameter.

This behaviour could then be optionally enabled via a flag in the settings, maybe “Immediate SSO Login Check” or something like that.

Thoughts?

Thanks

Tom

Note that this is different to the current behaviour when login required and enable sso are both enabled, as we want this to happen without requiring login required to be enabled, and the behaviour at the SSO provider is different - we don’t want non-logged-in users to be immediately presented with a login screen.

to do this cleanly and transparently we would need to add a special query param that you understand like say ?checkonly that forces you to always redirect back and then do some iframe magic, either that or:

  1. have your main site allow XHR from the discourse site and simply do a json call.
  2. you add a jsonp endpoint and use that for the test

regardless pulling this off is technically a bit tricky, not that I am against it.

1 Like

Couldn’t it be a whole-page redirect? Given that the login will be a whole-page redirect anyway.

Or is it preferable to do login-specific UI via AJAX? (I don’t know the internals of Discourse, maybe you cache most stuff and layer user login stuff in js…)

It could but I really dislike the idea of doing that cause anon (and crawlers) will pay a huge price. Additionally it would mean that any outage on the main site would cause a outage on the discourse site.

Hmm, I hadn’t thought about crawlers.

Can the Discourse UI handle getting notified about a user at some later point during page load? Or will it just do a full page refresh at that point?

a lot of internals need to be changed when a user logs in, we really are forced to do a full refresh at that point.

OK, so there might be a flash of un-logged-in content, but there’s not much that we can do about that at this time.

So we’re talking about getting the current logged-in status via one of:

  • IFRAME + redirect
  • JSON get requiring CORS headers etc
  • JSONP script

Last seems like the simplest for both Discourse and the SSO provider to implement.

2 Likes

So, have Discourse have a </body> script that goes like this:

if (!Discourse.User.currentProp('username') {
    $.ajax(....., {
        ....
        dataType: "jsonp",
        success: function(xhr) {
            if (xhr.responseJSON.have_account) {
                window.location = "/session/sso";
            }
        }
    });
}

It fails open - if the main site is down, the user can continue to browse as an anon on Discourse.

Hello guys, I recently faces the same problem. Any updates about your solutions? I would appreciate any kind of reply regarding this issue. Thanks in advance. :slight_smile:

Hi, I have implemented one very simplistic workaround for the case of linking discourse from the main site. Just changed the link to /login only for logged in users. If the user is logged in in our site and is not logged in discourse, it causes discourse to reload immediately and the user is then logged in via SSO. If the user was already logged in in discourse, there will be no page reload whatsoever.

This however does not cover the case when you need to link to specific page in discourse (maybe some redirectUrl parameter would solve this) and the case you came to discourse directly or from other site.