SSO 重定向循环

支持
1

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?

2

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.

3

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.

4

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

5

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.

6

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

7

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.

8

抱歉，也许我说的是最显而易见的问题，但我在这个问题的根源上看到了 WebKit WebView 的 bug 报告。我尝试了 Discourse 论坛上的这些变通方法，但没有成功。

我的一位同事（他是 Web 程序员，而我不是）提议在 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 的设置面板中无法实现这样的功能，这需要通过修改更深层的代码来完成，可能会引发问题，或者在更新时丢失。

感谢您的建议。

9

除了等苹果修复，没人有其他办法吗？

10

嘿 @nikod，我们公司在类似问题上通过将“同站 Cookie”设置从“严格”改为“宽松”解决了问题：

image
image615×120 9.81 KB

1 个赞