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

It redirects just fine for me in Firefox 68.

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 http://discuss-space.wmflabs.org/assets/preload-application-…b480941aaac91f9e7fa7f77496323ae056aaa4158822dea35de319c01.js (“script-src”).

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

I've been able to replicate this reliably more than 3 times now: When I access the discussion board directly via the URL discuss-space.wmflabs.org, I get an unsecure HTTP connection and most the page contents don't show up. If I go to the front page, space.wmflabs.org, 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 http://discuss-space.wmflabs.org/ 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 ~* 'discourse-mediawiki.wmflabs.org') {
   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;
}

We have copied what seems to work at discourse-mediawiki.wmflabs.org, which seems to have been copied from somewhere else...

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

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.

I ran ./launcher cleanup resulting in

Total reclaimed space: 5.77GB

./launcher enter app works now.

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!

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

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?

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