When setting up a new Discourse forum, I recently forgot to enable the force https setting
This isn’t just a security issue, it also prevents internal HTTPS links from getting the onebox treatment.
Because this setting should usually be enabled anyway, I’d suggest that the setup wizard should prompt to enable it, at least if the user is viewing the wizard over HTTPS. (In that case, I’d even consider enabling it without prompting…)
I suppose if they have HTTPS working already it wouldn’t harm to turn it on. I am afraid of users turning it on if they haven’t set it up properly yet as their site will become inaccessible.
If the user is accessing the wizard with HTTPS, silently enable the setting. HTTPS is obviously working.
If the user is not using HTTPS, ask him to try it out – click here to switch to HTTPS, if this doesn’t work out, come back here and click skip. If this works, congratulate him and enable the setting. If it doesn’t, leave it be.
(For extra points: If the user doesn’t have HTTPS set up when the wizard exits, seed a system topic in the internal category with instructions for setting up HTTPS.)
This may need to wait until all our hosted sites are https-on by default… but I agree that if the wizard senses HTTPS is already on then it should be turned on.
No, you should definitely enable the site setting in these cases! It affects many things like internal link handling and whether cookies are marked as secure.
I too had a fully HTTPS enabled site since forever but then this warning started to be pushed at me every week. It took me a long time to find the time to really dig into what the setting does.
I’m assuming that @ljpp is, like I was, more interested in what the force_https setting actually does rather than just knowing which magic checkbox to enable to make the noise go away.
My site has always had HTTP redirected to HTTPS so I could only assume that this setting is there to enable an HSTS header. After digging into the Discourse source code I confirmed that this is what it does and that it only affects the host name of the discourse site rather than the entire domain name.
Enabling the setting results in a header like this being included with every HTTPS response from the server:
I intentionally left the setting disabled until I could look at the source code because the setting isn’t documented and I was concerned that it might enable HSTS on my entire domain.
Interestingly this old Discourse PR fixed the very issue I was concerned about, although both it and this relevant stackexchange Q/A seem to interpret the HSTS spec incorrectly. If all user agents have incorrectly implemented the HSTS spec then there may have been nothing for me to worry about in the first place. I’ve recently posted a contradictory answer to stack exchange so it will be interesting to see if that triggers some authoritative confirmation of the situation from those that maintain and implement the spec.
In the mean time, I would say that if you’ve done all the usual checks to ensure your entire forum and all included content work fine over HTTPS then it is safe to enable this setting. I enabled it on my site a couple of months ago with no ill effects.