Issue: Bleeding-edge external SSO prohibits returning to host app


(Gregory Avery Weir) #1

We are pinned to the tests-passed branch of Discourse, and we’ve found that the following commit broke our SSO solution: SECURITY: The SSO `return_path` was an open redirect · discourse/discourse@f5e0cf6 · GitHub

We have login on our (non-Discourse) site, and as part of the login process we redirect to Discourse with a return_path to the host site (on a different subdomain) so that we can continue with the normal flow and let Discourse be logged in “in the background” without it disrupting our users’ flow. If users later visit the forums, they find themselves pleasantly still logged in.

However, from what I can tell, this commit restricts return_path to being on the Discourse subdomain. This means that we can’t log in to Discourse and then return to our own site.

For the moment we can pin ourselves to 1.2.0.beta5, but is it possible to provide a whitelist or otherwise disable this restriction on the return_path domain?


Sharing authentication between root and subdomain
(Sam Saffron) #3

@eviltrout’s fix is legit here, otherwise you have an open redirect due to this line

If you need this functionality I would recommend a double redirect, register an extra route using a plugin and then redirect from it offsite, that way you can validate that the redirect is going to the correct place.


Smoothly integrating Discourse with an existing social site
(Dean Taylor) #4

My SSO implementation is working OK with the current version:
Discourse 1.2.0.beta5 - https://github.com/discourse/discourse version 85d9b2d227a1fa77584be7781db54a7a95c2973f

Main Site / custom WordPress SSO source: www.example.com
Discourse Instance: forum.example.com

I can login and out repeatedly in a Incognito window without issue.


(Sam Saffron) #5

The issue is not that you can not log in, its that it no longer redirects you off-site when you “ask it to” (because we can not trust that information)


(Kane York) #6

What if the return_path was moved to be in the signed portion? That could work!


(Sam Saffron) #7

its echoed back … so it can not work that way.


(Jacob Chapel) #8

What about having a whitelist of return_path domains in the SSO config section?


(Dean Peterson) #9

This is a showstopper for me


(Gregory Avery Weir) #10

Here’s the plugin we created to provide a secondary redirect route.

It’s only been mildly tested, but you can use it by having the return path be /session/sso_redirect?return_path=[actual return path].

A valid redirect domain whitelist is available in the site settings.


(Dean Peterson) #11

Thanks! Now I just have to learn Ruby and how to add a plugin, but this will certainly make the job a lot easier :smile: – Update - I found the tutorial for adding a plugin so I’m set. Thanks again!


(Dean Peterson) #12

The error I mentioned previously was due to an unrelated change I made (not your plugin).


(Adam Capriola) #13

If your goal is to silently log the user into Discourse, you could utilize an iframe instead of doing the redirect:

<iframe src="http://discourse.example.com/session/sso" width="0" height="0" tabindex="-1" title="Discourse SSO" style="display:none" hidden>

More here. I previously used return path too but I think the iframe is better.


(Dean Peterson) #14

Very nice. Yes, that is my goal and I like the iframe idea better than forcing the redirects. Thanks!


(Sam Saffron) #15

@eviltrout we need to do something here, I thought we were going to add a site setting here ?


(Dean Peterson) #16

What do you do about the same origin policy in development? My application in development is on localhost and the discourse application is on a different machine. I am getting a lot of same-origin errors.


(Adam Capriola) #17

I’m honestly not sure – all my stuff is live and seems to be working ok. I might be approaching this incorrectly however.


(Dean Peterson) #18

Ok thanks. Yeah, it would be a nice solution but it is not a viable one for me. I need to be able to test outside of production and keep things maintainable. The same origin requirement for iframes will not allow this to work.


(Adam Capriola) #19

Came across a scenario where a return_path domain whitelist would be helpful:

I am using the hidden iframe above to silently log users in. New users often miss the Welcome Message though – it’s sent while the user is considered active (but in actuality they aren’t) so they won’t receive an email notification about it.

If I could set the redirect away from Discourse I think this would make it so the email notification about the Welcome Message would send (user wouldn’t be considered active when the message is received).

So … +1 for domain whitelist! :rice:


(Kane York) #20

An <embed src="discourse.../session/sso" onload="document.location='/next-page'> works.


(Adam Capriola) #21

That is redirecting the whole page for me (not just the embed/iframe).