こんにちは。
最近、Discourse/2.9.0.beta3 から Discourse/2.9.0.beta14 最新バージョンに Discourse インスタンスをアップグレードしました。
Discourse の Webhook イベントが現在機能しなくなっています。
これは設定です。
ペイロード URL: http://server-name:port/rest : これは、定義した内部 REST API サービスです。
この値を保存しようとすると、次のエラーが発生します。
「エラーが発生しました: ペイロード URL はブロックされた IP または内部 IP に解決されるため、使用できません」
ペイロード URL: http://server-name:port/rest の同じ値は、Discourse/2.9.0.beta3 Discourse バージョンでは正常に機能していました。
最新バージョンの Discourse で何かが更新されたのでしょうか、それともバグでしょうか？
お知らせいただけますでしょうか。よろしくお願いします。
これは正しくないように聞こえます。Discourse がセルフホストされている場合、Webhook のペイロード URL は内部リソースである可能性があります。Webhook を処理するために内部で解決される URL またはアドレスを設定できなくなる理由がわかりません。変更があったようで、ユーザープロファイルで無効な/糟糕なウェブサイト URL が防止されています。その変更が Webhook ペイロード URL の検証にまで及んでいますか？
それは、Discourseの管理者がWebフックを使用して、自分のものではないネットワーク上の内部リソースを発見または攻撃する可能性があるセキュリティ上の問題にもなり得るからです。
はい、これを Feature に移動しました。これは、内部ネットワークに関する情報を取得するために使用できます。特定のインスタンスの動作を調整するためのいくつかのノブがあります。
セルフホストインスタンスもこれの影響を受けています。Webhook を受信するサービスは内部 Docker ネットワークでのみホストしたいと考えており、外部から到達可能である必要はありません。
内部 Webhook を許可する方法はありますか？
私の理解が正しければ、内部 Webhook は、サーバー管理者ではない Discourse 管理者がネットワーク内部をスパイできないように許可されていません。しかし、これはセルフホストインスタンスの問題ではありません。当社の Discourse 管理者は、いずれにしても内部構造について知っているでしょう。
app.yml 設定に内部 Webhook を許可する設定を追加するか、内部ドメイン/IP のホワイトリストを提供するよう提案します。これにより、サーバー管理者（Discourse 管理者ではない）が、内部ネットワーク用の Webhook を誰が使用できるかを引き続き制御できます。
WebHooks がブロックされている SSRF 保護メカニズムによって尊重され、特定の内部ホストのブロックを解除できる設定を見つけました。
Webhook で許可される内部ホスト名を指定するには、allowed_internal_hosts 設定を使用します。