その後、Discourse インスタンスを別のサーバーに移行し、現在は SSL 終端付きのリバースプロキシの背後で動作しています。
ただし、ヘッダー画像とファビコンが HTTPS でリクエストされず、ブロックされてしまいます。「HTTPS 強制」をオンに設定してみましたが、解決しませんでした。
![]()
その後、Discourse インスタンスを別のサーバーに移行し、現在は SSL 終端付きのリバースプロキシの背後で動作しています。
ただし、ヘッダー画像とファビコンが HTTPS でリクエストされず、ブロックされてしまいます。「HTTPS 強制」をオンに設定してみましたが、解決しませんでした。
![]()
プロキシが X-Forwarded-Proto ヘッダーを提供していますか?(提供する必要があります)
プロキシが
X-Forwarded-Protoヘッダーを提供していますか?(提供されているはずです)
はい、提供されています。
私も同じ問題に遭遇しました。SSL 終端を伴う HAProxy の背後に Discourse インスタンスを配置しています。解決策は非常にシンプルですが、直感的ではありません。
(これは Discourse のバグではないかと考えています)
こんにちは、この件について再度ご連絡いたします。実は私も同様の問題に直面しており、ログインできないため force_https を true に設定することができません(ログイン時に不明なエラーが発生します)。ロゴを HTTP ではなく HTTPS 要求で参照させるにはどうすればよいでしょうか?それは簡単だと思いませんか?ご回答を心よりお待ちしております(この問題を解決するために私自身、多くの時間を費やしました)。
SSHでサーバーに接続し、Rubyコマンドラインを入力して、force_https サイト設定を切り替える必要があります。その方法については、こちらに#howtoトピックがあります。
返信ありがとうございます。私のメッセージが不明確でした。実際、rails コマンドを使って force_https を変更するのは問題ありませんでした。より明確にするために申し上げますと、
数日前に docker コンテナの再構築が必要だった最後のアップグレードを行うまで、force_https を true に設定し、nginx 設定ファイルの server セクションに以下のパッチを適用することで、有効なログインが可能な完全な動作環境を構築していました。
if ($http_x_forwarded_proto = 'http'){
return 301 https://$host$request_uri;
}
これは機能していました。しかし、アップグレード以降、同じパッチを適用してもログインできず、よく知られた「Unknown error」が表示されるようになりました。
production ログから以下のトレースを取得しました。
Started POST "/session" for 193.134.222.4 at 2020-05-14 19:24:40 +0000
Processing by SessionController#create as */*
Parameters: {"login"=>"rossierd", "password"=>"[FILTERED]", "second_factor_method"=>"1", "timezone"=>"Europe/Zurich"}
Can't verify CSRF token authenticity.
Rendering text template
Rendered text template (Duration: 0.0ms | Allocations: 1)
Filter chain halted as :verify_authenticity_token rendered or redirected
Completed 403 Forbidden in 2ms (Views: 0.7ms | ActiveRecord: 0.0ms | Allocations: 1101)
当社の discourse コンテナは VM 上で動作しており、https を介してアクセス可能です。
アップグレード前後でこの挙動が変化した原因について、何かご存知でしょうか?
現時点では、force_https を false に無効化しましたが、左上のロゴ(ブランドロゴ)が http:// リクエストで参照されているため正しく表示されないという問題を除き、すべて正常に動作しています。
余談ですが、当サイトの URL は https://discourse.heig-vd.ch です。
さらに、以下のサイト設定にも該当する URL が見つかりました:
SiteSetting.site_favicon_url(もう一つは SiteSetting.site_apple_touch_icon)で、値が “http://…jpeg” となっています。
ただし、force_https の場合のように、単純な Rails コマンドで値を変更するのは明らかなようには思えません。
この件について、何かご助言はありますか?
それらはセットアップウィザードで設定します。セットアップウィザードを再実行し、画像を再アップロードしてください。
画像はあのように設定しました。ウィザードを再実行しましたが、最終結果は同じです ![]()
画像のアップロードは、それらが参照される方法には影響しないと思います。これはウェブページの生成に関連する問題のようです。
さて、多くの失敗の後、ついに force_https=true で有効なログインを行う方法を発見しました。
Docker 環境では、/etc/nginx/conf.d/discourse.conf を以下のようにパッチ適用しました。
…
location @discourse {
limit_conn connperip 20;
limit_req zone=flood burst=12 nodelay;
limit_req zone=bot burst=100 nodelay;
proxy_set_header Host $http_host;
proxy_set_header X-Request-Start “t=${msec}”;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https; # $thescheme; ← 変更した部分
proxy_pass http://discourse;
}
…
私の環境では、少なくともこのセクション内でのみ機能します。
これで完璧に動作しています!