tempurl ip restriction doesn't work behind proxy

[Pawel Dudczak]

I generate a temporary url to get objects from swift container with restriction per ip address, and when i try to get the object get the message:
"401 Unauthorized: Temp URL invalid".

In the swift code the ip address variable is taken from the "REMOTE_ADDR" environment variable, not from the http request header:

in file: swift/common/middleware/tempurl.py - line 530
client_address = env.get ('REMOTE_ADDR')

It would be good if the client's address will taken from the real client's address(forwarded by X-Forwarded-For header etc.) and not the server's proxy, without that the per ip address restrictions donsn't work

[Tim Burke (1-tim-z)]

I remember that there was a version of the patch that respected X-Forwarded-For, but I was worried about clients adding the header themselves and bypassing the IP restriction. Maybe it'd be ok as an opt-in config option to look at X-Forwarded-For/Forwarded headers, though? If an operator *knows* they only have swift binding to localhost while haproxy/apache/whatever-else has the publicly-accessible port, I suppose it seems safe enough...

What proxy do you have fronting swift? Does it support haproxy's PROXY protocol? I've had pretty good luck with https://github.com/openstack/swift/commit/661838d since we introduced it, and the either-or nature of it seems less risky (to me) than looking for a header which either

* isn't present at all,
* is present and was sent by an internal-to-the-cluster load-balancer or such, or
* is present and was sent by a client.

[Pawel Dudczak (pdudczak)]

I'm using haproxy as a proxy server, inclusion parameter "require_proxy_protocol = true" is not the best way for me, beceause not all swift clients understand proxy protocol and not all connections are coming through haproxy, so some connections are rejected with the 400 http code(ERROR WSGI: code 400, message Invalid PROXY line '\r\n'). It'd be great as an opt-in config option to look at X-Forwarded-For headers

[Tim Burke (1-tim-z)]

That makes some sense... but if

> not all connections are coming through haproxy

wouldn't that mean that a client could provide an X-Forwarded-For header themselves, bypassing the IP restriction? I'm not opposed to adding the config option, I just want to make sure that it would actually be suitable for your use-case.

Another option for you may be to run multiple proxy-server instances -- one that haproxy talks to which has require_proxy_protocol = true and is only bound to localhost, and another for general traffic...

[Pawel Dudczak (pdudczak)]

currently, except for traffic from internal checks, all traffic from customers passes through haproxy, and I in the flight on haproxy overwrites the X-Forwarder-For header so there is no risk of the client heading falsification. It would be good if you could set swift-proxy to parse any header I set to haproxy or at least X-Forwarder-For. This would make life a lot easier, because when I turned the "require_proxy_protocol" variable to true, all my internal checks must talk with the proxy protocol, but not all of them can.