Same for Labs Projects please

In T163019#3183560, @Freddy2001 wrote:

Same for Labs Projects please

Can't they just do them themselves?

I've tried to add the following code to my .lighttpd.conf according to https://redmine.lighttpd.net/projects/1/wiki/HowToRedirectHttpToHttps which resulted in redirect-loop.

$HTTP["scheme"] == "http" {
    # capture vhost name with regex conditiona -> %0 in redirect pattern
    # must be the most inner block to the redirect rule
    $HTTP["host"] =~ ".*" {
        url.redirect = (".*" => "https://%0$0")
    }
}

In T163019#3183577, @Reedy wrote:

In T163019#3183560, @Freddy2001 wrote:

Same for Labs Projects please

Can't they just do them themselves?

The unencrypted HTTP and the encrypted SSL traffic go both via port 80 between the Webproxy and the Instance.
Hence, I can't configure redirect rules for redirecting traffic from Port 80 to 443 on my Instance.

Seems this Is the same issue for toollabs.

Might be because Tool Labs uses the infrastructure of Labs.

Look at it if it can help you: https://mozilla.github.io/server-side-tls/ssl-config-generator/

In T163019#3183608, @Urbanecm wrote:

I've tried to add the following code to my .lighttpd.conf according to https://redmine.lighttpd.net/projects/1/wiki/HowToRedirectHttpToHttps which resulted in redirect-loop.

You want to redirect based on the HTTP_X_FORWARDED_PROTO header, not the scheme, as the scheme (as far as the webservice is concerned) is always http -- the connection between the proxy and the webservice is not encrypted.

Alternatively, you can use protocol-relative URLs to load the javascript file, i.e. src="//tools.wmflabs.org/...", which will load the javascript over http if the original page is loaded over http.

Do you know how can I add the redirect rule to lighttpd config? Or do it need to be set somewhere else?

In T163019#3183892, @Urbanecm wrote:

Do you know how can I add the redirect rule to lighttpd config? Or do it need to be set somewhere else?

It need to set somewhere else: In the proxy. Not on the lighthttpd server.

In T163019#3183892, @Urbanecm wrote:

Do you know how can I add the redirect rule to lighttpd config? Or do it need to be set somewhere else?

I've done it in the main PHP file. Thank you for the header-help!

In T163019#3184660, @Freddy2001 wrote:

In T163019#3183892, @Urbanecm wrote:

Do you know how can I add the redirect rule to lighttpd config? Or do it need to be set somewhere else?

It need to set somewhere else: In the proxy. Not on the lighthttpd server.

No no no. You receive a header informing the request came over HTTP from the proxy, then you may redirect. For example my Wikinity tool is now https only (applies only for the main file but the others should not be accessed by users directly).

Where do I get this information in the header?

This is a HTTP header. For example in PHP you may do the following

if (getallheaders()['X-Forwarded-Proto'] == "http") {
	header("Location: https://".$_SERVER['HTTP_HOST'].$_SERVER['PHP_SELF']);
}

This would redirect all requests with X-Forwarded-Proto header set to http (exactly as it is set when receiving request over HTTP by the proxy) to the same URL but with https protocol.

I don't know how can you do it in the webserver's config sadly.

Note that the code must be at the beginning of your PHP code before any other output. Otherwise the location thing would just appear on the screen.

Slightly off topic to this bug, but why do we even allow non secure http on tool labs? Https-only (+hsts) is quickly becoming the norm for major websites

This seems to be a non-Security issue, and one which is best handled by another team, so I'm untagging the Security project.

In T163019#3184780, @Bawolff wrote:

Slightly off topic to this bug, but why do we even allow non secure http on tool labs? Https-only (+hsts) is quickly becoming the norm for major websites

That's good question. I personally think we can throw HTTP away, I'm enforcing HTTPS for tools.wmflabs.org for my computer and didn't find anything broken but...

Some tools I messed in T172065 doesn't work on HTTPS on some browsers (including my non-usual-non-testing Firefox) due to loading HTTP.