現在、ローカルのDiscourse環境がないため、どの程度お手伝いできるかわかりません。
404応答が出るのは、DiscourseサイトでDiscourse Connectが有効になっているか疑問に思います。
ローカルの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の出力から来ています。
何か間違っているに違いありません。根本原因に非常に近いようです。
サーバーを起動して、サーバーからAPIキーでリクエストを送信するようにトリガーすることさえ試しましたが、結果は同じでした。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 の 2 つのキーペアのみをボディに含める必要があり、api-key と api-username はヘッダーに含める必要がありました。
「いいね！」 2
サイトで現在 external_id を使用していない場合、これはどのように動作しますか？メールのみに基づいてユーザーをログインさせることができますか？
より一般的には、email と external_id はペイロードの 2 つの必須フィールドですが、これらがディスコース側（認証サイトからペイロードを受信するとき）で、どのユーザーアカウントにログインするかを判断するためにどのように使用されるか、明確にしていただけますか？
- ユーザー作成時にメールに関連付けられた
external_idがなかった場合、メールを使用し、将来のログインのためにこのメールにexternal_idを関連付けますか？ emailとexternal_idの間に不一致がある場合（それぞれが異なるディスコースアカウントに関連付けられている）、ログインするユーザーを判断するためにexternal_idまたはemailのどちらを使用しますか？それともエラーが発生しますか？
ありがとうございます！
external_idフィールドについてのご質問かと思います。DiscourseConnectのペイロードにexternal_idフィールドを設定する必要があります。このフィールドの値は、変更されないユーザーに関連付けられた文字列であるべきです。アプリケーションにユーザーテーブルがあると仮定します。そのテーブルのユーザーエントリの主キーをexternal_idフィールドの値として使用するのが良いでしょう。
ユーザーがDiscourseConnect認証をウェブサイトから追加する前にDiscourseでアカウントを作成していた場合、DiscourseConnect経由でDiscourseに初めてログインする際に、DiscourseはDiscourseConnectペイロードに含まれるメールアドレスに基づいてユーザーを見つけようとします。ユーザーが見つかった後、DiscourseConnectペイロードからのexternal_idを含むレコードがDiscourseデータベースに追加されます。次にユーザーがログインする際には、メールアドレスではなくexternal_idによってユーザーが見つけられます。（これは、DiscourseConnectペイロードでrequire_activationパラメータをtrueに設定した場合、機能しないことに注意してください。）
Discourseには、ほとんどのエッジケースに対応するための優れたフォールバック機能があります。複数のアカウントやメールアドレスを持つユーザーに関連する問題があり、エラーが発生する可能性があります。これらのケースの対処方法に関する詳細は、こちらにあります：デバッグと一般的なDiscourseConnectの問題の修正。
「いいね！」 1
とても参考になりました、ありがとうございます！期待通りに動作するようです 
「いいね！」 1
WordPressをプロバイダーとして数年間 DiscourseConnect を正常に使用しており、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 と同じ画面が表示されます。
ヘッダーのロゴをクリックすると https://discourse.domain.ext/ にアクセスでき、ログインも成功すること（ボタンをクリックするだけ）にも気づきました。
以前のバージョンでは、セッションコントローラー が異なって動作しており、外部 SSO によって呼び出しが開始されたことを理解し、正しく処理していた可能性が高いと思われます。
過去 1 か月間に @zogstrip がコミットした変更が、この誤動作に関連している可能性があることに気づきました（100%確実ではありません）。
現時点では、Discourse URL に /login を追加するコールバックメソッドに回避策を適用しており、すべて正常に動作しているようです。
このコード部分で潜在的に破壊的な変更に関するアドバイスを提供するドキュメントなど、見落としているものがあればお知らせください。
サポートありがとうございます。
「いいね！」 2
@markschmucker、@jimkleiber、@marco.palumbo は、No login methods when using Discourse Connect only で説明されているのと同じ問題を抱えていますか？
もしそうであれば、修正方法は「認証を即時実行する」サイト設定を有効にすることです。
「すぐに認証する」が有効になっています。
@zogstrip、ご協力ありがとうございます。残念ながら、「すぐに認証」を有効にすると、「ウェルカム」ページを匿名ユーザーに表示できなくなります。
「いいね！」 1
DiscourseConnect SSO を使用して名前や avatar_url を削除することはできないようです。フィールドを空文字列に設定してみました（たとえば、avatar_url= が base64 の sso パラメータに含まれていることを確認しました）が、コードは空のフィールドを無視するのだと思います。
私のシステムでは、名前と画像はオプションですが、現在の動作では、一度設定すると、置き換えることはできても、解除することはできません。私が何か間違っている可能性はありますか？（もしそうでなければ、修正できるかもしれませんか？）
[編集]: すでに回答を探していましたが、もちろん、上記を投稿した直後に、異なるキーワードで検索を試みたところ、Allow name removal using SSO - #9 by mentalstring を見つけました。それにアップボートしましたが、あまり期待はしていません。 
「いいね！」 2
上記で @markschmucker、@jimkleiber、@marco.palumbo が説明しているのと同じログインリダイレクトの問題が発生しています。数週間前にこの問題に気づき、5月のある時点では正常に機能していたことを知っています。上記であなたが言っていることを読むと、これはDiscourseに5月のあるアップデートで導入されたリグレッションであると確信しています。なぜなら、私たち全員が同時にこの問題に遭遇し、皆SSOコードが機能しており、共通のSSOコードは何も共有していないからです。
修正してもらうために、バグレポートを投稿しました。
リダイレクトの問題は3.6.0-beta1で修正されました。
「いいね！」 1
@markschmucker と @marco.palumbo さん
これは数週間前に修正済みで、v3.6.0.beta1で正常に動作するはずです。
「いいね！」 3