コンテンツセキュリティポリシーを緩和する方法

こんにちは

Discourse を、設定された公開ドメイン名を経由せずにテストしたいと考えています。例えば、Discourse が https://uat.mysite.com としてインストールおよび設定されている場合、ブラウザで https://uat.mysite.com を開くことができます。これにより、ブラウザは内部ネットワークからパブリックインターネットに出てドメイン名をパブリック IP アドレスに解決し、パブリック IP アドレス経由でページを読み込みます。

サーバーの内部 IP アドレス(例:以下の 192.168.1.2)で Discourse にアクセスしようとしましたが、当然ながら Content Security Policy のために読み込めませんでした。エラーは以下の形式で表示されます。

スクリプト 'http://192.168.1.2:12000/assets/locales/en-a9c88e45eb548bd7c807aecfd37d218891e213b5c1fd254857e0f16c72d73996.js' の読み込みが拒否されました。これは、以下の Content Security Policy ディレクティブに違反しているためです: "script-src http://uat.mysite.com/logs/ http://uat.mysite.com/sidekiq/ http://uat.mysite.com/mini-profiler-resources/ http://uat.mysite.com/assets/ http://uat.mysite.com/brotli_asset/ http://uat.mysite.com/extra-locales/ http://uat.mysite.com/highlight_js/ http://uat.mysite.com/javascripts/ http://uat.mysite.com/plugins/ http://uat.mysite.com/theme-javascripts/ http://uat.mysite.com/svg-sprite/ 'sha256-rwfDVOTzygQmkOwFNAeX564B66beHoel4+gRLgQUgHg='". 'script-src-elem' が明示的に設定されていないため、'script-src' がフォールバックとして使用されていることに注意してください。
                                           --------------------------------------------
                                          |                                             |
                                           ------------
uat.mysite.com は 98.1.2.3 に解決されます -->   |  パブリック IP |  Discourse が実行されているサーバー。     |
                                          |  96.1.2.3. |\
                                           ------------                                 |
                                          |                                             |
                                          |                  ----------------           |
                                          |                  |  プライベート IP  |           |
                                          |                  | 192.168.1.2  |           |
                                           --------------------------------------------
                                                                         ^
                                                                         |
192.168.1.2   ------------------------------------------------------------

サーバーの内部 IP アドレスから Discourse にアクセスしたい理由は、テストを行いたいからです。例えば、ネットワークがインターネットに接続されている必要がないテストを行いたい場合などです。または、DNS を設定せずにラップトップやビルドサーバーにテストインスタンスをインストールしたい場合などです。

/etc/hosts にカスタムエントリを設定することでこれを上書きできると思いますが、CSP を無効にするか、テストを許可するために他のソースを信頼するように設定する方法はありますか?

「いいね!」 1

その後、そのアドレスをディスコースサーバーのローカルIPに解決するようにマシンを設定してください。これには多くの方法がありますが、OSに依存するため、Google検索にOSを含める必要があります。(Linuxでは、そしてMacもそうだと思いますが、/etc/hostsを編集するだけで済みます。)

「いいね!」 1

CSP のせいで、/etc/hosts を試しましたが、同じエラーが発生しています。開発者がラップトップ内で何もかもできるように、DNS ソリューションをセットアップする必要なく、この機能をオンにするフラグや設定があると思っていたのですが。 macOS で開発用に Discourse をインストールする - ドキュメント / 開発者 - Discourse Meta を見ると、IP アドレスではなく http://localhost:3000 で動作するものにブートストラップされるようです。

私が抱えている課題は、Discourse をインストールするための自動化があり、同じプロセスを使用して開発、UAT、および本番環境の両方をセットアップしたいと考えていることです。また、開発環境がインターネットからアクセス可能である必要はないと考えていますが、現在のところ、適切な FQDN を解決する必要があるため、それが要件のようです。ユースケースは複数ありますが、その 1 つは、開発環境で Discourse のアップグレードを毎週自動化し、何も問題が発生しないかを確認するために多数のテストを実行することです。

いずれにしても、IP アドレス経由での直接アクセスを許可するという要件を緩和する方法があれば、知りたいです。そうでなければ、おそらく唯一の解決策は、小規模な DNS サービスをセットアップし、ラップトップがカスタム DNS サービスを使用するようにポイントすることですが、それは少し面倒なようです。

content security policy というサイト設定があります。チェックを外して保存すると、CSPを無効にできます。

これは本番環境インスタンスで行わない限り、問題ありません。

「いいね!」 3

それは良い考えではありません。決してうまくいきません。開発環境は、プリコンパイルされたアセットや、開発を不可能にするその他の多くのものがあるため、必然的に異なります。プラグインを開発しているのでない限り、開発環境はまったく必要ありません。したがって、その場合は、開発環境をDockerインストールにすることができます。ここでは開発環境とは呼ばれません。

標準のインストールで説明されているように、ステージング環境と本番環境をDockerを使用して起動したいと考えています。

「いいね!」 3

こんにちは!私は定期的にこれを Docker インストールで行っています。本番環境で標準の Docker インストールを使用していると仮定すると、受け入れテストでも同じものを使用するはずです。開発と Docker のインストールの間には、デプロイ時に問題となる可能性のある(設定、gem および JS パッケージのバージョンなど)多くの違いがあります。

Docker インストールはデフォルトで HTTPS を使用し、強制します。コンテナテンプレートをカスタマイズしない限り(これはいくつかの隠された複雑さがあることがわかりました)、別のサイト設定で HTTPS 強制を無効にすることができます。

これは、「ローカル Docker インストールでセキュリティを緩和する」ための私のスニペットであり、本番環境に移行する前に簡単に元に戻すことができます。

SiteSetting.content_security_policy = false
SiteSetting.force_https = false

その後は、ブラウザが http://uat.mysite.com で Docker コンテナのポート 80 を見つけられるかどうかの問題です。https の代わりに http を使用することに注意してください。

そのためには、@pfaffman/etc/hosts のトリックが最適です。各 OS の詳細はこちらにあります。

「いいね!」 2