WordPress  Discourse SSO 登录用户问题

支持 WordPress
1

我正在使用 WordPress 网站，该网站连接了 Discourse 论坛，大约有 200K 用户。
我们使用 OAuth Single Sign On - SSO (OAuth client) 和 WP-Discourse 插件，将 WP 的帖子连接到 Discourse，并让用户登录 WP，然后他们也可以登录 Discourse。

现在，当我们将 Discourse 设置为不需要登录时，出现了一个问题。

这是我们的步骤：

  1. 用户登录 WordPress
  2. 用户点击一个指向 Discourse 的链接（一个主题，任何指向 Discourse 的链接）
    ==> 用户现在看到 Discourse 就像未登录一样！但他们实际上在登录 WordPress 的那一刻就已经登录了！
  3. 现在用户点击 Discourse 登录按钮或任何主题链接
  4. 页面刷新，用户现在已通过身份验证！

有人告诉我们，这是预期的行为，我们需要这样做：

  • 当用户登录时，从 WordPress 指向 Discourse 的所有链接必须如下所示：https://our-discourse-instance.com/session/sso?return_path={我们指向的 Discourse 的原始 URL，例如主题 URL 或其他}
  • 当用户注销时，我们可以直接链接到 {我们指向的 Discourse 的原始 URL，例如主题 URL 或其他}，例如 https://our-discourse-instance.com/t/topic-slug

我强烈怀疑这是解决此问题的错误方法，因为：

  1. 如果用户在登录 Discourse 时复制了一个主题 URL，并与同样登录 WP/Discourse 的人分享，他们会遇到 #2 中所示的相同错误，因为没有附加这样的 URL 后缀。
  2. 为什么已登录用户需要重定向到 session/sso?return_path=？这背后的技术原因和逻辑是什么？
  3. 为什么用户在刷新页面（加载主题 URL、点击登录等）后立即解决了？
  4. 如果这是预期的行为，为什么没有更广泛地记录下来？
  5. 为什么不在 API 中提及这一点？我们能够从 Discourse 中提取任何主题 URL，但没有任何地方说明已登录用户无法立即访问内容，并且首先需要进行奇怪的重新加载，或者我们需要附加实际上并没有真正转换任何内容的奇怪 URL 参数？

我非常希望得到权威的意见，因为我完全不相信这是预期的行为！
如果确实如此，我想询问：

  • 为什么这实际上是必要的，以及
  • 计划如何处理（因为这肯定不是理想的，请参阅我列出的 #1 原因，说明为什么这不应该是预期的行为）

谢谢！

2

您好 @smileBeda，

您可以在此处查看文档：

如果您希望用户在访问论坛的任何路径时自动重定向到登录页面，则需要启用 login required（需要登录）设置。这确实是预期的行为。

1 个赞
3

感谢 @angus 的确认。

虽然感觉还是有点奇怪，但我已经添加了一个重定向到 wp 用户登录时的 session/sso?return_path=。
return_path 我设置为来自 wp 的推荐者（如果有）或 wp 主页。

这效果很好，并确保用户在两个实例上都已登录。
我不得不启用 discourse 中的设置以允许“任何 return path”，因为默认情况下 discourse 不允许“外部”return path。

您认为启用此设置有什么问题吗？

再次感谢您的友好回复和“官方”确认以及文档链接！

4

通常，我建议客户不要进行这种自动重定向。我理解你为什么觉得这是个问题，这种感觉并不少见，然而，标准的做法对于许多和你一样大甚至更大的网站来说都运行良好，而且自动重定向在某些情况下可能无法正常工作，导致用户体验不佳。

你期望的“一次登录，处处自动登录”是像 Meta（例如，登录 Facebook 后，你就登录了 Instagram）这样的互联服务有时会工作的方式，因为它们是集中控制的平台（尽管即使是集中式服务有时也会像 DiscourseConnect 那样工作）。

相反，你在这里处理的是独立的开源软件框架（即 WordPress 和 Discourse）。它们可以被设置成你期望的方式工作，但这需要特定的定制工作，并考虑到你的具体用例。它永远不会像 DiscourseConnect 这样的身份验证系统那样工作，后者服务于数千种不同的用例。

不，但我想质疑一下是否有必要这样做的前提。但如果没有更多信息，我看不到使用它的问题。

1 个赞
5

这会不会是未经验证的重定向风险，就像这里描述的那样？

我可以看到“允许任何返回值”确实允许重定向到任何地方
但我不能确定这是否真的有风险，因为重定向 URL 中或重定向 URL 没有共享敏感数据。

谢谢！

6

@Angus - 你能就上面的最后一个疑问提供一些见解吗？

谢谢！

7

抱歉，在未亲眼看到您的情况或与您建立明确关系的情况下，这涉及到为您提供敏感设置方面的建议。

特别是考虑到您论坛的规模以及适用于它的相关法规，我建议您就该问题寻求具体、知情的建议。

8

也许我没说清楚：

  1. 一个 Discourse 论坛会启用 discourse 中的设置，允许“任何返回路径”。
  2. 这意味着现在你可以访问 your-discourse.tld/session/sso?return_path=ANYTHING。
  3. ANYTHING 可能是一个外部 URL。

因此，这会带来一个安全漏洞，至少可以进行网络钓鱼尝试：

  • 恶意网站会创建一个按钮，上面写着“前往精彩社区！”
  • 按钮链接是 your-discourse.tld/session/sso?return_path=返回恶意网站
  • 用户点击按钮，在社区登录，然后被带回恶意网站。
  • 在那里，恶意行为者实现了一个看起来与社区完全相同的页面，并说“登录时出现问题，请重试”。
  • 用户提交一个看起来与社区外观匹配的登录表单。

恶意行为者现在已经获取了登录数据？

因此，也许“任何返回路径”这个设置不应该被用于有用户登录的网站，除非每个用户都确切地知道要留意什么。

你也会看到这种风险吗？
为什么 Discourse 开发者在制作可以与此设置交互的插件/代码时，不能给出“是的，没问题”或“绝对不行”的明确答复？
这个 URL 参数能改变的东西不多。它要么存在，要么不存在；要么允许外部访问，要么不允许。

也许我触及了不该触及的领域，比如“这里不讨论安全问题”？我当然能理解，许多平台不允许公开讨论在启用它们时未明确定义的安全问题 :slight_smile:

9

你似乎已经自己回答了自己的问题。

因为设置的效价取决于它们的使用方式，这确实是它们被称为“设置”而不是仅仅“功能”的原因。如果你的问题有一个简单的答案，那么一开始就不会有这个设置了。

我理解这种有些像律师的回答可能会让你感到沮丧。但我需要针对你的具体用例提供建议，而我在这里无法提供。