List Info

Thread: X-Forwarded-* headers patches




X-Forwarded-* headers patches
country flaguser name
United States
2007-06-17 00:45:41
Per discussion on the catalyst list, this patch implements
handling for a bunch 
of different X-Forwarded headers in a centralized spot, so
that all engines 
benefit. I've also included patches for the Apache and SCGI
engines to remove 
the proxy-related code they had implemented internally.

Engines that didn't implement any proxy handling will
magically get this 
handling added when the user upgrades to a version of
Catalyst-Runtime with 
this code in it, and I _think_ that old versions of the
engines should still 
just work.

Here's a summary from the docs:

=over 4

=item * X-Forwarded-For

The IP address in C<< $c->req->address >>
is set to the user's real IP
address, as read from the X-Forwarded-For header.

=item * X-Forwarded-Host

The host value for C<< $c->req->base >>
and C<< $c->req->uri >> is set
to the real host, as read from the X-Forwarded-Host header.
The value
of C<< $c->req->hostname >> is also
adjusted accordingly.

=item * X-Forwarded-Port

The port value for C<< $c->req->base >>
and C<< $c->req->uri >> is set
to the real port, as read from the X-Forwarded-Port header.

=item * X-Forwarded-Path

If this is set, the value of the X-Forwarded-Path header is
I<prepended> to the path value of C<<
$c->req->base >> and C<<
$c->req->uri >>.

=item * X-Forwarded-Is-SSL

If this is set, the scheme value of C<<
$c->req->base >> and C<<
$c->req->uri >> is set to "https".
Additional, C<< $c->req->protocol
>> is also set to "https", and C<<
$c->req->secure >> is set to a true
value.

=back


-dave

/*===================================================
VegGuide.Org                        www.BookIRead.com
Your guide to all that's veg.       My book blog
===================================================*/
_______________________________________________
Catalyst-dev mailing list
Catalyst-devlists.rawmode.org
http://lists.rawmode.org/mailman/listinfo/catalyst-dev


  
  
  
Re: X-Forwarded-* headers patches
country flaguser name
United States
2007-06-17 07:33:54
On Jun 17, 2007, at 1:45 AM, Dave Rolsky wrote:

> Per discussion on the catalyst list, this patch
implements handling  
> for a bunch of different X-Forwarded headers in a
centralized spot,  
> so that all engines benefit. I've also included patches
for the  
> Apache and SCGI engines to remove the proxy-related
code they had  
> implemented internally.

Thanks a lot, I'll get these applied today. 


_______________________________________________
Catalyst-dev mailing list
Catalyst-devlists.rawmode.org
http://lists.rawmode.org/mailman/listinfo/catalyst-dev


Re: X-Forwarded-* headers patches
country flaguser name
United States
2007-06-17 07:57:44
On Jun 17, 2007, at 1:45 AM, Dave Rolsky wrote:

> Per discussion on the catalyst list, this patch
implements handling  
> for a bunch of different X-Forwarded headers in a
centralized spot,  
> so that all engines benefit. I've also included patches
for the  
> Apache and SCGI engines to remove the proxy-related
code they had  
> implemented internally.

I see jrockway already committed this to a branch, so ignore
my  
previous message.

The one issue I have with this patch is that there may be
plugins out  
there that rely on the current code and need the adjusted
proxy  
values during a prepare_* stage.  The session plugins come
to mind  
and may be broken by this patch.

_______________________________________________
Catalyst-dev mailing list
Catalyst-devlists.rawmode.org
http://lists.rawmode.org/mailman/listinfo/catalyst-dev


Re: X-Forwarded-* headers patches
country flaguser name
United States
2007-06-17 10:27:30
On Sun, 17 Jun 2007, Andy Grundman wrote:

> The one issue I have with this patch is that there may
be plugins out there 
> that rely on the current code and need the adjusted
proxy values during a 
> prepare_* stage.  The session plugins come to mind and
may be broken by this 
> patch.

An alternative would be to have a bunch of X_from_proxy
methods that 
engines are expected to call in the appropriate prepare_X
method.

For example, we could have hostname_from_proxy (and a few
others) called 
in the prepare_path method.

This is a little more intrusive, because each engine has to
be changed to 
make these calls. Ideally, it seems like the engines could
share more code 
inherited from Catalyst::Engine, as they're doing largely
the same things.


-dave

/*===================================================
VegGuide.Org                        www.BookIRead.com
Your guide to all that's veg.       My book blog
===================================================*/

_______________________________________________
Catalyst-dev mailing list
Catalyst-devlists.rawmode.org
http://lists.rawmode.org/mailman/listinfo/catalyst-dev


[1-4]

about | contact  Other archives ( Real Estate discussion Medical topics )