无法确定 Cloudflare 代理背后的 Passkey 问题

支持
1

更新：已解决！

为了解决这个问题，我能够启用 force_https，这为我们解决了所有问题。事实证明，passkeys 试图路由到 http://，但浏览器没有标记这种混合流量。事实证明 CloudFlare 根本不是直接问题。希望这能帮助到其他人。

原始帖子：

问题

你好！我最近将我的 Discourse 实例移到了 Cloudflare tunnel 后面，除了 passkeys 之外，一切似乎都运行良好。现有的和新的 passkey 注册都失败了，但我认为日志并没有清楚地说明失败的原因。希望这里有人能帮助我找到解决此问题的其他故障排除信息：

相关信息

关于我的设置

  • 使用 Discourse Docker 部署 Discourse。
  • Postgres 和 Redis 是外部部署的。
  • 部署在 AWS EC2 实例的 Ubuntu 上。
  • 如前所述，Cloudflare tunnel 提供 TLS 并充当代理。

我尝试过的方法

  • 我已检查我的配置，以确保 Discourse 正在等待我的论坛主机名（forums.example.com）
  • Discourse 已配置为端口 80 HTTP，因为 Cloudflare 正在处理 TLS
  • 当 HTTP 未成功时，我尝试通过提供自签名证书并将 Cloudflare 重定向到端口 443 的 Discourse（使用 HTTPS 协议）来强制 Discourse 仅使用 SSL。
  • 我确保 Cloudflare 将 forums.example.com 传递给我的站点。我知道它会，因为任何其他主机头都会导致 Discourse 的 NGINX 返回 404。

相关日志

  • 这部分有点棘手。Discourse 没有在服务器端提供任何信息（据我所见），无论我使用 Bitwarden、iCloud Keychain、Chrome 还是 Firefox，结果都一样。
  • passkey 本身的日志几乎不存在
  • 当尝试创建新的 passkey 时，我在 Firefox / Chrome 开发工具控制台中找到的最有用的信息。返回以下内容：
{
  "errors": [
    "The origin of the authentication request does not match the server origin."
  ]
}

这清楚地表明客户端和 Discourse（又名代理）之间存在问题，但这些日志并未指明来回传递了哪些信息以进一步进行故障排除。

有人能帮助我找出任何其他要检查的设置或日志位置，或者有任何其他故障排除建议吗？我认为不太可能，但我猜 Nginx 配置中的失误也可能是一个因素。我实际上在客户端和 Discourse 之间有一个双重代理，同时运行 CloudFlare 和 Nginx。我应该重新考虑这个设置的任何部分吗？

就优先级而言，当然是希望能够修复，但由于在几千用户中只有大约 8 位用户使用 passkeys（其他登录方式运行正常），所以我并没有过多地担心它。

2 个赞