SSO を使用しており、ここ数日、一部のメンバーが以下のエラーでアカウントにアクセスできないと報告しています。
アカウントに問題があります。サイトの管理者にお問い合わせください
これは以前私が報告した問題（こちら ）が原因ではないかと考え、該当メンバーの IP アドレスが「Screened IPs」に登録されているか確認しました。その結果、一人は登録されていましたが、他のメンバーはそうではありませんでした。
verbose sso logging を有効にした後、他のユーザーに再試行を依頼したところ、/logs には「IP アドレスがブロックされています」と表示されました。
Verbose SSO log: IP address is blocked xxx.xxx.xxx.xxx
しかし、二度確認したところ、その IP アドレスは「Screened IPs」には表示されていませんでした。また、PostgreSQL の screened_ip_addresses テーブルを直接確認しても、該当 IP アドレスのレコードは見当たりませんでした。
考えられる手が尽きてきました。IP アドレスをブロックする他のセクションは存在しないでしょうか？あるいは、Screened IPs に追加される IP アドレスは非常に短時間のみで、報告後に（数時間後など）確認する頃には消えてしまっているのでしょうか？
念のため申し上げますと、私たちは Screened IPs に IP アドレスを手動で追加したことはありません。API を通じて誰かのアカウントを閉鎖した際に自動的に追加されているようです（上記リンク参照）。ドキュメントに記載されている block_ip: false パラメータを使用しても、この現象を止めることができていません。
pfaffman
2021 年 6 月 4 日午前 12:39
2
つまり、あなたが解決すべき課題はこれですね。Discourse API のリバースエンジニアリング方法 を確認することをお勧めします。
IP が「スクリーニング済み IP」に追加される問題は、ここで報告しようとしているものとは 別の問題 です。SSO 経由でアカウントにログインできないメンバーが、スクリーニング済み IP によってブロックされていないにもかかわらず、「IP アドレスがブロックされています」と表示されてログインできない事象が発生しています。
IP アドレスをブロックする可能性がある「スクリーニング済み IP」以外の場所にはどのようなものがあり、確認すべきでしょうか？
「スパマーとして削除」機能を呼び出しているようですね。これにより、IP アドレスとメールアドレスが自動的にブロックリストに登録されます。そのコードを見直すことをお勧めします。「スパマーとして削除」ではなく、UI に従って「通常の削除」を行う必要があります。
それは事実かもしれませんが、ユーザーの削除方法についてはこちら で議論されています。
これが別の問題かどうかはわかりませんが、スクリーニング済み IP のセクションにある「一致数」列がすべての エントリで 0 件を表示していることに気づきました。そのテーブルのエクスポートを確認しても、すべての IP の一致数が 0 であることが確認できました。しかし、毎日 SSO を通じて IP アドレスによるログインブロックが発生しています。
一方、スクリーニング済みメールを見ると、ほとんどのエントリで一致が確認できます。そこにも IP アドレスの列があります……そこで原因を見つけられたかと思いましたが、ブロックされている IP アドレスのいずれもそこに記載されていませんでした。
これは数分前の /logs からのものです：
こちらがスクリーニング済み IP の検索結果です：
スクリーニング済みメールも確認しましたが、ログインをブロックされたアカウントの IP アドレスもメールアドレスもそこに存在しませんでした。
他にどこを確認すべきか、何かヒントはありますか？
ここでの問題の特定ができたと思います（結局は私たちの側の問題でした）が、いくつかのバグを報告する必要があります。ただし、このスタックにはあまり慣れていないため、誰かがより詳しく見てくれることを願っています。
まず、原因についてです。screened_ip_addresses データベーステーブルを直接確認したところ、本来ブロックすべきではない 2 つの全体のブロック（176.59.0.0/16 と 109.252.0.0/16）がブロックされていることが分かりました。これらがどのように追加されたのか正直分かりません。この 2 つのエントリは 2 月以来存在していました。Discourse の管理画面には、/16 ブロック全体を一度にブロックするためのボタンなどあるのでしょうか!?
とにかく、これが初期の問題の原因である可能性が高いです。しかし、Discourse チームが調査した方が良いいくつかの問題が残っています。これが特に解決を難しくさせた要因です。
何らかの理由で、ブロックされた範囲が「Screened IPs」の一覧に表示されません。これらを見つけるには、直接データベースを確認する必要がありました。ただし、「176.59」や「109.252」で検索すると表示されます。/admin/logs/screened_ip_addresses に結果数の制限が適用されているのでしょうか。
エクスポートでは、これらは 176.59.0.0 および 109.252.0.0 として表示され、ブロック情報が一切示されていません。デフォルトの範囲（127.0.0.0/8、10.0.0.0/8 など）についても同様で、エクスポートファイルにはマスクが表示されません。
これらのエントリはユーザーをブロックしているにもかかわらず、match_count の値は 0 で、last_match_at は空のままです（テーブル全体で）。これは意図された動作でしょうか？おそらく allow の一致はカウントしたくないのでしょうが、ブロックがカウントされていない場合、これらのカラムは使用されていない、あるいは不要に見えるかもしれません。あるいは、SSO によるログインではこれらの一致がトリガーされないのでしょうか。
またしても言いますが、API から「スパマーとして削除」を呼び出している可能性が非常に高いです。関連する IP アドレスからのスパマー削除が一定数に達すると、IP アドレスの禁止範囲が自動的に拡大 します。おそらくあなたが目撃しているのはそれだと思われます。
はい、その通りです。もしかすると、あなたが長い間「スパマーとして削除」を続けてきたことが、フィルタリングされた IP リストがこれほど巨大になっている理由かもしれません。それは望ましくありません。
「ブロックして削除」ではなく、「削除のみ」を選ぶべきです。しかし、あなたが投稿したほぼすべての内容が、API 経由で「ブロックして削除」を呼び出していることを示す証拠となっています。
問題は使用したエンドポイントではなくパラメータでした。API はブール値を文字列の ‘true’/‘false’ として期待しており、私はそれに気づいていませんでした。
上記で触れられている他のバグが修正されるべきかどうかは不明ですが、それらがなければこの件はクローズできます。ありがとうございます。
