Problem with redirects where a Rack app sits behind a proxy

Problem with redirects where a Rack app sits behind a proxy

[Jon Leighton]

Hi there,

I have encountered a problem with redirects with Sinatra proxied by
Apache. Basically, the port number of the backend application server
(Mongrel or whatever) will appear in the Location header.

I've done a fairly extensive investigation here: https://github.com/jonleighton/redirect_test

If you read README.md it basically explains everything in detail, but
what it boils down to is this: Rack::Request#port is incorrect, in
that it uses SERVER_PORT when no explicit port is given by
host_with_port.

Rails is not affected, since it implements its own
ActionDispatch::Request#port method. I believe the Rails
implementation is correct and should be implemented in Rack.

If people agree with this analysis then I'm happy to produce a patch
against Rack.

Cheers,
Jon

--
http://jonathanleighton.com/

Re: Problem with redirects where a Rack app sits behind a proxy

[Lee Hambley]

[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]

Jon, it's the responsibility of your proxy to set X-Forwarded-For, and of
the Application to check :port if it cares about the real port, or the
X-Forwarded-For list in the case that you acknowledge the request might be
proxied.

Often XFF can be used to trick sites that use it for some `security` (not
your case) as the client can spoof it.

In case you use NGinx, at least you can specify to proxy transparently
(completely) - so your app wouldn't be any wiser.

Some proxies (Akamai) will also set a True-Client-IP header to the value set
last in XFF.

 • http://en.wikipedia.org/wiki/X-Forwarded-For

Hope that makes sense Jon (would be nice to have a standard Ruby way to look
at the proxies & original client info from the `smart` places, as it comes
up for a lot of people. Here's a snippet of a nginx backend configuration
that solved this in the easiest way for me.
https://gist.github.com/46cc2ba95794f5c92693

- Lee

On 28 November 2010 15:21, Jon Leighton <j@jonathanleighton.com> wrote:

> Hi there,
>
> I have encountered a problem with redirects with Sinatra proxied by
> Apache. Basically, the port number of the backend application server
> (Mongrel or whatever) will appear in the Location header.
>
> I've done a fairly extensive investigation here:
> https://github.com/jonleighton/redirect_test
>
> If you read README.md it basically explains everything in detail, but
> what it boils down to is this: Rack::Request#port is incorrect, in
> that it uses SERVER_PORT when no explicit port is given by
> host_with_port.
>
> Rails is not affected, since it implements its own
> ActionDispatch::Request#port method. I believe the Rails
> implementation is correct and should be implemented in Rack.
>
> If people agree with this analysis then I'm happy to produce a patch
> against Rack.
>
> Cheers,
> Jon
>
> --
> http://jonathanleighton.com/

[-- Attachment #2: Type: text/html, Size: 2631 bytes --]

Re: Problem with redirects where a Rack app sits behind a proxy

[Jon Leighton]

[-- Attachment #1: Type: text/plain, Size: 3013 bytes --]

Hi Lee,

Thanks for your reply. I'm not entirely following though, so I wonder if
there is some confusion.

For a start, this issue doesn't relate to X-Forwarded-For, but to
X-Forwarded-Host and the SERVER_NAME and SERVER_PORT env variables set
by the app servers.

My basic complaint is that Rack is taking the absence of a ":port"
section in X-Forwarded-For to mean "fall back to SERVER_PORT", when in
fact I think it should be interpreted as "fall back to port 80 (or
443)". (Which is what Rails does.)

See https://github.com/jonleighton/redirect_test/blob/master/README.md
for more detail.

Hope this makes sense.

Cheers,
Jon

On Sun, 2010-11-28 at 15:46 +0100, Lee Hambley wrote:
> Jon, it's the responsibility of your proxy to set X-Forwarded-For, and
> of the Application to check :port if it cares about the real port, or
> the X-Forwarded-For list in the case that you acknowledge the request
> might be proxied.
> 
> 
> Often XFF can be used to trick sites that use it for some `security`
> (not your case) as the client can spoof it.
> 
> 
> In case you use NGinx, at least you can specify to proxy transparently
> (completely) - so your app wouldn't be any wiser.
> 
> 
> Some proxies (Akamai) will also set a True-Client-IP header to the
> value set last in XFF.
> 
> 
>  • http://en.wikipedia.org/wiki/X-Forwarded-For
> 
> Hope that makes sense Jon (would be nice to have a standard Ruby way
> to look at the proxies & original client info from the `smart` places,
> as it comes up for a lot of people. Here's a snippet of a nginx
> backend configuration that solved this in the easiest way for me.
> https://gist.github.com/46cc2ba95794f5c92693
> 
> 
> - Lee  
> 
> On 28 November 2010 15:21, Jon Leighton <j@jonathanleighton.com>
> wrote:
>         Hi there,
>         
>         I have encountered a problem with redirects with Sinatra
>         proxied by
>         Apache. Basically, the port number of the backend application
>         server
>         (Mongrel or whatever) will appear in the Location header.
>         
>         I've done a fairly extensive investigation here:
>         https://github.com/jonleighton/redirect_test
>         
>         If you read README.md it basically explains everything in
>         detail, but
>         what it boils down to is this: Rack::Request#port is
>         incorrect, in
>         that it uses SERVER_PORT when no explicit port is given by
>         host_with_port.
>         
>         Rails is not affected, since it implements its own
>         ActionDispatch::Request#port method. I believe the Rails
>         implementation is correct and should be implemented in Rack.
>         
>         If people agree with this analysis then I'm happy to produce a
>         patch
>         against Rack.
>         
>         Cheers,
>         Jon
>         
>         --
>         http://jonathanleighton.com/
> 
> 

-- 
http://jonathanleighton.com/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]