I am working on a WordPress website that has a Discourse Forum connected to it with approximately 200K users.
Using the OAuth Single Sign On - SSO (OAuth client) and WP-Discourse plugins, we connect the posts from WP to discourse and have the users Login on WP with their WP User instance which then logs them in to Discourse too.
Now, a problem appeared, whenever we set the Discourse settings to not requiring being logged in.
These are our steps:
User logs in to WordPress
User clicks on a link leading to Discourse (a topic, any link leading to Discourse)
==> The user now sees Discourse as if they were not logged in! But they are being logged in, the moment they logged into WordPress!
Now the user clicks on the Discourse log-in or into any topic link
Page refreshes and user is now authenticated!
We have been told, that this is expected, and that we need to do the following:
when the user is logged in, all links leading to discourse from WordPress must be as follows: https://our-discourse-instance.com/session/sso?return_path={ORIGINAL URL OF DISCOURSE WE POINT TO, like a topic url, or so}
when a user is logged out, we may link to the {ORIGINAL URL OF DISCOURSE WE POINT TO, like a topic url, or so} directly, like so https://our-discourse-instance.com/t/topic-slug
I strongly suspect that this is the wrong approach to resolve this problem, because:
What if a user, while logged into Discourse, copies a topic URL, and shares that url with someone who is as well logged into the WP/DIscourse? They would get the same error as shown above in #2, since no such URL suffix would be appended
Why would a logged in user need to be redirected to session/sso?return_path=? What is the technical reasoning and logic behind this?
Why is it solved as soon the user reloads the page (loads a topic url, pressese login, etc)?
Why is this not more widely documented, if it were to be the actual expected approach?
Why would that not be mentioned in the API, where we are able to pull any topic URL from discourse, and NO where it is written that logged in users won’t be able to immediately reach the content and first need to do weird reloads, or that we need to append weird URL parameters that do, in fact, not really convert anything?
I would really appreciate some authoritative opinion on this, because I am not convinced at all that this is the expected behaviour!
If it is, I would like to inquire:
why this is actually necessary and
what is planned to be done in regard (because this surely not ideal, see point 1 of my reasons as of why this shouldn’t be expected)
If you want your users to be automatically redirected to login when they go to any path in your forum then you’ll need to enable the login required setting. This is indeed the expected behaviour.
While it still feels weird, I’ve gone ahead and added a redirect to the session/sso?return_path= on user login in wp
The return path I’ve set to the referrer from wp (if any) or the wp homepage
That works great and makes sure the user is logged in on both instances
I had to enable the setting in discourse to allow “any return path” though, since by default discourse disallows “external” return paths
Do you see any issue enabling this setting?
Thanks again for the kind reply and “official” confirmation plus documentation link!
Typically I advise clients against doing an automatic redirect like this. I understand why you feel this is an issue, it’s a not uncommon feeling, however the standard approach works just fine for many sites as large, or larger, than yours and the automatic redirect may not work in some scenarios, leading to poor UX.
The login-once-login-automatically-everywhere you’re expecting is how interconnected services like Meta (e.g. login to Facebook and you’re logged into Instagram) sometimes work because they’re centrally controlled platforms (albeit even centralised services will sometimes work the same way DiscourseConnect does too).
In contrast, you’re dealing with independent open-source software frameworks here (i.e. Wordpress and Discourse). They can be setup to effectively work in the way you’re expecting, but it requires specific custom work that takes into account your specific use case. It’ll never be how an authentication system like DiscourseConnect which serves thousands of different use cases, works.
No, with the caveat that I would question the premise of needing it. But without more information I can’t see an issue with using it.
Could this be an invalidated redirect risk, such as described here?
I can see how “allowing any return value” does indeed allow to redirect anywhere
But I am not sure if this really would be a risk, since no sensitive data is shared in or to that redirect url.
Sorry, that would be straying into giving you advice on a sensitive part of your setup without seeing it for myself, or having a defined relationship with you.
Particularly give the size of your forum, and the relevant regulations that apply to it, I’d recommend you get specific, informed, advice on that question.
A Discourse forum activates the setting in discourse to allow “any return path”
This means now you can visit your-discourse.tld/session/sso?return_path=ANYTHING
ANYTHING might be an external URL
Thus this opens a security vulnerability in terms of at least a phishing attempt could be staged:
malicious website crafts a button saying “go to the amazing community!”
the button link is your-discourse.tld/session/sso?return_path=BACK TO MALICIOUS SITE
the user presses button, logs in on the community, that leads them back to MALICIOUS SITE
there, the malicious actor implemented a page that looks exactly like the community and says "something went wrong while you logged in, please try again
the user submits a nice looking login form that matches the community looks
The malicious actor now has caught the login data?
Thus probably the setting the setting the setting “any return path” shouldn’t be used ever for a site that has users logging in, unless each and every user knows exactly what to look out for.
Would you see that risk too?
Why could Discourse developers crafting plugins/code that can interact with this setting not be able to give a nod into “yes no problem” or “hell no”?
It is not that a lot of things can change in that URL parameter. It is either there or not, either it allows externals or not.
Perhaps I am poking into an area I shouldn’t, as in “do not discuss security issues here”? I would understand that of course, many platforms do not allow talking openly about potential security issues that are not clearly defined when enabling them
I think you’ve already answered your own question.
Because the valence of settings depends on how they’re used, indeed that’s why they’re settings and not just “features”. If there was a simple answer to your question there wouldn’t be a setting in the first place.
I appreciate this somewhat lawyerly response is frustrating. But you need advice specific to your use case, which I’m not in a position to give you here.
