Discourse を SSO プロバイダーとして使用する際に直面している問題について、専門家の意見を伺いたいと思います。
私の目標: Discourse を別のアプリケーション (LibreChat) の認証を処理するように設定しています。Discourse と通信するクライアントとして機能する OIDC ブリッジサービスである distrust を使用して、標準の DiscourseConnect プロバイダー機能を使用しています。
問題: SSO フローは最後のステップまで完璧に機能します。ユーザーは正常に私のアプリから Discourse にリダイレクトされ、Discourse の認証情報で正常にログインできます。しかし、ログイン後、提供された return_sso_url ではなく、私の Discourse フォーラムのホームページ (/) にリダイレクトされます。
行き詰まっている点 (除外したこと): この問題についてしばらくトラブルシューティングを行っており、単純な設定ミスではないことを確認しました。以下の点を明確に除外しました。
- シークレット:
discourse connect provider secretsは正しく設定されています。プロトコルなしのプレーンなドメイン (例:auth.my-site.com) を使用しており、シークレットキーはクライアントサービスのキーと完全に一致しています。 - SSO モード:
enable discourse connect providerがチェックされており、無効な「SSO Client」設定が無効になっていることを確認しました。 - ユーザーポリシー:
must_approve_usersが無効になっていること、およびテストユーザーが完全に検証済みのメールを持つ管理者であることを確認しました。 - プラグイン: すべての非公式のサードパーティ製プラグインを無効にし、コンテナを再構築しましたが、問題は解決しません。
決定的な証拠: 私を困惑させている決定的な証拠が 2 つあります。
- HAR ファイル分析: HAR ファイルでネットワークフロー全体をキャプチャしました。ログインのための
/sessionへのPOSTリクエストは成功していることが示されています。サーバーはすぐに302 Foundリダイレクトで応答しますが、Locationヘッダーは一貫して/です。これは、Discourse が SSO リダイレクトを意図的に中止していることを証明しています。 - 空の Rails ログ: 次に、ログインを試みている間にコンテナ内の
production.logファイルをテールしました。このプロセス中にログに何も書き込まれません。 これは、Discourse がこれをエラーとして認識しておらず、意図的かつサイレントなアクションであることを示しています。
私の質問: ログインは成功しているものの、リダイレクトが正しくなく、ログにエラーがないことを考えると、Discourse のどの内部ポリシー、事前チェック、または隠し設定が、return_sso_url を無視して代わりにホームページにリダイレクトさせているのでしょうか? 標準的な設定はすべて使い果たしたように感じています。
何かアイデアがあれば、事前に感謝します！