Override 'wsgi.url_scheme' via a request header, 'X_WSGI_URL_SCHEME'. #42

Merged
merged 10 commits into from Mar 10, 2014

Projects

None yet

5 participants

@tseaver
Member
tseaver commented Sep 3, 2013

Allows proxies which serve mixed HTTP / HTTPS requests to control signal
which are served as HTTPS.

@tseaver tseaver Override 'wdgi.url_scheme' via a request header, 'X_WSGI_URL_SCHEME'.
Allows proxies which serve mixed HTTP / HTTPS requests to control signal
which are served as HTTPS.
06df318
@mmerickel
Member

spelling

@tseaver
Member
tseaver commented Sep 3, 2013

Removes one more reason to mention / explain Paste. The only question I have is whether waitress should expect the same 'X_Forwarded_Scheme' header as Paste; I chose not, but it would be easy to switch back.

@mmerickel
Member

Any reason to avoid prior-art? PasteDeploy's prefix middleware uses X-Forwarded-Proto which lines up pretty well with the commonly used X-Forwarded-For.

@mmerickel
Member

Ah and as you mentioned the prefix middleware supports both X-Forwarded-Proto and X-Forwarded-Scheme, both of which are (of course) undocumented.

To be clear the prefix middleware is in PasteDeploy, so mentioning it is not so bad. It's py3k compatible.

@kgaughan kgaughan commented on an outdated diff Sep 7, 2013
docs/differences.rst
@@ -13,6 +13,9 @@ Differences from ``zope.server``
- Calls "close()" on the app_iter object returned by the WSGI application.
+- ALlows per-request override of ``wsgi.url_scheme`` by the value of the
@kgaughan
kgaughan Sep 7, 2013 Member

There's a minor typo here: s/ALlows/Allows/

@kgaughan
Member
kgaughan commented Sep 7, 2013

I was thinking: might it be worthwhile ensuring that X-Forwarded-Proto can't be used to override the value explicitly set in waitress.adjustments.Adjustments.url_scheme when waitress is spun up?

@tseaver tseaver referenced this pull request in repoze/repoze.profile Oct 24, 2013
Closed

Web based profile viewer not honoring HTTPS usage #3

@tseaver
Member
tseaver commented Oct 24, 2013

@kgaughan: Zope's configuration exposes the notion of a "trusted proxy": if the upstream IP matched, then the headers passed by the proxy would be used unconditionally. Otherwise, the configured defaults would be used. Maybe we need to do the same?

@kgaughan
Member

That definitely seems worthwhile.

@sontek
Member
sontek commented Mar 9, 2014

@tseaver whats holding up the merge of this?

@sontek
Member
sontek commented Mar 10, 2014

I think it'd be good to support X-Forwarded-For and X-Forwarded-Proto, thpose are the standard headers that things like nginx and gunicorn use. X-Forwarded-For would be the client IP and -Proto would be http/https.

@mmerickel
Member

This should be opt-in, and should also include the X-Forwarded-For support that @sontek mentioned. It'd be unwise to publish this as-is since it's a large vulnerability for any waitress server that is not behind a properly-configured reverse proxy to trust a random HTTP header.

@tseaver
Member
tseaver commented Mar 10, 2014

@mmerickel @sontek : 'X-Forwarded-For' isn't relevant to this PR, which is about allowing mixed-mode proxies to signal to the application which scheme was used in the original request, so that they can generate absolute URLs using the same scheme.

But yes, I haven't merged this because of the concern @mmerickel mentions about folks running w/o proxies.

@mmerickel
Member

I think the thought process is that both headers are very common in a reverse proxy configuration and may be opted-in by the same option, but of course maybe not.

allow_forwarded_scheme = yes
allow_forwarded_ip = yes
@mmerickel
Member

I wish this was done via the allow* options I mentioned rather than this trusted_proxy ip address because now I have to mess with my deployment setup to make my app know about the proxy it's running behind, while previously my wsgi server was completely agnostic and just as secure.

@tseaver
Member
tseaver commented Mar 10, 2014

Feel free to update it after I merge the work I've already done.

@tseaver tseaver merged commit 09f25b3 into master Mar 10, 2014
@mmerickel mmerickel commented on the diff Mar 10, 2014
docs/arguments.rst
@@ -28,8 +28,14 @@ threads
number of threads used to process application logic (integer), default
``4``
+trusted_proxy
+ IP addreess of a client allowed to override ``url_scheme`` via the
@mmerickel
mmerickel Mar 10, 2014 Member

spelling

@mmerickel
Member

I'd happily update it, but I don't like to change code without talking about it first. By that, I can't quite tell if you think the concerns are not relevant or you just really wanted to merge this branch?

@tseaver
Member
tseaver commented Mar 11, 2014

I would prefer the 'trusted_proxy' approach myself (less convenient, but also less susceptible to being abused if the appserver is accidentally exposed to public requests). I can live with it either way.

@pwaller
pwaller commented Mar 12, 2014

Huh, I just followed the latest documentation and hadn't realised that this isn't released yet. Surprised such a feature is so new. What's the best way to configure it before the new release, then?

With respect to the issue at hand, what if there are multiple proxies in a load balancing arrangement? It seems like hard-coding IPs into application configuration files is not the ideal place to do it and that this configuration should really live in the runtime environment architecture or in a firewall. If I was deploying an application I would make it listen on an interface where only trusted proxies could talk to it in the first place.

@pwaller
pwaller commented Mar 12, 2014

(I meant to give a shout-out to @mmerickel's allow_* suggestion)

@bertjwregeer bertjwregeer deleted the feature.x_wsgi_url_scheme-header branch Oct 14, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment