こんにちは、
当サイトはHTTPとHTTPSの両方で動作する必要があります。クッキー(_forum_session)を保護する必要があります。現在のクッキーにはHttpOnlyフラグのみがあり、Secureフラグが不足しています。Secureフラグも設定するにはどうすればよいでしょうか?
よろしくお願いいたします。
こんにちは、
当サイトはHTTPとHTTPSの両方で動作する必要があります。クッキー(_forum_session)を保護する必要があります。現在のクッキーにはHttpOnlyフラグのみがあり、Secureフラグが不足しています。Secureフラグも設定するにはどうすればよいでしょうか?
よろしくお願いいたします。
サイトは HTTPS のみで動作するように設定してください。
Discourse のコードを変更する方法はありませんか?
@mevaha さん
ウェブのトレンドは、長年にわたり HTTPS のみを使用することです。
以前はこれが問題でしたが、Let’s Encrypt (LE) などの組織が SSL 証明書を無料で提供し、証明書の管理を確実に行う仕組みを提供するようになったことで解消されました。
LE (certbot) を使用してサイトの証明書を設定すると、HTTP と HTTPS の両方が自動的に設定され、HTTP トラフィックは自動的に HTTPS に完全にリダイレクトされます。
もちろん、Discourse を HTTP のみで実行する方法を見つけることもできますが、Discourse の開発環境以外ではサポートされません。なぜなら、HTTPS がなければ、パスワードを含むすべてのユーザーログイン情報が暗号化されずにネットワークを介して送信されてしまうからです。これは本番環境ではサポートされていません。
次のように考えてみてください。HTTPS は、車でのシートベルト着用のようなものです。シートベルトなしで運転したい人々は、そのリスクを自己責任で行いますが、自動車メーカーはシートベルトのない車を製造しません。
Discourse についても同様です。Discourse は本番環境で安全に実行されるように設計されています。したがって、本番環境でサポートされる Discourse のバージョンは HTTPS です。
これが参考になれば幸いです。
もっとお役に立てず申し訳ありません。
@neounix さん、ありがとうございます。当社の問題点は、HTTPS 証明書がロードバランサーによって管理されており、Discourse とロードバランサーの間でポート 80 のみが開かれていることです。HTTP から HTTPS へのリダイレクトを試みましたが、成功しませんでした。Discourse のクッキー設定ファイルを共有していただけますでしょうか。
よろしくお願いいたします。
こんにちは @mevaha さん
その場合、おそらくロードバランサーの前に(またはロードバランサーの一部として)リバースプロキシが設置されていると思われます。
詳しく説明します。
リバースプロキシ(ロードバランサーがある場合はそれも含む)は、バックエンドの Discourse と HTTP を使用して通信します。
つまり、Discourse が HTTP のみで通信するというご指摘は正しいですが、それは外部世界ではなく、リバースプロキシに対してのみです。
流れは以下のようになります。
WEB ユーザー <-----> HTTPS <-----> リバースプロキシ <----> HTTP <----> ロードバランサー <----> DISCOURSE (DOCKER)
したがって、おっしゃる通り、Discourse の Docker コンテナをポート 80(HTTP のみ)として公開することは可能です。
ただし、Web 側のサイトでは、HTTPS リクエストを HTTP を使用してバックエンドへプロキシするリバースプロキシが必要です。
正しく設定されていれば、リバースプロキシ(およびロードバランサー)は、HTTP クッキーやヘッダーが正しく双方向に渡されるように保証します。
ご参考になれば幸いです。
さらにご質問があれば、お気軽にお尋ねください。
なお、アーキテクチャの正確な技術詳細をご提供いただければ、よりスムーズにお手伝いできます。私たちに水晶玉アプリがあるわけではありませんので ![]()
@neounix さん、どうもありがとうございます!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.