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

Support
1

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.

image
image.png1907×60 8.92 KB

1 Like
2

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

3 Likes
3

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

Yes it is.

1 Like
4

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)

3 Likes
5

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).

6

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.

7

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

8

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)…

9

Please, any help about this topic?

10

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

1 Like
11

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.

12

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!

1 Like