# DiscourseConnect flow no longer functions
**URL:** https://meta.discourse.org/t/discourseconnect-flow-no-longer-functions/182844
**Category:** Support
**Created:** [March 11, 2021, 3:01am UTC](https://meta.discourse.org/t/discourseconnect-flow-no-longer-functions/182844 "2021-03-11T03:01:30Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@barryvan](https://meta.discourse.org/u/barryvan)
#### Post date: [March 11, 2021, 3:01am UTC](https://meta.discourse.org/t/discourseconnect-flow-no-longer-functions/182844/1 "2021-03-11T03:01:30Z")
Since the update from DiscourseSSO to [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true), our SSO integration has stopped working.
We have what is probably an unusual setup, in that there are multiple applications from which SSO can be initiated, rather than a single one. Our software can be installed on-prem or multi-tenanted in the cloud. Each tenant instance of the software includes an SSO link through to our Discourse community. This means that we can initiate the SSO from (for example) `tenant1.ourcompany.com` and from `software.tenant2.com` and from `something.else.com` – nearly a thousand different places.
We don’t have a single central identity provider across all of our tenants; each can use their own IDP solution (Google, O365, AD, Okta, …). Server-side, we have processes and mitigations in place to protect against account take-overs.
Unfortunately, our approach here seems to have stopped working in the most recent Discourse update. (Thanks to [this commit.](https://github.com/discourse/discourse/commit/13d2a1f82c25e16f96ac3bdad67f4369e3d43a61)) From a technical perspective, the flow that was working was this:
- Our backend would, via API, obtain a nonce and SSO details from Discourse
- Discourse would send a 301 redirect with the SSO payload back to us at a single specific address
- The server here was configured to ignore the 301 redirect (to avoid nonce errors). Instead, it would parse the `Location` header, decode the base64 values, get the nonce, generate the SSO payload, sign it with the SSO sercrete and send the user on their merry way to the SSO login URL.
It seems that the nonce has been changed so that it’s attached to the browser session (to protect against CSRF attacks). This means that when we try the flow above, the client browser is missing the `_forum_session` cookie for the nonce when we send them back to Discourse, and so we get a “nonce expired” message.
Is it possible to make this CSRF protection optional? That is, to have a new setting for `enable_secure_nonce` which we can set to `false`?
As it stands, most of our customers are locked out of our forum, and we’re looking at having to get them all to set up passwords, and losing our ability to track forum notifications in our app – so we’ll see a downturn in engagement. ☹
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [March 11, 2021, 3:24am UTC](https://meta.discourse.org/t/discourseconnect-flow-no-longer-functions/182844/2 "2021-03-11T03:24:53Z")
> [@barryvan](#):
>
> Is it possible to make this CSRF protection optional?
Yes traditionally we have always supported site settings for cases like this. We will probably make it a hidden setting cause it is very hard to explain, but I do support it for outlier cases like yours. We can then enable it on your instance.
@david will have a look at this.
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [March 11, 2021, 10:33am UTC](https://meta.discourse.org/t/discourseconnect-flow-no-longer-functions/182844/5 "2021-03-11T10:33:37Z")
It’s [now possible](https://github.com/discourse/discourse/pull/12356) to disable the protection via the rails console by running
```plaintext
SiteSetting.discourse_connect_csrf_protection=false
```
You should only do this if you understand and accept the risks it introduces. For anyone hosted by [discourse.org](http://discourse.org), please get in touch and we can flip the setting for you.
(cc @rysher who had [a similar request](https://meta.discourse.org/t/sso-stopped-working-after-upgrade-to-2-6-2-from-2-5-1/180901))
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [April 10, 2021, 10:39am UTC](https://meta.discourse.org/t/discourseconnect-flow-no-longer-functions/182844/7 "2021-04-10T10:39:03Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.