[18:23:38] Hola, RhinosF1 [18:23:59] Please, request steward on miraheze phabricator [18:26:58] Please, request global kickban to Joaquinito01 [18:27:08] bd808 give me an op so i can [18:28:29] @kb bearfield [19:07:14] o/ can someone point me to some documentation or give me a brief primer on HTTPS and the web proxies for Cloud VPS? as in, if i create an instance on Cloud VPS and create a web proxy for it, is there any recommendations for what to do to ensure HTTPS? I did create an instance / web proxy and HTTPS seems to work but HTTP also works and frankly I'm a bit confused though glad as to why HTTPS seemed to have been enabled out of the box. [19:08:28] isaacj: I don't think that currently the proxy actively redirects. You can make a rewrite in your vhost to force https though [19:09:24] there is an ongoing task about forcing all traffic over — the remaining challenges are largely about communication and grace periods. https://phabricator.wikimedia.org/T131288 [19:09:39] isaacj: does 'make a rewrite in your vhost' make sense? Or should I dig up an example? [19:10:26] andrewbogott: yeah, i think that makes sense though examples always help (as in change my nginx settings i assume). maybe i'm showing how little i know about HTTPS, but how come I did not need to get a certificate or anything like that? [19:10:44] isaacj: the proxy also acts as a tls terminator [19:11:17] so it holds the cert and does all of that for you — then traffic from the proxy to your apache (or whatever) is unenecrypted. [19:13:50] ahh...ok, this is making more sense. so yeah if you have an example for how to encrypt that traffic as well, that'd be much appreciated. i'm assuming it means listening on port 443 instead of 80 and probably changing a few other settings. it doesn't sound like it requires getting a cert though thankfully [19:14:03] if you're happy supporting both http and https then you're already done :) [19:15:01] (I'm having trouble finding rewrite examples for nginx but will see what google can tell me) [19:15:02] yeah, in some ways for this particular instance it doesn't really matter. it's quite non-private information, but in practice i'd like to try to implement it so that we're set up to if we have an instance where we consider it to be much more important [19:16:04] bd808: do you have an example handy for forcing http -> https with nginx? All the samples I'm finding on line do it by port, which of course won't work behind a cloud-vps proxy [19:17:41] it is kind of an ugly dance in nginx, especially when you are already behind our TOLS terminating front proxy [19:17:52] *TLS [19:18:12] you can see the original url though, can't you? And detect that it was an http url? [19:21:36] not sure if that was a question for me, but in the nginx access.log, everything is coming through as HTTP/1.1 [19:22:46] ah, it was meant for bd808. But the easy answer for you (if you can live with it) is, clamor for a cloud-wide solution to this and don't worry about fixing it yourself in the meantime :) [19:24:12] haha, andrewbogott i love that answer :) [19:27:24] there should be a X-Forwarded-Proto header that tells you if the upstream terminated TLS or not [19:28:22] that's what the "fix" for this in Toolforge was before we started forcing TLS for everyone. Sniff the X-Forwarded-Proto header and issue a redir if it was not returning "https" [19:28:54] I honestly don't think I have an nginx config sample for doing that anywhere, but I can work one up [19:29:14] it takes either lua or some 'interesting' use of `if` [19:29:41] andrewbogott: you may remember how many times `if` has caused us grief in nginx land :) [19:30:55] bd808: if you're willing and think it would work without too much maintenance, i'm happy to experiment with it. if a cloud-wide solution is vaguely imminent though, I'm plenty willing to wait [19:31:57] it should not be impossible and should be a copy-n-paste with no maintenance once we have a working example. I know we have given advice on doing it with apache2 before [19:32:47] the icky part is just nginx not loving conditionals, or rather conditionals in nginx not being intuitive [19:33:33] great, no hurry. in case it's relevant, as you can see my nginx config is quite simple at the moment: https://github.com/geohci/research-api-endpoint-template/blob/master/model/config/model.nginx [19:33:50] andrewbogott and I were talking just last week about enforcing TLS at the proxy. We finally have it all enforced for toolforge.org after 18 monhts of transition [19:35:53] isaacj: so the trivial fix there would be do the redirect from your uwsgi app by doing something like https://github.com/legoktm/toolforge/blob/3fec9a5d53af722d8eb916953cf6bc576c29f594/toolforge/__init__.py#L115-L124 [19:35:55] !log deployment-prep deploying ores f3c44be [19:35:58] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Deployment-prep/SAL [19:36:55] codesearch uses that same snippet too [19:37:30] * bd808 will try to make some time later today to experiment with nginx config for that [19:37:50] yeah, i have a tool over there and am very excited about that change. i am very much in the situation of wanting to have no websites where i have to worry about https vs. http as opposed to 1 :) [20:09:57] bd808: it looks like iw.toolforge.org strips query parameters? https://iw.toolforge.org/checker/?db=enwikisource_p&title=Index:Bon-Accord_Sangster.pdf goes to just https://checker.toolforge.org/ [20:10:19] legoktm: ugh. that's a bug [20:10:40] * legoktm files [20:10:53] I at least know how to fix it :) [20:11:41] T258444 [20:11:42] T258444: iw.toolforge.org strips query parameters when redirecting - https://phabricator.wikimedia.org/T258444 [20:11:42] ty :) [20:13:53] !log tools.iw Updated ingress to use $request_uri when redirecting (T258444) [20:13:56] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.iw/SAL [20:15:16] bd808: now it's redirecting to https://checker.toolforge.org//checker/?db=enwikisource_p&title=Index:Bon-Accord_Sangster.pdf [20:15:58] I guess $request_uri also includes the path? [20:18:07] legoktm: blerg. I'll see if I can find the more better config :/ [20:20:13] !log tools.iw Updated ingress to use $args rather than $request_uri when redirecting (T258444) [20:20:16] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.iw/SAL [20:21:50] !log tools.iw Updated ingress to add $is_args when redirecting (T258444) [20:21:52] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.iw/SAL [20:22:20] legoktm: 4th time is the charm :) I think its working now [20:22:54] yep, looks correct! [20:23:00] should we write some test cases for this? :p [20:26:05] legoktm: its not easy (or maybe even possible?) to test this with a CI system, but yeah having some examples on https://wikitech.wikimedia.org/wiki/Tool:Iw of things that should work might be a good idea. [20:33:12] bd808: https://wikitech.wikimedia.org/wiki/Tool:Iw#Testing [21:25:33] !log cloudinfra Created A record for wmcloud.org pointing to proxy-proxy well known IP (T258415) [21:25:35] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Cloudinfra/SAL [21:25:36] T258415: Redirect https://wmcloud.org to https://wikitech.wikimedia.org/wiki/Help:Cloud_Services_Introduction - https://phabricator.wikimedia.org/T258415 [21:33:38] !log cloudinfra Created CNAME record for www.wmcloud.org pointing to wmcloud.org (T258415) [21:33:41] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Cloudinfra/SAL [21:33:42] T258415: Redirect https://wmcloud.org to https://wikitech.wikimedia.org/wiki/Help:Cloud_Services_Introduction - https://phabricator.wikimedia.org/T258415 [23:00:52] isaacj: StackOverflow has an answer for your nginx TLD redirect from behind a proxy question -- https://serverfault.com/a/503069/6479 [23:02:40] The only thing that doesn't deal with especially well is POST requests. But if this is a new thing you are building it should work fine. The handling of POST + 301 redirects is sketch in the real world, but if you don't have legacy POST users to worry about then there is no problem.