UPDATE: 解決しました!
問題を解決するために force_https を有効にすることができ、すべてが解決しました。パスキーが http:// にルーティングしようとしていたことが判明しましたが、その混合トラフィックはブラウザによってフラグが立てられていませんでした。結局、Cloudflare はまったく問題ではありませんでした。これが将来誰かの役に立つことを願っています。
元の投稿:
問題
こんにちは!最近、Discourse インスタンスを Cloudflare Tunnel の背後に移動しましたが、パスキーを除いてすべて正常に機能しているようです。既存および新規のパスキーの登録は失敗しますが、ログからは失敗の理由が明確になっていないと思います。この問題を解決するために必要な追加のトラブルシューティング情報を見つけるのを手伝っていただける方がいることを願っています。
関連情報
セットアップについて
- Discourse Docker を使用して Discourse をデプロイしています。
- Postgres と Redis は外部にデプロイされています。
- AWS EC2 インスタンスの Ubuntu にデプロイされています。
- 前述の通り、Cloudflare Tunnel が TLS を提供し、プロキシとして機能しています。
試したこと
- 設定を確認し、Discourse がフォーラムのホスト名 (
forums.example.com) を期待していることを確認しました。 - Cloudflare が TLS を処理しているため、Discourse はポート 80 HTTP で設定されています。
- HTTP が成功しなかった場合、自己署名証明書を提供して Discourse を SSL のみに強制しようとし、Cloudflare をポート 443 の HTTPS プロトコルで Discourse にリダイレクトしました。
- Cloudflare が
forums.example.comをサイトに渡していることを確認しました。他のホストヘッダーが Discourse の NGINX に 404 を引き起こすため、これは確認済みです。
関連ログ
- この部分は少しトリッキーです。Discourse はサーバー側で何も提供していません(私が知る限り)、Bitwarden、iCloud Keychain、Chrome、または Firefox のいずれを使用しても結果は同じです。
- パスキー自体のログはほとんどありません。
- 新しいパスキーを作成しようとしたときに、Firefox / Chrome の開発者ツールコンソールから得られた最も役立つ情報でした。以下が返されます。
{
"errors": [
"The origin of the authentication request does not match the server origin."
]
}
これは、クライアントと Discourse(別名プロキシ)の間で何らかの問題が発生していることを明確に示していますが、これらのログは、この問題をさらにトラブルシューティングするために送受信されている情報を表示していません。
他に確認すべき設定やログの場所、またはトラブルシューティングの推奨事項があれば、誰か教えていただけますか?可能性は低いと思いますが、NGINX の設定に誤りがある可能性も考えられます。クライアントと Discourse の間に、CloudFlare と NGINX の両方が実行されている二重プロキシがあります。このセットアップのいずれかの部分を再検討すべきでしょうか?
優先順位としては、確かに修正されると嬉しいですが、数千人のユーザーのうちパスキーを使用しているのは約 8 人だけで(他のログイン方法はすべて正常に機能しています)、それほどストレスを感じていません。