sda
2020 年 6 月 20 日午後 5:17
1
こんにちは、ご支援をお願いしたく存じます。今週からSSOが機能しなくなり、昨日はすべて修正したつもりでした(実際に動いていました、誓います 補足:昨日と今日の「新規ユーザー」を確認しましたが、修正後にもかかわらず両日とも新規ユーザーが作成されていました。現在は再び機能しなくなっています…)。残念ながら、今日行われた更新は効いていません。
問題:ユーザーが新しいアカウントを作成できず、ログアウトしたユーザーが再度ログインできません。
私のDiscourseサーバーで、以下のルートにおいて400エラーが発生していることに気づきました。
403 : GET : discourse-url/users/by-external/USER-ID.json?
補足:APIドキュメントを最近確認したところ、このルートは存在しないようです(それでも動作していました)。正しいルートは以下のようです:https://discourse.example.com/u/by-external/{external_id}.json
404 : POST : discourse-url/admin/users/sync_sso?
ルート末尾に ? が付いているのは、URLを生成する関数にオプションのパラメータフィールドがあるためです。これら2つのルートでは、すべてのデータはフォームボディまたはヘッダーで送信されます。
私はこちらのライブラリ を使用しています。
私が更新したもの(問題が解決したと思っていたもの):
すべてのリクエストで、Api-Key と Api-Username をクエリパラメータとして送信していました。過去数ヶ月、管理パネルで「リクエストに古いヘッダーを使用しています」という警告が表示されていることに気づいていました。これはこの投稿へのリンク であり、重要な詳細は以下の通りです:
非推奨警告!
2020年4月6日をもって、HTTPヘッダーベース以外の認証(一部のRSS、メール受信、ICSルートを除く)のサポートを終了しました。 つまり、api_key および api_username をクエリパラメータまたはHTTPボディに含めるAPIリクエストは、まもなく機能しなくなります。HTTPヘッダーを使用した認証に更新する方法については、以下のcURLリクエスト例をご覧ください。
すべてのリクエストを更新し、現在はすべてのリクエストで Api-Key と Api-Username をヘッダーに含め、コンテンツタイプをmultipart form dataに設定しています。
この問題のデバッグのために何を確認すべきか、ご助言いただければ幸いです。昨日の終業時にはほぼ100%正常に動作しており、アカウントへのログイン・ログアウトも、新規アカウントの作成もできていました。
さらに情報が必要であればお知らせください。よろしくお願いいたします!
「いいね!」 2
simon
2020 年 6 月 20 日午後 6:06
2
ヘッダーフィールド名はアンダースコア(_)ではなくダッシュ(-)を使用する必要があります。フィールド名を Api-Key および Api-Username に変更してみてください。
これであなたのサイトへのログインができないという問題が解決するかどうかはわかりませんが、現在発生している 400 エラーの問題は解消されます。
「いいね!」 2
sda
2020 年 6 月 20 日午後 6:08
3
@simon 、レスポンスありがとうございます!残念ながら私の投稿の記述が不十分でした。私のリクエストでは既に - を使用しており、_ は使用していません。
「いいね!」 2
simon
2020 年 6 月 20 日午後 6:21
4
この問題のデバッグを開始するには、Discourse サイトの設定ページに移動し、「sso」を検索してすべての SSO 設定を確認してください。enable sso、sso url、sso secret の設定が正しいことを確認します。次に、verbose sso logging サイト設定を有効にします。この設定を有効にすると、追加のログエントリがサイトのエラーログ(管理 / ログ / エラーログ)に追加されます。
SSO を介してログインを試みてください。その後、エラーログを確認して、問題の詳細が示されているかどうかを確認します。役立つ情報が見つからない場合は、ブラウザの Web インスペクタを開き、Network タブで「Preserve log」チェックボックスにチェックを入れます。行われているリクエストを確認してください。
問題の修正中にサイトからロックアウトされた場合、管理者ユーザーとして /u/admin-login にアクセスし、フォームにメールアドレスを入力することで SSO をバイパスできます。ログインリンクが記載されたメールが送信されます。
「いいね!」 2
sda
2020 年 6 月 20 日午後 6:33
5
@simon 、ヒントをありがとう!ログを見てはいるんですが、読み方があまり詳しくなくて困っています。2 つの異なる種類の警告と 1 つのエラーが表示されます。
頻繁に表示される警告は以下の通りです :
Verbose SSO log: Started SSO process add_groups: admin: moderator: avatar_force_update: avatar_url: bio: card_background_url: email: external_id: groups: locale: locale_force_update: logo
エラーは以下の通りです :
Job exception: The difference between the request time and the current time is too large.
Discourse からログアウトしたテストユーザーでサイトにログインしようとすると、ネットワークパネルに以下が表示されます。
503 Service Unavailable : GET- https://my-site/auth/discourse_sso?sso=XXXX&sig=xxxx
残念ながら、次にどう進めばよいかで行き詰まっています。
「いいね!」 1
simon
2020 年 6 月 20 日午後 6:48
6
「いいね!」 3
sda
2020 年 6 月 20 日午後 7:52
7
@simon ありがとうございます!サーバーの時刻がずれていたので、それを修正したところ、バックアップが再び正常に動作するようになりました!
さて、現在は不規則に新しいエラーが発生しています。
ログセクションでは、ランダムに以下の警告が表示されます(2 回だけ確認しました):
MaxMindDB (/var/www/discourse/vendor/data/GeoLite2-City.mmdb) could not be found: No such file or directory @ rb_sysopen - /var/www/discourse/vendor/data/GeoLite2-City.mmdb
および
MaxMindDB (/var/www/discourse/vendor/data/GeoLite2-ASN.mmdb) could not be found: No such file or directory @ rb_sysopen - /var/www/discourse/vendor/data/GeoLite2-ASN.mmdb
この問題の解決方法を調べている最中です。アプリの再構築を試みましたが、再構築が完全に成功したかどうかは 100% 確信が持てません。以前発生していた 400 エラーや 503 エラーに加えて、今もランダムに MaxMindDB が見つからないというエラーが発生しています。
「いいね!」 1
sda
2020 年 6 月 21 日午後 1:36
8
今朝の早い時間からずっとこの問題に取り組んでいますが、あまり進展していません。MaxMindDBのエラーは解消したと思います(以前は断続的かつ一貫性のないエラーでしたが、過去3時間は再現できていません)。また、アプリを数回正常に再構築しました。
SSOパイプラインがここで破綻します:
ユーザーがDiscourseにアクセス
アクティブなセッションがないため、ユーザーは discourse/session/sso_login にリダイレクトされる
ユーザーは my-site/discourse_sso?sso=XXXX&sig=XXXX にリダイレクトされる
サイト側の前のルートがヒットすると、/users/by-external/userId.json に対してGETリクエストが送信される
これにより 403 Forbidden が返される
直後に /admin/users/sync_sso に対してPOSTリクエストが送信される
これにより 404 “No route matches [POST] /admin/users/sync_sso” というエラーが発生
最終的に、サイト側から 503 Forbidden メッセージが返される(サイト側のエラーメッセージを整理する必要があります)
このエラーはRailsアプリ側の問題だと感じています(もし間違っていたら訂正してください)。その理由は、金曜日の終業時にはすべて正常に動作していたからです。金曜日の夜から土曜日の間に数人の新規ユーザーがサインアップしたという事実がそれを証明しています(ログインや新規ユーザー作成が機能しなくなっていたのが問題でした)。以前の投稿でも述べた通り、その時点で全て修正したと思っていたのですが、土曜日に作業を始めたところ、再び破綻していることに気づきました。
「いいね!」 1
simon
2020 年 6 月 21 日午後 4:26
9
sda:
サイトからの前のルートにアクセスされた際、/users/by-external/userId.json に GET リクエストを送信しています
これにより 403 Forbidden が返されます
直後に /admin/users/sync_sso へ POST リクエストが送信されます
その結果、404 “No route matches [POST] /admin/users/sync_sso” というエラーが発生します
/users/by-external/<external_id>.json や /admin/users/sync_sso へのリクエストを送信している理由がわかりません。通常のフローでは、SSO ペイロードを URL のクエリパラメータとして設定し、ユーザーを /session/sso_login にリダイレクトするだけです。sync_sso ルートの用途に関する詳細は、こちらをご覧ください: https://meta.discourse.org/t/sync-sso-user-data-with-the-sync-sso-route/84398。
Discourse ユーザーとまだ関連付けられていない external_id を用いて /users/by-external/<external_id> にリクエストを送信した場合、404(見つかりません)エラーが返されるはずです。external_id が Discourse ユーザーと関連付けられている場合は、該当するユーザーが返されます。
「いいね!」 2
sda
2020 年 6 月 21 日午後 5:19
10
@simon 、/users/by-external/USER-ID.json へのリクエストは、そのユーザーが既に私の Discourse にアカウントを持っているかを確認するために行われます。その ID でユーザーが見つかった場合、そのユーザーは私のサイトに関連付けられた Discourse グループに追加または削除され、/admin/groups/groupId/members.json への PUT リクエストを実行した後、my-discourse/session/sso_login にリダイレクトされます。
ユーザーにアカウントがない場合、/admin/users/sync_sso への POST リクエストでアカウントが作成されます。ユーザーが作成され(適切な Discourse グループにも追加された後)、my-discourse/session/sso_login にリダイレクトされます。
挙げられたドキュメントを再度確認し、フォローアップいたします(ありがとうございます!)。このフローは 2015 年初頭から問題なく動作していました(Discourse と SSO オプションは私たちにとって非常に貴重なツールでした!)。それが先週突然動作しなくなったのは不思議です。
「いいね!」 3
sda
2020 年 6 月 22 日午前 11:45
11
@simon ありがとうございます!問題を解決しました。以前使用していた Api-Username は、先週何らかの理由(非アクティブ)で「無効化」されていました。当初、これが問題の原因ではないかと推測していました。金曜日にユーザーを再度有効化し、おそらくそれが金曜日のすべての動作を正常にしたのだと思います(当初は、Api-Username と Api-Key をヘッダーに移動させたことが原因だと思っていました)。
Discourse は土曜日の朝に同じユーザーを再度無効化しました。これが、動作していたものが突然止まった理由です。非アクティブにより、これほど短期間でユーザーが再度無効化されるとは思いませんでした。
今後このような問題が起きないよう、Api-Username を「system」に変更しました。引き続きご支援いただき、ありがとうございました。このデバッグの過程で、バックアップログも再び動作するようになり、多くのことを学びました!
「いいね!」 3
system
(system)
クローズされました:
2020 年 7 月 24 日午前 11:51
13
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.