Moved site behind proxy, favicon and header not using https anymore

I’ve since moved my Discourse instance between servers, and is now running behind a reverse proxy with SSL termination.

However, the header image and favicon are not being requested over HTTPS and getting blocked. I tried setting “force https” to on, but this hasn’t helped.

1 Like

Is your proxy supplying an X-Forwarded-Proto header? (It should).

3 Likes

Is your proxy supplying an X-Forwarded-Proto header? (It should).

Yes it is.

1 Like

I had the same issue. I have a Discourse instance behind HAProxy with SSL termination. The fix is pretty simple, but not obvious:

  1. First make sure that “force https” is enabled in the settings (go to Settings and filter by “force https”).
  2. Go to Settings > Branding > and just re-upload your logos.
  3. Everything should use HTTPS now (be sure to hit your browser refresh button).

(I think this may be a bug in Discourse)

1 Like

Hello,
I’d like to come back along this issue. Actually, I’ve the same problem, and I can’t use force_https to true since there is no way to login… (Unknown error at the login).
How can we force the logo to be referenced with a https request and not http?
Shouldn’t it be easy?
So many thanks for your feedback (so many many hours spent on my side to fix this).

You’ll need to flip the force_https site setting via SSH-ing into the server and entering the Ruby command line. There are #howto topics on doing that here.

Thanks for your reply. I was certainly unclear in my message. Actually, I can manage to change force_https using rails command, no problem. So, just to be clearer:
Until the last upgrade I’ve performed a couple of days ago which needed to rebuild the docker container, I had a full running solution using force_https to true and with the following patch I had to apply in server section of nginx config file in order to get a valid login:

  if ($http_x_forwarded_proto = 'http'){
    return 301 https://$host$request_uri;
  }

And it worked. However, since the upgrade, the same patch did not allow me to log in again, getting the well known “Unknown error”
I got the following trace from the production log:

 Started POST "/session" for 193.134.222.4 at 2020-05-14 19:24:40 +0000
 Processing by SessionController#create as */*
 Parameters: {"login"=>"rossierd", "password"=>"[FILTERED]", "second_factor_method"=>"1", "timezone"=>"Europe/Zurich"}
 Can't verify CSRF token authenticity.
 Rendering text template
 Rendered text template (Duration: 0.0ms | Allocations: 1)
 Filter chain halted as :verify_authenticity_token rendered or redirected
 Completed 403 Forbidden in 2ms (Views: 0.7ms | ActiveRecord: 0.0ms | Allocations: 1101)

Provided that we have our discourse container running in a VM which is accessible through https.

Do you have any idea about the cause of this change of behaviour before and after the upgrade?

So far, I disabled force_https to false, everything runs well except the logo at the top left (brand logo) which does not appear correctly since it is referred using an http:// request…

By the way, here is the URL of our site: https://discourse.heig-vd.ch

In addition, I also found the following site setting which has the guilty URL:
SiteSetting.site_favicon_url (another is SiteSetting.site_apple_touch_icon) with the “http://…jpeg”.
However, it seems not obvious to change the value with a simple rail command as we do with force_https for example)…

Please, any help about this topic?

You set those via the setup wizard. Re-run the setup wizard and re-upload the images.

1 Like

I set the images like that. I re-launched the wizard, but with the same effect at the end :frowning:
I guess uploading the pictures does not impact on the way how they are referred; it is more a thing related to the web page generation.

Well, after so many unsuccessful attempts, I finally figured out how to have a valid login with force_https=true.

In the docker env., I patched /etc/nginx/conf.d/discourse.conf as follows:


location @discourse {
limit_conn connperip 20;
limit_req zone=flood burst=12 nodelay;
limit_req zone=bot burst=100 nodelay;
proxy_set_header Host $http_host;
proxy_set_header X-Request-Start “t=${msec}”;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https; # $thescheme; <-- What I modified
proxy_pass http://discourse;
}

And it only works in this section, at least with my environment.

Works great now!