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.
With force_https disabled, I can’t test this. We rely on that setting to ensure assets are served over https, not http. Regarding the login issue, it appears you’re using SSO, so ensure the SSO redirect from your provider links to your site via https://, not http://. Once you’ve re-enabled force_https I can take another look.
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를 통해 올바르게 로드되는 반면, 이 두 이미지만 http를 통해 로드되는 걸까요?
로그인 방식이 무엇인가요? 로컬(사용자 이름/비밀번호) 로그인이 아닌 것 같은데요?
설치 환경 앞에 프록시나 다른 서비스가 있나요?
다른 웹 애플리케이션을 통해 SSO를 사용하고 있습니다.
nginx를 리버스 프록시로 사용하고 있습니다.
nginx는 어떻게 구성되었나요?
Nginx가 모든 HTTP 요청을 HTTPS로 리다이렉트하므로, 어쨌든 HTTP를 통해 콘텐츠를 로드하는 것은 불가능합니다.
가장 먼저 SSO 설정을 다시 확인해 보세요. 사용자가 어디로 리디렉션되는지, 그리고 어떤 오리진(origin)을 허용하는지 확인하는 것이 좋습니다. SSO 설정 내의 모든 항목이 https://를 사용하도록 확인하세요. 또한 Nginx 문제일 수도 있습니다. 변수가 여러 개라서 여기서 디버깅하기가 쉽지 않을 것 같습니다…
여기서 보고하신 분들과 이 스레드에서 보고하신 분들과 정확히 동일한 문제를 겪고 있습니다.
이 문제는 SSO 구현이나 웹서버와는 무관합니다. 제 경우 HTTP 요청이 HTTPS로 리디렉션된 후 리버스 프록시를 통해 전송됩니다. 사용자를 http**s**://discourse.fqdn.top/session/sso_login?sso=PAYLOAD&sig=SIGNATURE로 리디렉션하고 force_https를 false로 설정하면 SSO가 완벽하게 작동합니다. 이는 SSO 부분과 프록시가 모두 완벽하게 정상 작동한다는 것을 보여줍니다. force_https를 true로 전환할 때만 작동이 중단됩니다. 기존 세션이 있는 경우 force_https를 true로 변경해도 Discourse를 아무 문제 없이 사용할 수 있습니다(이는 문제가 리버스 프록시와 무관하다는 점을 더욱 확증합니다). force_https를 false로 두는 것은 옵션이 될 수 없는데, 이렇게 하면 로고가 깨지고 Chrome이 HTTP와 HTTPS 자산이 혼합된 페이지에 대해 불만을 제기하기 때문입니다(주소 표시줄에 페이지가 안전하지 않다는 작은 경고가 표시됩니다).
nginx 설정이 어떻게 되어 있나요? 그리고 X-Forwarded-Proto 헤더가 포함되어 있나요?
정말 감사합니다. 네, 그 방법으로 문제가 해결되었습니다. 결국 프록시와 관련된 문제였네요. 콘텐츠가 로드되었다는 이유만으로 그렇지 않다고 가정해서 죄송합니다.
참고로 저는 nginx가 아니라 Apache를 ReverseProxy로 사용하고 있습니다. 관련 설정 줄은 다음과 같습니다:
RequestHeader set X-Forwarded-Proto "https"
ProxyPass / http://[::1]:2045/ retry=10
ProxyPassReverse / http://[::1]:2045/
첫 번째 줄을 추가하니 문제가 해결되었습니다.
안녕하세요,
다시 이 문제를 언급하게 되어 죄송합니다. 하지만 실제로 Firefox에서 혼합 콘텐츠(mixed content) 경고가 사라지지 않고 있습니다. 재미있는 점은 제 환경 설정이 거의 비슷하다는 것입니다 … 대략적으로요. 누군가 아이디어나 개선 사항을 제시해 주시면 좋겠습니다. 저는 Apache 지시문(directives)에 대해 그다지 전문가가 아니거든요. 하지만 제 생각에는 어느 정도 합리적으로 보입니다.
저희는 Docker에서 Discourse를 실행하고 있으며, Apache를 통해 ReverseProxy로 처리하고 있습니다. 서버에서 많은 “일반” 도메인을 운영 중이므로 Lets Encrypt 인증서는 ISP Config로 관리하고 있습니다.
Reverse Proxy는 ISP Config를 통해 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에서 혼합 콘텐츠 경고가 나타납니다. 제가 시도해 본 것은 설정에서 force ssl option을 활성화하는 것이었습니다. 첫 번째 결과로 더 이상 로그인할 수 없게 되었습니다. 저희는 사용자 이름과 비밀번호로만 인증합니다. 그래서 아래에서 언급된 수정 방법을 시도해 보았습니다.
자, 이제 force ssl이 적용되어 로그인도 가능합니다. 하지만 여전히 Firefox에서 혼합 콘텐츠 경고가 표시됩니다. 콘솔에는 다음과 같이 표시됩니다:
그리고
이 이미지들이 http로 전달되고 있습니다 … 또한 sub.domain.de/wizard를 사용하여 해당 브랜딩 이미지를 다시 업로드해 보았지만 여전히 동일한 문제를 겪고 있습니다 … https를 사용하여 최적화된 이미지를 다시 렌더링하도록 강제하는 방법이 있을까요? 저희 Reverse Proxy 설정에 문제가 있는 건가요?
여기서 더 이상의 도움을 주시면 정말 감사하겠습니다. Lets Encrypt(Apache가 처리하며, Discourse 내장 설정이 아님)를 통해 SSL을 강제하는 Apache Reverse Proxy 설정의 가능성은 무한대처럼 느껴져서 거의 drowning(수몰)된 기분입니다. 그리고 Apache를 Reverse Proxy로 사용하는 호스트로, 그리고 저희가 사용하는 Lets Encrypt 설정을 사용하는 사람은 극소수일 것 같은 느낌이 듭니다. 아니면 저희가 잘못 설정하고 있는 것일 수도 있고요.
말씀드린 대로, 어떤 힌트든 감사히 받겠습니다. 미리 감사합니다!
Rails 콘솔에서 SiteIconManager.ensure_optimized!을 실행해 보세요.
와, 정말 빠른 답변이네요! 정말 감사합니다.
그동안 … 시간이 지나면서 무언가가 발생해서 그런 건지 정확히 모르겠습니다. 하지만 첫 게시글을 올린 후 제가 한 일은 마법사(wizard) 대신 관리자 설정(브랜딩)을 통해 해당 이미지들(파비콘과 애플 아이콘)을 다시 업로드한 것이었습니다. 그리고 바로 그 순간, 로그인과 모든 기능이 이제 제대로 작동하는지 다시 확인하려고 탭을 닫으려던 참이었는데 … 어땠을까요. 파이어폭스의 혼합 콘텐츠(mixed content) 오류가 사라져 있었습니다!
와!
그래도 @RGJ 님, 정말 많이 감사드립니다. 최적화된 이미지의 재렌더링 문제도 이로 인해 해결되었을 것 같습니다. 시간이 지남에 따라 시간 임계값(time threshold) 때문에 발동된 건지, 아니면 마법사가 아닌 관리자 패널을 통해 이미지를 다시 업로드하면서 발동된 건지 어떻게 생각하시나요?
다시 한번 감사드리며, 특히 @alphanoob1337 님께는 드디어 이 문제를 해결하게 해 주셔서 정말 감사합니다!
월요일 아침에 이렇게 기분 좋게 자리에서 일어설 수 있다니, 정말 괜찮네요 
