Insecure fonts requests

Support

AI-generated summary

The discussion revolves around resolving an “Insecure fonts requests” issue on a fresh Discourse installation. silverdr reports a Mixed Content error due to fonts being requested over HTTP instead of HTTPS. After some investigation, Arkshine suggests enabling the force_https setting, which silverdr confirms resolves the issue.

However, silverdr and Stephen discuss why force_https is necessary, even when SSL encapsulation is handled outside the container. Stephen explains that it tells Discourse to rewrite requests, making it necessary for secure serving.

Hyan provides additional context on factors affecting asset URL protocols, including commenting out SSL templates and enabling force_https. silverdr clarifies that their setup uses a reverse-proxy and a Unix socket, which shouldn’t cause hardcoded HTTP schema in static URLs.

The discussion concludes that enabling force_https resolves the issue, but silverdr and others express that ideally, Discourse should not require this workaround and should use relative references or HTTPS by default.

1 
Mixed Content: The page at '<URL>' was loaded over HTTPS, but requested an insecure font '<URL>'. This request has been blocked; the content must be served over HTTPS

And 40 requests for fonts from discourse-fonts gem. This is a fresh installation where Postgres and Redis is run on a separate server inside local network and the connection is “socketed” but served to the outside over https of course. There are similar threads but no clear answer to me. Checking CSS points to wizard.scss (source-mapped). Any clues?

2

Did you enable the force https setting?

3

Most probably no. Where do I set it? And why should it be needed in the first place instead of having the CSS request static assets over https or relative references?

FWIW - on the outside facing webserver I do have the typical 301 set

Edit:

Found the setting based on this post, thank you @Arkshine

4

I’m unsure why you have an http link somewhere; https should be enforced regardless.

You can find in the search bar:

image
image861×193 6.81 KB

5

Well, me neither. I didn’t modify anything. Just the regular launcher build app These URLs seem to be in the processed CSS, which I obviously didn’t touch (nor the scss) in any way. I didn’t find anything https related in the app.yml either so.. don’t know. The force_https seem to work the problem around.

6

FORCE_HTTPS tells Discourse to rewrite requests.

It’s necessary even if you’re doing ssl encapsulation outside the container to avoid the issue you’re describing.

7

It depends how we define “necessary”. Currently it might be necessary to work around the actual problem, which is that compiled CSS files reference static assets explicitly using http schema. But IMHO this should not be necessary in the long run

8

Necessary as in it’s the purpose of FORCE_HTTPS - that’s how you tell Discourse that it’s being served securely and to rewrite links as such.

9

So what factors/conditions would impact the assets (JS/CSS) URL protocol HTTP/HTTPS?

  1. If you comment out below, and your site access from HTTP, then assets URL will be HTTP as well
  #- "templates/web.ssl.template.yml"
  #- "templates/web.letsencrypt.ssl.template.yml"

In this case, if you enable force_https you will end up with all assets URL error R_SSL_PROTOCOL_ERROR if you requested domain doesn’t install certificate. Then to avoid that you install certificate for that to resolve the SSL protocol issue

  1. If you instead install Discourse with above template uncommented, the site’s assets URL should be HTTPS along with your site base URL protocol. And more, the force https is invisible in admin UI.
10

As mentioned in the original post, in my case certificate and everything is correct and valid but all connections to the outside are handled by a reverse-proxy (nginx, obviously ;-), while connection to discourse goes over unix socket. Meaning I have
templates/web.socketed.template.yml
rather than any of those you mention. Still - this should not need to cause static URLs have hardcoded explicit http: schema