Apache2::xForwardedFor - Re-set remote_ip to incoming client's ip when running mod_perl behind a reverse proxy server. In other words, copy the first IP from X-Forwarded-For header, which was set by your reverse proxy server, to the remote_ip connection property.

  in httpd.conf

    PerlModule Apache2::xForwardedFor
	PerlSetVar  xForwardedForRequire 1
	PerlSetVar  xForwardedForAccept 192.168.1.1
	PerlAddVar  xForwardedForAccept 192.168.1.2
	PerlPostReadRequestHandler Apache2::xForwardedFor

  also note:
  	PerlSetVar  xForwardedForRequireHeaderName X-Internal-Password
	PerlSetVar  xForwardedForRequireHeaderValue shibby

  or:
    PerlSetVar  xForwardedForRequireHeaderName X-Forwarded-Server
	PerlSetVar  xForwardedForRequireHeaderValue lanServer1
	PerlAddVar  xForwardedForRequireHeaderValue lanServer2

At this time you simply need to load the module and add it to the PerlPostReadRequestHandler phase of your mod_perl-enabled httpd, and set a few variables.

Apache2::xForwardedFor is really flexible and does some very odd ( but neat! ) things

Set some variables in httpd.conf, and that's it

Apache2::xForwardedFor will let you do all this neat stuff

  migrate X-Forwarded-For headers into $c->remote_ip for proxied requests
  specify which reverse proxy servers your mod_perl app serves to using:
     a list of IPs you allow
     a list of IPs you prohibit
     a secondary header of your choice, with a set value , inserted by the reverse proxy

This allows you to limit which hosts Apache serves content to ( in a rather flexible manner ), with just a few simple settings.

should you want to receive the X-Forwarded-For info from the proxy server on another ip, the name of it would be the value of this variable.

require the X-Forwarded-For header (or alternate name). return FORBIDDEN otherwise

Why would you do this? So that by default you can use either access apache through the proxy or directly. This is FALSE by default, if someone wants to patch to be TRUE by default, send it my way.

should you require an additional header, this is the name of it.

Why would you do this? Maybe you don't trust your gateway/proxy admin to be filtering headers correctly. So you want to put a hash or an internal lan marking on internal requests.

should you require an additional header (xForwardedForRequireHeaderName), this is the value. this will be ignored if xForwardedForRequireHeaderName is not set. if xForwardedForRequireHeader and this is UNDEF, the header value does not match, or the header is not sent, this will return FORBIDDEN

single item or list of IP addresses to accept

single item or list of IP addresses to deny

This doesn't support AT ALL:

	IPV6

	X-Forwarded-Host

This doesn't fully support :

	X-Forwarded-Server

If you patch it to support those , let me know.

As illustrated in the example above, you can feign some support for X-Forwarded-Server by using the alternate header name

As this module is designed for use under mod_perl , it takes advantage of how mod_perl 'optimizes away' debug statements tied to false constants at compile time.

In order to Debug for testing, you must set some envelope variables-- either on the commandline, or just in HTTPD.conf before this module is included .

  xForwardedFor_DEBUG
    0 (default) , 1 (print debug info)

  xForwardedFor_TEST
    0 (default) , 1 ( require alternate header ) , 2 ( require alternate header and set it if not provided )

 Jonathan Vanasco - cpan@2xlp.com
 http://2xlp.com 

Copyright (c) 2006 Jonathan Vanasco. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

Based on the module Apache::ForwardedFor by Jay J. Lawrence ( jlawrenc@cpan.org )

This has a lot of tweaks/additions that you might find useless