Discourse SSO Provider 登录时未将用户重定向到 return_sso_url

支持 SSO
1

据我所知，同样的问题曾两次被提及，并被告知已在 2018 年（https://meta.discourse.org/t/discourse-doesnt-redirect-to-return-sso-url-after-user-logs-in-on-private-site/97201）和 2015 年（https://meta.discourse.org/t/login-redirect-during-sso-provider-login/29759）得到修复。但我仍然遇到同样的问题。

我们组织内部署了 Discourse。我们拥有自己的用户账户数据库，因此我们使用自定义的 SSO 登录网站，按照 Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso) 中的说明，允许用户登录 Discourse。该功能运行良好。

此外，我们还拥有 WordPress、Rocket Chat 以及一个自定义的 Tornado Web 应用。它们都依赖 Discourse 作为 SSO 提供商。

对于 WordPress，我们使用 wp-discourse 插件。对于 Rocket Chat 和 Tornado Web 应用，我们遵循了 Use Discourse as an identity provider (SSO, DiscourseConnect) 中的说明。

如果用户已经登录过 Discourse，登录流程运行良好。然而，如果用户尚未登录 Discourse，则所有服务的登录流程（例如 WordPress、Rocket Chat 或 Tornado Web 应用）都无法正常工作。当用户尝试登录 WordPress、Rocket Chat 或 Tornado Web 应用时，他们会被重定向到 discourse.com/login。然后，用户点击登录按钮，这会将他们重定向到我们自定义的 SSO 网站。在那里完成登录后，他们会被重定向回 discourse.com，而不是目标服务（例如 WordPress、Rocket Chat 或 Tornado Web 应用）。

顺便提一下，wp-discourse 的“与 Discourse 同步登出”功能不起作用。当用户登出 WordPress 时，他们仍然保持登录 Discourse 的状态。

在经历了多次 Discourse 更新后的几个月里，我一直面临这个问题。现在我寻求帮助。如果需要任何详细信息，请告知。

我目前的变通方法是：不将用户重定向到 /session/sso_provider，而是将其重定向到 /session/sso?return_path=customurl。缺点是，即使用户已经登录过 Discourse，系统仍会要求他们重新登录。

2

在自定义 SSO 登录过程中，登录应用实际上从 cookie sso_payload 中读取并提取了 return_sso_url。该 return_sso_url 被嵌入到 sso 载荷中，以便发送至 /session/sso_login?。我确实可以在 /logs 中观察到 return_sso_url 已正确设置，但未观察到重定向行为。以下是我粘贴的日志内容：

add_groups:
admin:
moderator:
avatar_force_update:
avatar_url:
bio:
card_background_url:
email: xxx@xxx
external_id: 42
groups:
locale:
locale_force_update:
logout:
name: xxx
nonce: b4c758723a8abf665b079dc41a585dbc
profile_background_url:
remove_groups:
require_activation:
return_sso_url: https://customurl
suppress_welcome_message:
title:
username: xxx
website:
location:

3

@cylau1996 你找到什么解决方案了吗？

4

有什么解决方案吗？