# SSO redirect loop
**URL:** https://meta.discourse.org/t/sso-redirect-loop/117898
**Category:** Support
**Created:** [May 16, 2019, 8:45am UTC](https://meta.discourse.org/t/sso-redirect-loop/117898 "2019-05-16T08:45:21Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@nikod](https://meta.discourse.org/u/nikod)
#### Post date: [May 16, 2019, 8:45am UTC](https://meta.discourse.org/t/sso-redirect-loop/117898/1 "2019-05-16T08:45:21Z")
Hey there,
we’re using Discourse [v2.3.0.beta2 +130] with SSO. For a few months now (sorry that I can’t pinpoint the exact update that caused the issue) collegues are reporting SSO redirect loops (followed by 429 errors which is ok) when clicking on discourse links in webmail clients. This only happens, if one is already logged in. We can reproduce in Firefox and Chrome on Windows and Linux. Steps to reproduce:
- When logged out of discourse (all cookies cleaned etc)
- Click on a Disourse link in Gmail or Zimbra
- A new tab opens with the Discourse URL
- After getting redirected to our SSO login enter your credencials
- You get successfully logged in
- Click on another Discourse link in Gmail or Zimbra
- A new tab opens with the Discourse URL
- You get redirected to the SSO login
- Then you get redirected back to Disrourse with the token in the URL
- Then Discourse redirects you back to the SSO login
- and so on …
Strangly this doesn’t happen if the link is copy/pasted instead of clicked on. This strikes me as weird.
These are the URLs in the loop
- `https:// forum.our.tld/`
- `https:// forum.our.tld/session/sso`
- `https:// sso.our.tld/sso/discourse?sso=bm9u…%3D%3D&sig=3944…`
- `https:// forum.our.tld/session/sso_login?sso=bm9uY…1B%0AbmRyZWFz…Vhc19sYXV0X…JTQwZ2…dHAlM0ElMkYl…BBKitodHRw…pdG9y…rJTI4ZW…Vu%0AZGUr…9fdXJs%0APWh0…Nlc3Npb2…3D%0A&sig=13f4…`
I found similar topics here but none of them is matching my exact problem:
- We have HTTPS everywhere, so it’s probably not related to [SSO Loop - Help needed to find the problem](https://meta.discourse.org/t/sso-loop-help-needed-to-find-the-problem/78214). We do SSL termination in Haproxy in front of Discourse.
- It’s not a Safari thing, so it’s not related to [Infinite SSO redirect on Safari](https://meta.discourse.org/t/infinite-sso-redirect-on-safari/110857).
Any ideas what might be wrong here?
---
### Author:  [@itsbhanusharma](https://meta.discourse.org/u/itsbhanusharma)
#### Post date: [May 16, 2019, 9:52am UTC](https://meta.discourse.org/t/sso-redirect-loop/117898/2 "2019-05-16T09:52:27Z")
I’d be interested to check the email provider responsible for sending emails on behalf of your discourse install, I’ve seen similar behaviour on a client when they accidentally enabled email tracking (which essentially rewrites the links) on the discourse emails.
There can be other potential candidates too which may need the forum link for identification.
---
### Author:  [@nikod](https://meta.discourse.org/u/nikod)
#### Post date: [May 16, 2019, 9:56am UTC](https://meta.discourse.org/t/sso-redirect-loop/117898/3 "2019-05-16T09:56:15Z")
> [@itsbhanusharma](#):
>
> I’d be interested to check the email provider responsible for sending emails on behalf of your discourse install, I’ve seen similar behaviour on a client when they accidentally enabled email tracking (which essentially rewrites the links) on the discourse emails.
Discourse is sending mails via our own mailservers. There’s no link rewriting or tracking involved.
I also suspected Gmail at first, but the issue is the same with Zimbra.
---
### Author:  [@itsbhanusharma](https://meta.discourse.org/u/itsbhanusharma)
#### Post date: [May 16, 2019, 9:57am UTC](https://meta.discourse.org/t/sso-redirect-loop/117898/4 "2019-05-16T09:57:47Z")
Did you check the email raw? Maybe something interesting can be found there.
But before I row this to the wrong bank, are those links actually being opened in a real browser or some sort of web-view
---
### Author:  [@nikod](https://meta.discourse.org/u/nikod)
#### Post date: [May 21, 2019, 2:55pm UTC](https://meta.discourse.org/t/sso-redirect-loop/117898/5 "2019-05-21T14:55:42Z")
> [@itsbhanusharma](#):
>
> But before I row this to the wrong bank, are those links actually being opened in a real browser or some sort of web-view
It’s a real desktop browser. Right-click → copy link location → paste works. A simple left-click opens a new tab and then hangs in the loop. I don’t know if some Javascript is interfering with what’s actually happening or if it’s just a `target=blank`.
---
### Author:  [@itsbhanusharma](https://meta.discourse.org/u/itsbhanusharma)
#### Post date: [May 21, 2019, 3:14pm UTC](https://meta.discourse.org/t/sso-redirect-loop/117898/6 "2019-05-21T15:14:22Z")
I think You really need to check the email RAW for possible issues since the link being sent is correct.
---
### Author:  [@nikod](https://meta.discourse.org/u/nikod)
#### Post date: [May 23, 2019, 2:03pm UTC](https://meta.discourse.org/t/sso-redirect-loop/117898/7 "2019-05-23T14:03:30Z")
I can even reproduce with this page:
```plaintext
foo
https://forum.our.tld/t/title/3940/551
```
When clicking on the link I’m in the redirect loop, if I copy/paste it it works.
I’m … puzzeled.
The only thing I can think of that’s different in a browser when clicking on a link vs. copy/pasting the link is the referrer.
---
### Author:  [@marco.palumbo](https://meta.discourse.org/u/marco.palumbo)
#### Post date: [January 22, 2021, 11:16am UTC](https://meta.discourse.org/t/sso-redirect-loop/117898/8 "2021-01-22T11:16:31Z")
Sorry if maybe I’m saying the most obvious but I see the problem origin on this issue on [WebKit WebView](https://bugs.webkit.org/show_bug.cgi?id=213510)
I tried workarounds mentioned [here on discourse forum](https://meta.discourse.org/t/infinite-sso-redirect-on-safari/110857/6) with no success
One of my colleagues (he’s a web programmer, me not) purposed to change something on the SSO provider (not `myforum.com/session/sso_provider`) so that when it calls the forum sends a GET in URL querystring with an extra parameter login=mylogin
Likely the token creation call goes
from `myssoprovider.com/sso?sso=xxxxx&sig=xxxxx`
to `myssoprovider.com/sso?sso=xxxxx&sig=xxxxx&login=mylogin`
But AFAIK it’s not possible to implement such a thing on discourse side from settings panel, rather it’s a mod that goes deeper and can cause problems or going lost in updates.
Thanks for your suggestions
---
### Author:  [@marco.palumbo](https://meta.discourse.org/u/marco.palumbo)
#### Post date: [January 26, 2021, 3:39pm UTC](https://meta.discourse.org/t/sso-redirect-loop/117898/9 "2021-01-26T15:39:46Z")
No one has an idea on that except waiting on Apple to fix it?
---
### Author:  [@raeno](https://meta.discourse.org/u/raeno)
#### Post date: [May 3, 2021, 2:02pm UTC](https://meta.discourse.org/t/sso-redirect-loop/117898/10 "2021-05-03T14:02:01Z")
Hey @nikod, we had a similar issue in our company and solved it by setting ‘same site cookies’ setting to “lax” instead of “strict”:
