New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes in Apache 2.4 / mod_perl (remote IP) #214
Comments
At the moment I'll stick with client_ip as this works. useragent_ip seems to require more than just the two lines: Can't locate object method "useragent_ip" via package "Apache2::Connection" at /usr/share/eprints3/p |
You're calling useragent_ip on the wrong object... |
ah.. yeah.. works better now.. |
Nice! :-) thanks for testing (I don't have apache 2.4 handy). |
ep-tech conversation on that topic: 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 In this scenario i use: X-Forwarded-For: client, proxy1, proxy2the last value isn't the original client's IP but the who connect with usmy $ip = $ENV{'HTTP_X_FORWARDED_FOR'} || $r->connection->remote_ip; Enio
|
Looks like Apache2::ServerUtil::get_server_version() should provide a way to switch between behaviours for 2.(<4) and 2.4. |
also UNIVERSAL::can might help. if( $r->connection->can( 'remote_ip' ) ) .... |
A collection of patches which fixes issues with using EPrints over Apache v2.4. For the 3.3 branch, here are the patches you should use (if you had to): 88567f9 This basically wraps the various ways to get the "real" client IP (by opposition to the IP of a machine in-between such as a proxy or load-balancer) into a single method. Other patches make use of the new API method $repository->remote_ip. |
In Repository.pm, X-Forwarded-For is taken as is without any parsing but in proxy environment it may include multiples ip if there are more proxy. You can see http://en.wikipedia.org/wiki/X-Forwarded-For#Format So i propose a patch: *** pp/perl_lib/EPrints/Repository.pm 2014-10-22 14:18:33.278788495 +0200 *** 431,436 ****
|
Doesn't this proposal leave you with the last (proxy), rather than the first (client) address? Rather you'd want something like |
Actually, even that's imperfect, if the XFF header is malformed with a leading comma. To work in most real-world eventualities you'd need something more complex, like: # sanitise: remove leading commas and whitespace
$ip =~ s/^\s*,+|\s+//g;
# slice: take only first address from the list
$ip =~ s/,.*//; |
Yes, this leave the last proxy (who connect whith me) but why? |
... and if the client browser is in a nat office (network address translation), the ip of the client will surely be a private IP (in XFF) |
Usually a NAT proxy knows not to expose private IPs to the public internet. But back to your use-case; you say you want to log the first hop outside your gateway/reverse-proxy. Note Seb's comment, "the various ways to get the "real" client IP (by opposition to the IP of a machine in-between such as a proxy or load-balancer)" Our goal with this method is to get the client IP, what you want is something different. I feel that's something you negotiate between your eprints server and your gateway/RP. |
Discussion in eprints#214 highlighted that XFF may contain multiple forwarded IP address, separated by commas. This patch takes only the first such address from the list (i.e. the original client's address).
Discussion in eprints#214 highlighted that XFF may contain multiple forwarded IP address, separated by commas. This patch takes only the first such address from the list (i.e. the original client's address).
In my use-case I would like to take the ip that connects to the RP apache, since it is, in my opinion, the only valid and that it has a value always true. |
As I said, you're wanting to do something different than what this method provides. We're giving the equivalent of the new If you want to use something for security purposes (LoginTicket, Recaptcha, cfg.d/security.pl) you should not use any user-supplied value. If you really trust your reverse proxy, then I suppose it's safe to use a value that you are certain it provided. However most of us don't have that guarantee -- we don't trust any node in the path, we just want to have EPrints make the best effort to tell us the IP address of the actual web browser or robot accessing our site. For the common case, the IP of some random proxy out in the web is just as useless as the (rare) XFF-spoofed address, but for the most part the values we're going to get back are what we're after. For logging, there are other options, for example logging at the reverse proxy, or including the entire XFF header in the log. |
hello, can anyone help me, complete guide how to install eprints in my localhost. |
Short answer tested on eprints 3.3.12:
change
to
and
to
|
This was the approximate solution I was thinking of - but it mat not be perfect - and would need validation under Apache 2.2 and Apache2.4, for code that does, and does not use the `connection->remote_ip` method. The deparsed code block doesn't not contain comments (so wouldn't flag commented-out code - which I think is correct). It may be that a link to a wiki page relating to the issue would be helpful to output - or alink to #214?
Reported by David McElroy on ep-tech.
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:
The text was updated successfully, but these errors were encountered: