SSOは登録をブロックするためにスクリーニング済みIPアドレスを使用しますか?

これはバグではなく、想定された動作であることを確認したく、質問いたします(おそらく想定通りだと思います)。

簡潔に説明すると、当サイトでは SSO を使用しています。メインのウェブサイトが登録を管理し、SSO 経由で Discourse 上のアカウントを承認します。設定においてユーザーの IP アドレスを渡すよう確認済みで、各ユーザーの管理ページを確認すればそれが確認できます。しかし、Screened IPs(スクリーニング済み IP)のブロックリストに IP アドレスを追加しても、今後のアカウント作成や承認の試みをブロックすることはできません。

私の推測では、SSO はそのチェックをバイパスしているのではないかと思いますが、これは正しいでしょうか?また、これが想定された結果でしょうか?

背景:
この質問をした理由は、当社のモデレーションチームが、非常に乱暴で悪用的なアカウントに対して IP アドレスをブロックリストに追加する追加作業を行っていますが、それが効果がないように見えることに気づいたためです。そのため、彼らはこの手順を継続する必要があるのか、それとも(スクリーニング済み IP リストが SSO 設定では何の役にも立たない場合など)無視してよいのかを私が調査したいと考えています。

SSO がサイトのログインを制御している場合、Discourse はそれを制御できず、制御することもできません。ログインを別のサーバーが制御している以上、Discourse 側で IP をブロックすることにはメリットがないと確信しています。

はい、私も同じように理解し、そのように感じています(そのため、私にとってはこれが当然のことだと思っています)。

自サイトでも確認してみました。Screened IPs リストに自分の IP アドレスを追加し、アクションを「Block」に設定すると、SSO 経由でのログイン時にその IP アドレスから新しいアカウントを作成することはできません。これは設計通りの動作です。コード上の該当箇所は以下になります:discourse/app/controllers/session_controller.rb at main · discourse/discourse · GitHub

興味深いですね… 確かに 8 月 20 日に登録 IP がブロックされた最近のアカウントがありましたが、そのユーザーは 9 月 15 日に正常にアカウントを作成しました。

編集:
しかし、ログには以下のような記録もあり、どうやら時折機能しているようです?

Verbose SSO log: IP address is blocked [ip_address_redacted]

add_groups: 
admin: 
moderator: 
avatar_force_update: 
...

もしかすると、VPNを使用していたか、別のコンピュータやモバイル端末を使っていたのでしょうか?

その時間差があれば、IP ブロックを迂回していることすら気づいていなかったかもしれません。

ああ、何が起こっているのか分かった気がします。カスタム SSO フィールドに「登録 IP」という名前のフィールドがあり、そこには確かにブロックされた IP アドレスが表示されています。しかし、Discourse に記載されている「最終 IP」は異なります。これは単なる推測ですが、VPN の使用を説明するものかもしれません。なぜ登録フィールドにはブロックされたアドレスが記録され、Discourse には異なるアドレスが記録されたのか、私には分かりません。