Help passing source URL for SSO

support
1

We have an issue when users click on a piece of protected content (like a shared link in Twitter) and they are not logged in. The go to our memberful login page (SSO) and come back to the root categories, not the original item they clicked on. This seems like it should be built in somehow. Memberful suggested I reach out to the community:

On the SSO side of things we don’t know the page the user was originally trying to access that was protected, in the case of Discourse we redirect to the " /session/sso_login " endpoint after a successful login. Discourse then checks the value of the destination cookie (https://github.com/discourse/discourse/blob/master/app/assets/javascripts/discourse/controllers/login.js.es6#L148) it stored to determine where to send the user, and in this case the cookie on your installation of Discourse is either being unset or set to “https://community.intelligentfanatics.com/latest” as that was the page where the SSO login was triggered from.

None of the settings you suggested seem to solve this issue, it looks like a code change will be required in Discourse to set the destination cookie differently if you are redirected to another page before the SSO is called. If this feature is essential it might be worth contacting the Discourse team on their development discussion.

Any help, much appreciated! Maybe it’s a simple setting somewhere I’m missing.

1 Like
2

I’ve tested this on my hosted forum, using the WP Discourse plugin for SSO. I’ve tried sharing links to protected content on both Twitter and Facebook. When someone clicks on the link, they are redirected to my website, go through the login process, and are then redirected by Discourse to the correct topic. I’ve tried this both with the ‘login required’ setting enabled and with content in protected categories.

I don’t think there is anything that Memberful SSO could be doing that would be causing a problem for you. As they noted, the return path for an SSO request is set by Discourse when someone attempt to access content that requires logging in.

Have you changed the ‘same site cookies’ setting on Discourse? If so, try setting it to “Lax” and see if that makes a difference. If that isn’t the problem, can you let us know which version of Discourse you are on?

3 Likes
3

It was already set to “Lax”. So I’m back to square one. @joebuhlig suggested it was something that Memberful (SSO) was doing. Now I remember, when I disable his procourse teaser plugin, then it works. I just tested it now. So it is indeed something his plugin is doing, because when it’s enabled, folks never get redirected back to the original content they clicked.

1 Like
4

I don’t know what to do here. The developer can’t seem to fix it or doesn’t know how. Are their any other teaser topic plugins that show locked content titles in listings?

6

It looks like the problem is with the plugin’s check_teaser_on_login method. Maybe that method could check if SSO is enabled, and not overwrite cookies[:destination_url] if it is?

3 Likes