I just enabled force_https on my Discourse installation. The https termination is handled by a reverse proxy in front of it. Enabling force_https switches most of Discourse’s internal links to https, but not those for already existing images and specifically favicons and logo. Now accessing my site over https causes a mixed content warning due to the non-https images being included.
The links can be made to be https by re-uploading the images or by executing SiteIconManager.ensure_optimized! from the rails console, so apparently the link is being cached somewhere and not updated when force_https is changed.
Discourse should update the links to its uploaded images (and probably all uploads) when force_https is toggled. Or even better would be to not include the scheme in those links, though I don’t know if that is possible.
I build docker images (split web_only and data) with the discourse_docker repository, and I run the images in a Kubernetes cloud behind a proxy that handles https termination. The discourse container only listens on port 80 and I did not enable the ssl and letsencrypt templates in the container configuration file. It appears that the letsencrypt template is what sets force_https to true, so for my setup it was not enabled by default.
This is an issue even if the proxy is sending the X-Forwarded-Proto header and all.
Toggling the force_https site setting will not update the logo URL protocol until the icon_manager cache has been cleared. Adding force_https to the watched settings for the icon manager is probably the easiest solution.
Right! If you do a standard install, it’s set automatically, which is why I suspected that this wasn’t a standard install.
I’m pretty sure that on the GKE site that I manage it’s set with a DISCOURSE_FORCE_HTTPS environment variable and it works as expected. But it was a long while ago that I set that up, so I could be forgetting something.
