Canonical URL when using SSL Offloading


(Mark McDowall) #1

I’m not sure if this is a unique setup or not, but it seems like it would be fairly common in a larger organization, dare I say corporate.

I use CloudFlare for DNS and its caching capabilities (SSL is enabled). I have a front end firewall that does SSL Offloading; it has a wildcard SSL cert and all backend web servers only have HTTP enabled. The firewall will redirect any HTTP requests to HTTPS so SSL is forced for all requests.

My issue is the fact that canonical URL under each topic shows the HTTP URL instead of the HTTPS one, which I presume is due to fact that discourse doesn’t know about that the connection is HTTPS.

Example:

<link href="http://forums.domain.com/t/slug/2766" rel="canonical"/>

I also noticed that the RSS link on the same page does show HTTPS:

<link href="https://forums.domain.com/t/slug/2766.rss" rel="alternate" title="Post Title" type="application/rss+xml"/>

but other meta tags on the same page are HTTP:

<meta content="http://forums.domain.com/user_avatar/forums.domain.com/markus101/45/2.png" name="twitter:image"/>
<meta content="http://forums.domain.com/t/slug/2766/2" property="og:url"/>
<meta content="http://forums.domain.com/t/slug/2766/2" name="twitter:url"/>

Is there a way to get these URLs to be HTTPS without adding SSL directly to discourse, I’d like to avoid that to simplify SSL cert management.


(Sam Saffron) #3

You also have a “force_https” setting that can work around this issue. also you can set headers in NGINX …

Just changing those 2 links is not enough at all.


(Mark McDowall) #4

Are you referring to the “use https” setting on the Security settings tab?

It wasn’t clear to me if that altered the behavior in some way that required SSL on the docker instance, plus the warning scared me enough not to just play with the setting:

DO NOT ENABLE THIS UNLESS HTTPS IS ALREADY SET UP AND WORKING!

Does this force the base URL to always be HTTPS, even if it thinks it should be HTTP (like it does now)?

Which headers are you referring to? Not sure that we’re going to be able to set them as this doesn’t appear to be a feature on the firewall I’m using, unless you’re referring to nginx within the docker image.

I realize changing those two links aren’t enough, those were just examples of the issue and it also shows its not consistent.


(Sam Saffron) #5
- hooks:
  - after_code:
     ...... existing ......
  - after_web_config:
    - replace:
         filename: /etc/nginx/conf.d/discourse.conf
         from: $thescheme;
         to: https;
         global: true

after installing docker manager should do the trick in the container config


Switched to HTTPS, 1 of the rss link is http
(Mark McDowall) #6

Thanks, I added this to my app.yml, then rebuilt it with launcher.sh but the result is the same. Taking a peek inside the running docker image shows multiple places with https, which I assume was $thescheme before (I didn’t look before running it).

As a test I enabled another port for testing which URLs it would generate, I used port 2280.

Canonical:

<link href="http://forums.domain.com/t/retry-attempt-issue/2418" rel="canonical" />

RSS:

<link href="https://fw.domain.com:2280/t/slug/2418.rss" rel="alternate" title="Title" type="application/rss+xml" />

Meta:

<meta content="http://forums.domain.comv/letter_avatar/markus101/45/2.png" name="twitter:image" />
<meta content="http://forums.domain.com/t/slug/2418" property="og:url" />
<meta content="http://forums.domain.comv/t/slug/2418" name="twitter:url" />
```

The only URL that was actually affected was the RSS link and it used the hostname for my firewall because I used that instead of forums, but it also took into account the port, which is worth mentioning I think. I presume it is built on the client where it knows about the port, since the backend server never would with DNAT doing its job.

Thanks for the assistance on this, I'm trying to appease mighty google.

(Mark McDowall) #7

Turning on “use http” in security settings was the the solution, despite my concerns that it might require the HTTPS endpoint to be enabled within nginx it seems to change the scheme that is used to create those URLs.

Thanks again for the help and for the amazing software!


(eriko) #8

I realize this is an old post but I want to confirm this is still correct.

If your are using an SSL offloader/frontend (we are using Zen load balancer) and you want to have connections coming into port 80 redirected to use 443 by discourse you need to both change you web containers .yml file with

hooks:
  - after_code:
   ...... existing ......
  - after_web_config:
    - replace:
       filename: /etc/nginx/conf.d/discourse.conf
       from: $thescheme;
       to: https;
       global: true

and set use https in the settings. We could setup individual redirects in Zen, which we have, but it removes some the flexibility that we hoped to gain by using multisite.


(Kane York) #9

The other option is to have your SSL terminator set the X-Forwarded-Proto: header.


(eriko) #10

Sadly setting X-Forwarded-Proto is not yet available in Zen Balance 3 or 4. It is on some of the wish lists. I will take a shot at this method in the morning.

thanks


(Kane York) #11

Your replace command is basically saying “Ignore X-Forwarded-Proto, it’s always https”. So it works.


(eriko) #12

The replace will replace the instances of $thescheme on line 18 which will break the file. After manually changing the rest I still did not get any effect.

For the 6 or so I need for no I will just do the redirect in zen balance.

Thanks for your help.