# 重建后使用稳定版v3.3.3，SSO失效

**URL:** <https://meta.discourse.org/t/sso-broken-after-rebuild-with-stable-v3-3-3/343847>\
**Category:** SSO\
**Created:** [2024年十二月21日 22:10 UTC](https://meta.discourse.org/t/sso-broken-after-rebuild-with-stable-v3-3-3/343847 "2024-12-21T22:10:25Z")\
**Posts on this page:** 1\
**Showing post:** 9

<div class="post-metadata">

**Author:** ![mentalstring](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mentalstring/32/168934_2.png) [@mentalstring](https://meta.discourse.org/u/mentalstring)\
**Post date:** [2024年十二月22日 08:16 UTC](https://meta.discourse.org/t/sso-broken-after-rebuild-with-stable-v3-3-3/343847/9 "2024-12-22T08:16:47Z")

</div>

> [@simon](#):
>
> 这有点渺茫，但你是否在不同的浏览器会话中生成了 nonce，例如通过应用程序的后端发出 SSO 请求，而不是让用户通过浏览器重定向来完成 SSO 流程？

并非如此——我们遵循重定向，实现了 [Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso)](https://meta.discourse.org/t/setup-discourseconnect-official-single-sign-on-for-discourse-sso/13045) 中描述的相当标准的实现。它已经顺利运行了好几年，我们也没有动过它。

> [@simon](#):
>
> 有一个隐藏的站点设置 `discourse_connect_csrf_protection`，默认启用。

虽然我们没有做任何不寻常的 SSO 操作，但我还是尝试了，通过在 Rails 控制台中禁用它，结果只是移除了错误消息。也就是说，当 SSO 提供商重定向回 Discourse 时，没有出现 `账户登录超时，请重试登录。` 错误，而是没有任何消息（错误消息或其他）——但遗憾的是，仍然是未登录状态。

> [@simon](#):
>
> 这有点渺茫

我也在胡乱猜测，因为这很奇怪。我认为，问题在我们最初通过 Web 界面更新到 3.3.3 时没有出现，而是在大约 36 小时后通过控制台重建才出现，这可能是一个线索，但我对两者之间的差异了解不够。

我再次尝试升级到 3.3.3，问题立即出现。切换回 3.3.2 后，SSO 又可以正常工作了。

---

_[View the full topic](https://meta.discourse.org/t/sso-broken-after-rebuild-with-stable-v3-3-3/343847)._