Yes, this true but if we are under reverse proxy apache (balanced) that set 'X-Forwarded-For' and a remote connection is from a proxy like 'squid' that in http set
'X-Forwarded-For' and in https is DIRECT (tunnel a connection) we must take the ip of 'squid' and not the client's ip.
Otherwise when the client is in http we take the client's ip and when in https we take the proxy ip (so the login cookie authenticate only https request)
In https 'squid' is in tunnel mode so it can not set  'X-Forwarded-For'.

In this scenario i use:
# X-Forwarded-For: client, proxy1, proxy2
# the last value isn't the original client's IP but the who connect with us
my $ip = $ENV{'HTTP_X_FORWARDED_FOR'} || $r->connection->remote_ip;
$ip=~s/^.*, *//;


  Enio
Il 13/03/2014 09:40, John Salter ha scritto:

Just an addition to this, under Apache 2.[something less than 4?], if you’ve got proxy servers in the routing, you might need to do something like this:

 

#Check if the remote IP is in our known proxy IPs, and it’s got a forwarded-for header.

#Only trust the proxies under your control!

if ( ($r->connection->remote_ip =~ /$self->{'_proxy_ips'}/) && ( $r->header_in('X-Forwarded-For') ) ){

    # Select last value in the chain -- original client's IP

    if (my ($ip) = $r->headers_in->{'X-Forwarded-For'} =~ /([^,\s]+)$/) {

        $self->log->error('message' => "Incoming IP: $ip  is proxied.");

        #set the remote_ip to the real remote IP sop other things can use it sensibly

        $r->connection->remote_ip($ip);

    }

}

 

Under 2.4 it looks like this is all handled in a different (better) way.

Cheers,

John

 

 

From: eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-bounces@ecs.soton.ac.uk] On Behalf Of Sebastien Francois
Sent: 12 March 2014 11:39
To: eprints-tech@ecs.soton.ac.uk
Subject: [EP-tech] Re: remote_ip via package "Apache2::Connection"

 

David,

See http://www.marshut.com/ippzhs/problem-with-apache2-connection-remote-ip.html and http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html (search for "remote_ip").

conn_rec->remote_ip and conn_rec->remote_addr

These fields have been renamed in order to distinguish between the client IP address of the connection and the useragent IP address of the request (potentially overridden by a load balancer or proxy). References to either of these fields must be updated with one of the following options, as appropriate for the module:

·         When you require the IP address of the user agent, which might be connected directly to the server, or might optionally be separated from the server by a transparent load balancer or proxy, use request_rec->useragent_ip and request_rec->useragent_addr.

·         When you require the IP address of the client that is connected directly to the server, which might be the useragent or might be the load balancer or proxy itself, use conn_rec->client_ip and conn_rec->client_addr.

It seems like it should use useragent_ip now. But we need to support either versions of apache2/mod_perl so will have to test for remote_ip's existence then useragent_ip.

I've now created that ticket: https://github.com/eprints/eprints/issues/214 & thanks for reporting that issue.

Seb.

On 12/03/14 11:24, David McElroy wrote:

Just finished setting up Eprints in ubuntu 13.10 server and I was getting the following error in my apache log:

 

Can't locate object method "remote_ip" via package "Apache2::Connection" at /usr/share/eprints3/perl_lib/EPrints/DataObj/LoginTicket.pm line 143.\n

 

this corrected the issue:

 

       #my $ip = $r->connection->remote_ip;

my $ip = $r->connection->client_ip;

 

and on line 118:

 

#$data->{ip} = $repo->get_request->connection->remote_ip;      

$data->{ip} = $repo->get_request->connection->client_ip;

       

 

I can’t see this issue on the github, should I submit it? Or am I correcting something that I should be fixing in my perl modules?

Thanks,

 

David McElroy

Research Data Management Officer

 

University of East London

Docklands Library

University Way

London E16 2RD

 

t: 020 8223 6467

 

 

 

 

*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech

*** Archive: http://www.eprints.org/tech.php/

*** EPrints community wiki: http://wiki.eprints.org/

*** EPrints developers Forum: http://forum.eprints.org/

 

*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/

*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/