Shared cookie SSO: Notifying frontend

[edL (Ed Lepedus)]

I’m writing a plugin to enable shared cookie SSO with a bespoke system, but I’m not sure how to let the Ember fronted know that a user has ‘logged in’ in this way.

I’ve subclassed Auth::DefaultCurrentUserProvider and extended current_user to check for our shared cookie if the super method hasn’t found a user. This all works fine if I log in to the external service and then visit the forums, but if I’m already on the forums I have to do a manual refresh before Ember realises that I’m now logged in.

Is there a way to tell ember to do a login from the CurrentUserProvider/plugin?

[codinghorror (Jeff Atwood)]

Why are you not using the built in SSO support?

DiscourseConnect - Official Single-Sign-On for Discourse (sso)

(Feb 2021) ‘Discourse SSO’ is now ‘DiscourseConnect’. If you are running an old version of Discourse, the settings below will be named sso_... rather than discourse_connect_... The DiscourseConnect protocol allows you to completely outsource all user registration/login in Discourse. The Problem Many sites wishing to integrate with a Discourse site want to keep all user registration in a separate site. In such a setup all login operations should be outsourced to that di…

[edL (Ed Lepedus)]

I wish I could, but IIRC, the built-in SSO uses OAuth/OIDC. The bespoke service I’ve got to integrate with doesn’t implement OAuth, so they want me to grab the cookies and call an endpoint which will give me the user’s profile.

[simon]

I wish I could, but IIRC, the built-in SSO uses OAuth/OIDC.

The built-in Discourse SSO does not use OAuth/OIDC. It does require you to add some code to your SSO provider site to handle SSO requests from Discourse. There are quite a few existing implementations of this that you can use to get started.

[edL (Ed Lepedus)]

Ok, I’ve had another look, and I see what you mean. It shouldn’t be too hard to implement an SSO endpoint.

However, before chucking it over the fence and making work for them, can I confirm whether the shared cookie approach could also be viable?

It feels like I’m very close (loading the forums once signed in to the external service seamlessly logs me in). Is there any way to notify the frontend that an ‘out-of-band’ session has been created on the backend? This would address the edge case where the forums are already open in another tab.

It doesn’t even have to be completely seamless. I would be ok with it happening the next time the user interacts with the app, or even on clicking ‘Login’ (as long as they aren’t prompted for credentials).

Thank you both for your help, and sorry for being awkward

[david (David Taylor)]

The best solution here is to properly implement SSO.

If you do want to keep trying with the shared cookie, you can refresh the browser of a specific user using something like this integrated into your plugin:

MessageBus.publish "/file-change", ["refresh"], user_ids: [user.id]

I think this will require quite a lot of development to create a smooth user experience, and it’s beyond the scope of what we can provide support for. If I were you, I would spend the time creating a compatible SSO endpoint instead.

[edL (Ed Lepedus)]

Hmm… that’s really interesting – thanks. That’s exactly the sort of thing I was looking for, although having to specify a user is a catch 22. If there’s no logged in session in Ember, then it’s not going to know to respond to the message for a specific user id.

I’ll see if we can use the standard SSO instead.

Thanks

[david (David Taylor)]

If there’s no logged in session in Ember

The messagebus makes a fresh request every 30 seconds, so it should pick up the user-id, even if the rest of the Ember app does not.

I’ll see if we can use the standard SSO instead.

definitely the safer option here