Hello,
I tried using Force https and it seemed to work for me except it was causing login problems. However, the logos are loaded using http by default. They should use the // protocol and let the browser decide which one to use, right? Or maybe there is another solution I’m missing?
Thanks
Hi Eddie,
What version of Discourse are you running? In recent versions logos are uploaded via site settings, instead of being linked using a URL, so this should no longer be an issue.
Hi Joshua, We recently upgraded to v2.2.5. During the previous upgrade, before force https, I believe I deleted the post where the logos were uploaded and switched to the site settings. Everything was fine. Then with v2.2.5, I can’t get rid of the http:// part without force https. I tried reuploading, the wizard, even modifying the images so their hash was different. No luck
Sorry, now I’m confused. Is force_https enabled or not? Is there any possibility you’re overriding the uploaded logos via themes? If your force_https is enabled, and your logos are served via site settings, there should not be a mixed content warning. Are you able to share a link to your site so I can take a look?
It was enabled, thought the upgrade was over. Then our QA reports that logins are not working. so we disabled force https for now. You can test here //forum.y8.com
I checked the themes and didn’t spot anything that might cause this https problem. We mostly use stock, though it is an old stock theme.
force_httpsが無効な場合、これをテストできません。アセットをhttpではなくhttpsで提供されるようにするため、この設定に依存しています。ログインの問題について、SSOを使用されているようですので、プロバイダーからのSSOリダイレクトがhttp://ではなくhttps://でサイトへリンクされていることを確認してください。force_httpsを再度有効にしたら、再度確認いたします。
This forum is using the oauth2 basic plugin. Maybe there is a problem with that, might require a version roll back. Not sure yet. I did check the settings, all addresses were using https, so no obvious problem there.
私も同様の問題に直面しています。
ロゴと大きなアイコンが HTTP で読み込まれており、これが混合コンテンツの原因となっていることを発見しました。force_httpsを有効にするとこの問題は解消されましたが、ログインができなくなり、リダイレクトループが発生しました。このオプションを無効にすると、ログインが再び可能になります。
なぜこのようなことが起こるのでしょうか？
また、なぜ他のすべてのアセットは正しく HTTPS で読み込まれているのに、この 2 つの画像だけが HTTP で読み込まれているのでしょうか？
ログイン方法は何ですか？ローカル（ユーザー名とパスワード）でのログインではないと推測されますが、合っていますか？
インストールの前面にプロキシやその他のサービスはありますか？
別の Web アプリケーションを介して SSO を使用しています。
nginx がリバースプロキシとして使用されています。
nginx はどのように設定されましたか？
Nginx はすべての HTTP リクエストを HTTPS にリダイレクトしているため、そもそも HTTP でコンテンツを読み込むことはできません。
まず、SSO 設定を確認し、ユーザーがどこにリダイレクトされるか、およびどのオリジンを許可しているかを確認することをお勧めします。SSO 設定内のすべての URL が https:// を使用していることを確認してください。また、これは Nginx の問題である可能性もあります。複数の変数が絡んでいるため、ここでのデバッグは難しいでしょう…
私もここで報告されている方々と同じ問題に直面しています。また、この スレッド でも同様の報告があります。
この問題は SSO の実装やウェブサーバーとは無関係です。私の場合、http リクエストが https にリダイレクトされ、それがリバースプロキシを介して送信されます。force_https を false に設定し、ユーザーを https://discourse.fqdn.top/session/sso_login?sso=PAYLOAD&sig=SIGNATURE にリダイレクトすると、SSO は完璧に動作します。これにより、SSO 部分もプロキシも正常に機能していることがわかります。force_https を true に切り替えると、問題が発生します。既存のセッションがある場合、force_https を true に変更しても Discourse を問題なく使用できます（さらに、この問題がリバースプロキシとは無関係であることを裏付けています）。force_https を false のままにしておくことはできません。ロゴの表示が崩れるだけでなく、Chrome が http と https のアセットが混在していることを警告（アドレスバーに「このページは安全ではありません」という小さなアラートが表示）するためです。
あなたの nginx 設定はどのようになっていますか？また、X-Forwarded-Proto ヘッダーは設定されていますか？
ありがとうございます。はい、その対応で問題が解決しました。つまり、実際にはプロキシに関連していたのですね。コンテンツが読み込まれていたため、違うと推測してしまい、申し訳ありません。
参考までに、私は nginx ではなく Apache をリバースプロキシとして使用しています。関連する設定行は以下の通りです。
RequestHeader set X-Forwarded-Proto "https"
ProxyPass / http://[::1]:2045/ retry=10
ProxyPassReverse / http://[::1]:2045/
最初の行を追加することで問題が解決しました。
こんにちは、
また持ち出して申し訳ありませんが、Firefox で混合コンテンツの警告を消すことができていません。面白いことに、私の設定はそれなりに似ているのですが… 誰かアイデアや改善策をご提供いただけないでしょうか。Apache ディレクティブの専門家ではありませんが、ある程度は理にかなっていると思います。
当社は、多くの「通常」のドメインを運用しているサーバー上で、ISPConfig を使って Let’s Encrypt の証明書を管理しつつ、Apache をリバースプロキシとして Docker 上の Discourse をホストしています。
ISPConfig による Apache ディレクティブでリバースプロキシを設定しました。現在の設定は以下の通りです：
ProxyPreserveHost On
ProxyPass /.well-known/acme-challenge !
RequestHeader set X-Forwarded-Proto "https"
ProxyPass / unix:///var/discourse/shared/standalone/nginx.http.sock|http://localhost/
ProxyPassReverse / unix:///var/discourse/shared/standalone/nginx.http.sock|http://localhost/
RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://sub.domain.de$1 [R,L]
それでも Firefox で混合コンテンツの警告が表示されます。まず試したのは、設定で「SSL 強制」オプションを有効にすることでした。その結果、ログインができなくなりました。当社はユーザー名とパスワードでの認証のみを行っています。そこで、以下の修正を試みました。
これで「SSL 強制」も有効になり、ログインも可能になりました。しかし、Firefox からはまだ混合コンテンツの警告が表示されます。コンソールには以下のように表示されています：
および
これらが HTTP で配信されていると… -branding 画像を sub.domain.de/wizard を使って再アップロードしても、この問題は解決しません… HTTPS で最適化された画像を再レンダリングさせる方法はありますか？リバースプロキシの設定に何か問題があるのでしょうか？
さらにサポートしていただければ大変助かります。Let’s Encrypt（Apache 経由で処理）による SSL 強制を伴うリバースプロキシの設定は多岐にわたり、Discourse 内蔵の設定ではなく Apache で対応しているため、 drowning しているような感覚です。また、Apache をリバースプロキシとして使用し、今回と同様の Let’s Encrypt 設定を採用している人は少ないのかもしれません。あるいは、単に私たちが設定を間違えているだけかもしれません。
繰り返しになりますが、どのようなヒントでもいただければ幸いです。あらかじめ感謝申し上げます！
Railsコンソールから SiteIconManager.ensure_optimized! を実行してみてください。
すばらしい、こんなに早く回答が来て感謝します！
さて、その間のことですが…時間が経過して何らかの処理が実行されたことがきっかけだったのかはわかりません。最初の投稿を送信した後、ウィザードではなく管理設定（ブランディング）からファビコンとアップルアイコンの画像を再度アップロードしました。そして、ログインやその他の機能が正常に動作しているか確認するためにタブを閉じようとしたその瞬間に、なんと！Firefox の混合コンテンツエラーが消えていたのです！
すごい！
@RGJ さん、やはり本当にありがとうございます。これで最適化された画像の再レンダリングの問題も解決したはずです。この問題は、時間の閾値によって自動的に発生したのか、それともウィザードではなく管理パネルから画像を再度アップロードしたことがきっかけだったと思いますか？
改めてありがとうございます。特に @alphanoob1337 さん、これでついに動作するようになりましたね！
月曜日に気持ちよく退社できるなんて、なかなか不便な状況から解放されて嬉しい気分です 
