# Ensure that user is signed in to Discourse

**URL:** https://meta.discourse.org/t/ensure-that-user-is-signed-in-to-discourse/86396
**Category:** SSO
**Created:** [April 29, 2018, 8:03am UTC](https://meta.discourse.org/t/ensure-that-user-is-signed-in-to-discourse/86396 "2018-04-29T08:03:37Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![adopilot](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/adopilot/32/105040_2.png) [@adopilot](https://meta.discourse.org/u/adopilot)
#### Post date: [April 29, 2018, 8:03am UTC](https://meta.discourse.org/t/ensure-that-user-is-signed-in-to-discourse/86396/1 "2018-04-29T08:03:38Z")

</div>

Our discource is set to use SSO from our businesses app.  
In few business process we use discourse as email and notification relay.  
Some business flow starting at our erp with forms and moving on discource.  
Since discource crating SSO users only when they loged in discource, we have cases that users exists in our erp, but they do not exists in discoure.  
It happens if they did not sing in discource ever.  
If my users does not exists in discource the work flow fails.  
User is not going to be notified by email or desktop notification.  
Our app can check does user exist in discource by finding user by external-id.  
But I do not have an idea how to push user to sing in to discource and send him back to initial form, if app realize that user does not exist in discourse.

Is there some discource endpoint that will after singing in redirect user to parametered url ?

I want to send user to singing in discource and get back to my form ?

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [April 29, 2018, 12:09pm UTC](https://meta.discourse.org/t/ensure-that-user-is-signed-in-to-discourse/86396/2 "2018-04-29T12:09:48Z")

</div>

You can use the API to force the user to be crested when the account is created in SSO. The Wordpress plugin did this, so you might look the for an exempt.

---

<div class="post-metadata">

### Author: ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)
#### Post date: [April 30, 2018, 2:42am UTC](https://meta.discourse.org/t/ensure-that-user-is-signed-in-to-discourse/86396/3 "2018-04-30T02:42:02Z")

</div>

Yes calling #sync\_sso endpoint with the full single sign on payload can allow you to pre-stage accounts.

---

<div class="post-metadata">

### Author: ![shahidmir](https://avatars.discourse-cdn.com/v4/letter/s/9dc877/32.png) [@shahidmir](https://meta.discourse.org/u/shahidmir)
#### Post date: [May 24, 2018, 12:54pm UTC](https://meta.discourse.org/t/ensure-that-user-is-signed-in-to-discourse/86396/4 "2018-05-24T12:54:31Z")

</div>

Hi  
I find myself in the same situation.  
I will be migrating users to discourse. Until they login via the SSO, there will be no record in the single\_sigon\_records.

If any one of my users changes his email in the main app, before attempting an SSO into discourse, then the next time he comes to discourse will be with a new email address, which will fail.

I do not want to use a pre-staging strategy as some of those users may never even login to discourse, hence want to avoid creating records for no reason.

But if i have to go down this route, could I insert data into the ‘single\_sigon\_records’ table manually, or would it have to be via the sso\_sync endpoint?  
I notice the table has a ‘last\_payload’ field, which could be problematic in this case?

regards  
shahid
