我现在没有本地的Discourse安装，所以我不确定我能帮多少。
404响应让我想知道Discourse Connect是否真的在你的Discourse站点上启用了：
听起来你正在使用一个本地的angular应用程序和一个生产环境的Discourse站点进行测试。我预计这仍然可以工作，但可能导致了问题。你肯定应该能够得到除404之外的某种响应。
@simon 感谢您的回复，
我自己已经确认了好几次，
我还有一个生产测试站点，托管在此 discourse 站点的父域上。如果您可以查看这个 [link redacted]
来测试生产流程，我已经将 Discourse Connect URL 更新为“https://domainsite.com/login”，请随时使用 Google 提供商登录并进行测试。在检查控制台日志中，您将看到我打印出的错误和响应，即 404。
由于我只是在做 POC，如果您不介意的话，可以留下您的电子邮件，我可以将您设置为管理员，以便更仔细地调查我的 discourse 站点上的配置。再次感谢您的时间和帮助。
我唯一不确定的部分是 sig 和 sso，我在代码中这样做正确吗？除了这个部分。API 密钥，我尝试了两种方式，生成给所有人和只给系统，结果都一样。如果可能的话，请提供一个适用于 Postman 或基于 Angular 的示例代码，供我参考。
我注意到您代码截图中的这一点：
mode: 'no-cors'
我不熟悉 Angular 应用，但看起来您正尝试从客户端向 Discourse 发出经过身份验证的 API 请求。我不确定这在 Discourse 代码的哪个位置，但我的理解是 Discourse 会阻止从客户端发出的管理员 API 请求。这是因为无法在不暴露客户端 API 密钥的情况下发出请求。与此相关的是，您应该立即更改您的 API 密钥。
1 个赞
感谢您指出这一点，
感觉又前进了一步。
我也尝试从 Postman 发送请求。
如果您认为客户端的“mode: ‘no-cors’”阻止了 Discourse 接受来自前端的 api 密钥调用，那么从 Postman 发送应该没问题，对吗？但结果是一样的
sig 和 sso 来自 ssoPayload 和 signature 的输出，我在过程中打印了它们。
一定有什么地方出了问题，似乎离找到根本原因很近了。
我甚至尝试启动一个服务器，然后触发服务器使用服务器端的 apikey 发送请求，结果是一样的，这让我觉得我在 Discourse 站点上缺少一些配置。
1 个赞
从 Postman 或命令行使其正常工作是个好主意。从您发布的屏幕截图来看，您似乎将 api-username 和 api-key 放在了请求的正文中。这些参数需要放在请求头中。请求的正文应包含 sig 和 sso 键/值对。如果这对您有帮助，以下是 WP Discourse 插件处理它的方式：wp-discourse/lib/plugin-utilities.php at main · discourse/wp-discourse · GitHub 。
1 个赞
太棒了！开始了，
现在它能用了！
非常感谢 @simon
问题正如你所说：
sso 和 sig 应该是 body 中仅有的两个键值对
api-key 和 api-username 应该放在 headers 中
2 个赞
如果我在一个目前不使用 external_id 的网站上启用此功能，它将如何运行？它能否仅根据用户的电子邮件地址登录用户？
更广泛地说，由于 email 和 external_id 是载荷中 2 个必填字段，您能否澄清它们在 Discourse 端（在接收来自身份验证网站的载荷时）如何用于确定要登录哪个用户帐户？
- 如果在用户创建期间没有将
external_id与电子邮件关联，它会先使用电子邮件，然后将external_id与此电子邮件关联以供将来登录吗？ - 如果
email和external_id之间存在不匹配（每个都与不同的 Discourse 帐户关联），它会使用external_id还是email来确定登录哪个用户？还是会抛出错误？
谢谢！
我认为你的主要问题是关于 external_id 字段。你需要在 DiscourseConnect payload 中设置一个 external_id 字段。该字段的值应该是一个与用户相关联的、永远不会改变的字符串。我假设你的应用程序有一个 users 表。该表中用户条目的主键很适合用作 external_id 字段的值。
如果用户在你的网站添加 DiscourseConnect 身份验证之前已经在 Discourse 上创建了帐户，那么当他们第一次通过 DiscourseConnect 登录 Discourse 时，Discourse 会尝试根据 DiscourseConnect payload 中的电子邮件地址查找用户。找到用户后，将在 Discourse 数据库中添加一条记录，其中包含来自 DiscourseConnect payload 的 external_id。下次用户登录时，将通过 external_id 而不是电子邮件地址来查找他们。（请注意，如果将在 DiscourseConnect payload 中将 require_activation 参数设置为 true，则此方法无效。）
Discourse 对大多数边缘情况都有很好的回退机制。存在与用户拥有多个帐户和电子邮件地址相关的问题，这些问题可能会触发错误。有关处理这些情况的一些详细信息，请参见此处：Debug and fixing common DiscourseConnect issues。
1 个赞
非常有帮助，谢谢！听起来一切都如我所料 
1 个赞
我们已经成功地将 DiscourseConnect 与 WordPress 作为提供商一起使用了好几年，并且没有更改 Discourse 或 WP 的配置。今天我注意到一个我认为是新的行为。
当我注销时，它以前会带我到 WordPress 登录屏幕。现在它会带我到 Discourse 登录屏幕。如果我尝试使用 Discourse 屏幕登录，我会收到一个“未知错误”，但关键是我根本不应该出现在那里——我应该在 WP 登录界面。
请注意，我确实启用了本地登录（不确定为什么，因为我正在使用 WP）。如果我禁用本地登录并尝试登录，它会说没有可用的登录方法。所以我想它不喜欢我的 WP 连接，但同样，我没有更改任何一端的配置。我已确认 Discourse Connect 已启用，连接 URL 正确，并且两端的密钥相同。
已更新至 3.5.0.beta5-dev。WP Discourse 插件也已更新。
2 个赞
我也遇到了同样的问题，我将尝试找出问题所在。
1 个赞
我们也正在使用 DiscourseConnect 并遇到相同的问题。
我们已经运行了几年，一切都很顺利。今天更新到 3.5.0.beta8-dev [e91024a221]。
基本上，来自 sso 系统的回调到 discourse url 添加了 https://discourse.domain.ext/login，我们看到了与 @markschmucker 相同的屏幕。
我们还注意到，点击标题 logo 会跳转到 https://discourse.domain.ext/，并且登录成功（只需点击一个按钮）。
似乎在之前的版本中，session controller 的行为有所不同，很可能理解到该调用是由外部 sso 发起的，并以正确的方式进行了处理。
我注意到在上个月 @zogstrip 提交了一些可能与此错误行为相关的更改（不确定）。
目前，我们在回调方法中应用了一个变通方法，该方法在 discourse url 中添加了 /login，一切似乎都正常工作。
如果我遗漏了任何关于此代码部分可能具有破坏性更改的建议文档，请告诉我。
感谢您的支持。
2 个赞
@markschmucker、@jimkleiber 和 @marco.palumbo，你们是否也遇到了 No login methods when using Discourse Connect only 中强调的相同问题？
如果遇到，解决方法是确保启用了“auth immediately”站点设置。
我已经启用了“立即授权”。
感谢您在此事上的帮助@zogstrip。不幸的是，如果我启用“立即进行身份验证”，我将失去为匿名用户提供“欢迎”页面的能力。
1 个赞
使用 DiscourseConnect SSO 似乎无法删除姓名或 avatar_url。我尝试将字段设置为空字符串（已确认例如 avatar_url= 最终会出现在 base64 sso 参数中），但我猜代码会忽略空字段。
在我的系统中，姓名和头像都是可选的，但目前的工作方式是，一旦设置，就永远无法取消设置，只能替换。我有没有可能做错了什么？（如果没有，也许可以修复？）
[编辑]：我已经搜索过答案了，但当然在我发布上述内容后，我尝试搜索了不同的关键词，找到了 Allow name removal using SSO - #9 by mentalstring 。我给它点了赞，但并不抱太大希望。
2 个赞
我和 @markschmucker、@jimkleiber 和 @marco.palumbo 在上面描述的登录重定向问题一样，我是在几周前发现这个问题的，我知道它在五月份的时候还能正常工作。阅读了你们上面的说法，我确信这是 Discourse 在五月份的某个更新中引入的一个回归错误，因为它同时影响了我们所有人，我们都有有效的 SSO 代码，并且我们之间没有共享任何 SSO 代码。
我发布了一个错误报告，希望能尽快修复这个问题。
重定向问题在 3.6.0-beta1 中已为我修复。
1 个赞
@markschmucker 和 @marco.palumbo
看起来这个问题在几周前就已经修复了，并且应该在 v3.6.0.beta1 中正常工作了。
3 个赞