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.
I have a similar problem here:
After finding that the logo and the large icon are loaded via http causing mixed content, enabling force_https fixed this. But login wasn’t possible anymore leading to a redirect loop. After disabling this option, login works again.
Why is this happening?
And why are only those two images loaded via http, while all other assets are loaded correctly loaded via https?
What is your login method? I’m guessing it’s not local (username/password) login?
Is there any proxy or other service in front of your installation?
I’m using SSO via another web application.
nginx is used as a reverse proxy.
How was nginx configured?
Nginx is redirecting all http requests to https, so it shouldn’t be possible to load content via http anyway.
My first thought would be to double check your SSO config to see where it is directing users, as well as what origins it accepts. Make sure everything within the SSO config is using https://. It’s also possible that this is an Nginx issue. Going to be hard to debug here with multiple variables…
I have the exact same issue as the people reporting here and in this thread.
The issue is not to related to the SSO implementation nor the webserver: In my case http requests are redirected to https, which is then sent through the reverse proxy. SSO works perfectly if I redirect the user to https://discourse.fqdn.top/session/sso_login?sso=PAYLOAD&sig=SIGNATURE and force_https is false. Showing that both the SSO part and proxy work perfectly well. Only when I switch force_https to true, it stops working. When I have a pre-existing session, I can change force_https to true and use discourse without any issues (further cementing the point, the issue is not related to the reverse proxy). Leaving force_https false is not an option because it breaks logos and Chrome is not happy, when assets from http and https are mixed (it shows a small alert in the address bar, that the page is not secure).
What does your nginx config look like and do you have an X-Forwarded-Proto header in it?
Tahnk you so much. Yes; that solved the issue. So it was related to the proxy. Sorry for assuming otherwise, just because the content was loaded.
For the sake of completeness I am using Apache as ReverseProxy and not nginx. Here are the relevant configuration lines:
RequestHeader set X-Forwarded-Proto "https"
ProxyPass / http://[::1]:2045/ retry=10
ProxyPassReverse / http://[::1]:2045/
Adding the first line solved the issue.
Hey there,
sorry to bring this up again. But in fact I am not getting rid of my mixed content warnings in firefox. The funny thing is, I have quite the same setup … more or less. Maybe someone can bring in some ideas or improvements. Wenn I am not that kind of a big expert in Apache directives. But it makes sense for me – a bit at least.
We have discourse in docker on Apache through RevereseProxy and handle the Lets Encrypt certs with ISP Config as we have a lot of “normal” domains running on our server.
We set up the Reverse Proxy with Apache directives by ISP Config. Our Setup looks like this:
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]
We still have mixed content warings in firefox. What I tried is to set force ssl option in settings. As a first effect we could not log in anymore. We just authenticate by user and pw. So I tried the fixe mentioned
Well, force ssl and login is possible now. But we still have firefox showing mixed content warnings. Console says:
and
are delivered by http … We also tried to repuload those branding images using sub.domain.de/wizard but we still are running in this issues … is there a way to … I do not know force to re-render the optimized images using https? Is something wrong with our Reverse Proxy setup?
I would so thankful on further assistance here. It is like a ocean of possible Reverse Proxy configurations with forcing ssl by Lets Encrypt (handled by) Apache (and not not build in discourse config) so I think I drowning. And I have the feeling that there are just a few people using Apache as a host with Reverse Proxy and that Lets Encrypt setup we are using. Or we are just the ones configuring it wrong.
Well as I said, I would appreciate any hints. Thanks in advance!
Try SiteIconManager.ensure_optimized! from a rails console.
Wow such a fast answer! Thanks a lot.
Well meanwhile … I do not know if it was triggered by having time let pass so that something happened. But what I did after submitting my first post I just uploaded those to images (favicon and apple icon) again not using the wizard but the admin settings (branding) and just in that moment I wanted to close the tab just rechecking if login and everything works now correctly … guess what. The firefox mixed content errors where gone!
Wow!
Well @RGJ still thank you very much, I guess this would also fix the rerendering of the optimized images. Do you think it got fired in the meantime because of a time threshold or by uploading the images again using admin panel, not the wizard.
Thanks again, especially @alphanoob1337 for finally getting this to work!
Wow thats pretty inconvenient for a Monday leaving the desk with pleasant happy feeling 
