SSO redirect loop

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:

Any ideas what might be wrong here?

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.

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.

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

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.

I think You really need to check the email RAW for possible issues since the link being sent is correct.

I can even reproduce with this page:

<!doctype html>
<html>
  <head><title>foo</title></head>
  <body>
    <a href="https://forum.our.tld/t/title/3940/551">https://forum.our.tld/t/title/3940/551</a>
  </body>
</html>

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.

너무 당연한 말을 하고 있는 건 아닌지 걱정되지만, 이 문제의 원인이 WebKit WebView에 있는 것 같습니다.
여기 discourse 포럼에 언급된 우회 방법을 시도해 보았지만 성공하지 못했습니다.

제 동료 중 한 명(그는 웹 프로그래머이고, 저는 아닙니다)은 SSO 제공자(myforum.com/session/sso_provider가 아님)의 설정을 변경하여 포럼을 호출할 때 URL 쿼리스트링에 login=mylogin이라는 추가 매개변수를 포함하는 GET 요청을 보내도록 하는 것을 제안했습니다.
아마도 토큰 생성 호출이 다음과 같이 변할 것입니다.
myssoprovider.com/sso?sso=xxxxx&sig=xxxxx
에서
myssoprovider.com/sso?sso=xxxxx&sig=xxxxx&login=mylogin
으로.

하지만 제가 아는 한, discourse 설정 패널에서 이런 기능을 구현하는 것은 불가능하며, 오히려 더 깊은 부분에 개입하는 플러그인(mod)을 사용해야 합니다. 이는 문제를 일으키거나 업데이트 과정에서 사라질 수 있습니다.

제안해 주시면 감사하겠습니다.

Apple이 수정할 때까지 기다리는 것 외에 다른 해결책이 전혀 없나요?

안녕하세요 @nikod, 우리 회사에서도 비슷한 문제를 겪었는데, ‘same site cookies’ 설정을 “strict” 대신 "lax"로 변경하여 해결했습니다: