Page MenuHomePhabricator

Inconsistent enforcement of HTTPS in
Closed, ResolvedPublic


This is strange:


As far as I am aware, we applied to discuss-space the same "messy hack" that discourse-mediawiki has:


#Messy hack to force SSL on only the hostname, not IPs so ELB and Icinga work.
  set $use_https NO;
  if ($host ~* '') {
    set $use_https A;
  if ($http_x_forwarded_proto != 'https') {
    set $use_https "${use_https}B";
  if ($use_https = AB) {
    rewrite ^ https://$host$request_uri? permanent;


Related: T227019: Redirect all traffic to HTTPS

Event Timeline

Qgil created this task.Jul 16 2019, 6:59 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 16 2019, 6:59 AM
Qgil triaged this task as Medium priority.Jul 16 2019, 7:00 AM
Qgil added a subscriber: Tgr.
Qgil updated the task description. (Show Details)Jul 16 2019, 7:47 AM
Stryn added a subscriber: Stryn.EditedJul 30 2019, 10:14 AM

When searching on Google "space wmflabs" the first result is (not https), so the content on site won't appear at all on Firefox.

It redirects just fine for me in Firefox 68.

elappen-WMF added a subscriber: elappen-WMF.EditedAug 17 2019, 1:11 PM

The redirect is currently not working in Chrome, Safari or Firefox. Only the navigation bar is visible.

Firefox error:

Content Security Policy: The page’s settings blocked the loading of a resource at…b480941aaac91f9e7fa7f77496323ae056aaa4158822dea35de319c01.js (“script-src”).

@JHedden @bd808 You helped fixing T227019: Redirect all traffic to HTTPS. Do you have any idea what might be going on here?

InsaneHacker added a subscriber: InsaneHacker.EditedAug 23 2019, 11:16 AM

I've been able to replicate this reliably more than 3 times now: When I access the discussion board directly via the URL, I get an unsecure HTTP connection and most the page contents don't show up. If I go to the front page,, and then click on the Discuss-link, I get an HTTPS connection.

EDIT: Just realized this is because the menu link on the front page contains https://-links, and so the above might not be new information. What is interesting is that when I access the site using the described insecure method, clicking any menu link other than the front page and Blog-links, the insecure connection remains. Presumably that's because the other menu links are still within the discuss-space.

In a chrome incognito session without HTTPS-Everywhere, I can reproduce serving a 200 response rather than the hoped for 301 Redirect response. Seems pretty obviously to be misconfiguration at the Nginx level.

#Messy hack to force SSL on only the hostname, not IPs so ELB and Icinga work.
  set $use_https NO;
 if ($host ~* '') {
   set $use_https A;
 if ($http_x_forwarded_proto != 'https') {
   set $use_https "${use_https}B";
 if ($use_https = AB) {
   rewrite ^ https://$host$request_uri? permanent;

Is this copy-and-pasted from somewhere else? If this is just a "normal" backend instance behind the shared TLS reverse proxy provided for Cloud VPS tenants, I would think that this would work:

if ($http_x_forwarded_proto != 'https') {
    return 301 https://$host$request_uri;
Qgil added a comment.Aug 26 2019, 10:27 AM

We have copied what seems to work at, which seems to have been copied from somewhere else...

For how this code landed in discourse-mediawiki, see T180854#3880870 and comments below.

Tgr added a comment.Aug 27 2019, 6:56 PM

I tried to check the config but I get this:

tgr@discuss-space:/var/discourse$ sudo ./launcher enter app
You have less than 5GB of free space on the disk where /var/lib/docker is located. You will need more space to continue
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda3        19G   14G  4.3G  76% /

Would you like to attempt to recover space by cleaning docker images and containers in the system?(y/N)

(Why Discourse insists on 5G free space to give me a shell is beyond me.)
So that will have to be dealt with at some point.

Qgil added a comment.Aug 28 2019, 5:51 AM

I ran ./launcher cleanup resulting in

Total reclaimed space: 5.77GB

./launcher enter app works now.

Qgil added a comment.Oct 2 2019, 10:21 AM

Mmm I feel really stupid now.

After ./launcher enter app I go to /etc/nginx/conf.d and then vim discourse.conf (argh, where is my dear nano!?)

My first surprise is that the "messy hack" is not there. I swear I had added it. I check the same file in discourse-mw. The messy hack is there.

Alright. Nevermind. I add the configuration that Bryan shared above

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

I exit with :wq. I access the file again, my change is there. Good.

I exit the app and run ./launcher rebuild app. HTTPS still isn't forced. I go check discourse.conf again. MY CHANGES ARE GONE!

So I feel very stupid because there is something very basic that I seem to be missing here, and because of this we probably have been more than three months with HTTPS working only half way.

Halp please!

Qgil claimed this task.Oct 2 2019, 10:22 AM
Qgil raised the priority of this task from Medium to High.
Qgil edited projects, added Space (Oct-Dec-2019); removed Space.
Qgil moved this task from Backlog to Started on the Space (Oct-Dec-2019) board.
Tgr added a comment.Oct 2 2019, 12:28 PM

Well, rebuild destroys and recreates the Docker container so it doesn't seem that surprising. Probably templates would be the right way to do it (or just don't rebuild the container often :).

Qgil added a comment.Oct 2 2019, 7:44 PM

Hm. But... I guess we have rebuilt discourse-mediawiki since we set it up almost two years ago, and the messy hack is still there. In act, installing a new plugin requires to rebuild the app. Isn't there a way to make this change persistent?

Qgil added a comment.Oct 3 2019, 7:46 AM

(OK, I replied too fast yesterday. Templates. I'll try today.)

Qgil closed this task as Resolved.Oct 3 2019, 8:44 PM


discourse-mw has a file /templates/web.toolforge.yml that discuss-space misses, and the messy hack is there. I have created an equivalent file at discuss-space with the shorter and cleaner configuration shared by Bryan above, I have rebuilt discuss-space and... HTTPS enforcement seems to work!

I have tested with Firefox, and http redirects to https.

Also, a couple of other tests:

These things were broken because of http/https inconsistencies.

Qgil moved this task from Started to Evaluated on the Space (Oct-Dec-2019) board.Oct 28 2019, 7:56 AM