# Shared cookie SSO: Notifying frontend
**URL:** https://meta.discourse.org/t/shared-cookie-sso-notifying-frontend/120012
**Category:** Development
**Created:** [June 11, 2019, 11:12am UTC](https://meta.discourse.org/t/shared-cookie-sso-notifying-frontend/120012 "2019-06-11T11:12:00Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@edL](https://meta.discourse.org/u/edL)
#### Post date: [June 11, 2019, 11:12am UTC](https://meta.discourse.org/t/shared-cookie-sso-notifying-frontend/120012/1 "2019-06-11T11:12:00Z")
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?
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [June 12, 2019, 1:55pm UTC](https://meta.discourse.org/t/shared-cookie-sso-notifying-frontend/120012/2 "2019-06-12T13:55:32Z")
Why are you not using the built in SSO support?
> [@Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso)](https://meta.discourse.org/t/official-single-sign-on-for-discourse-sso/13045):
>
> [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) is a core Discourse feature that allows you to configure “Single Sign-On (SSO)” to completely outsource all user registration and login from Discourse to another site. Offered to our [pro, business and enterprise hosting customers](https://discourse.org/pricing). information_source (Feb 2021) ‘[Discourse SSO](https://meta.discourse.org/t/13045?silent=true)’ is now ‘[DiscourseConnect](https://meta.discourse.org/t/13045?silent=true)’. If you are running an old version of Discourse, the settings below will be named sso\_... rather than discourse\_connect\_... The Problem Many sites wishing to integrate wit…
---
### Author:  [@edL](https://meta.discourse.org/u/edL)
#### Post date: [June 12, 2019, 2:10pm UTC](https://meta.discourse.org/t/shared-cookie-sso-notifying-frontend/120012/3 "2019-06-12T14:10:41Z")
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.
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [June 12, 2019, 5:37pm UTC](https://meta.discourse.org/t/shared-cookie-sso-notifying-frontend/120012/4 "2019-06-12T17:37:39Z")
> [@edL](#):
>
> I wish I could, but IIRC, the built-in SSO uses OAuth/OIDC.
The built-in [Discourse SSO](https://meta.discourse.org/t/13045?silent=true) 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.
---
### Author:  [@edL](https://meta.discourse.org/u/edL)
#### Post date: [June 13, 2019, 9:37am UTC](https://meta.discourse.org/t/shared-cookie-sso-notifying-frontend/120012/5 "2019-06-13T09:37:37Z")
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 🙏
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [June 13, 2019, 9:58am UTC](https://meta.discourse.org/t/shared-cookie-sso-notifying-frontend/120012/6 "2019-06-13T09:58:06Z")
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:
```plaintext
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.
---
### Author:  [@edL](https://meta.discourse.org/u/edL)
#### Post date: [June 13, 2019, 10:31am UTC](https://meta.discourse.org/t/shared-cookie-sso-notifying-frontend/120012/7 "2019-06-13T10:31:28Z")
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 🙂
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [June 13, 2019, 10:37am UTC](https://meta.discourse.org/t/shared-cookie-sso-notifying-frontend/120012/8 "2019-06-13T10:37:46Z")
> [@edL](#):
>
> 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.
> [@edL](#):
>
> I’ll see if we can use the standard SSO instead.
👍 definitely the safer option here