You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2020/07/30 19:27:57 UTC
[Bug 64634] New: RemoteIpValve support x-forwarded-for header with
port (Azure)
https://bz.apache.org/bugzilla/show_bug.cgi?id=64634
Bug ID: 64634
Summary: RemoteIpValve support x-forwarded-for header with port
(Azure)
Product: Tomcat 9
Version: 9.0.x
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: cstuhr@ephibian.com
Target Milestone: -----
I attempted to enable the RemoteIpValve for a server hosted in Azure behind an
ApplicationGateway. The ApplicationGateway creates an x-forwarded-for header
value as <ip>:<port> instead of just <ip>. The RemoteIpValve can't parse this,
so it fails to work.
It is not super clear to me if this is an abuse of the x-forwarded-for spec by
Azure or not. But it would be nice if RemoteIpValve could be enhanced to
support this.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 64634] RemoteIpValve support x-forwarded-for header with port
(Azure)
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64634
Christopher Schultz <ch...@christopherschultz.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #4 from Christopher Schultz <ch...@christopherschultz.net> ---
I just added two new unit tests to the RemoteIPValve which include port numbers
in X-Forwarded-For and "trusted proxies" and it seems to be working as I would
expect it to work. I haven't tried this in any live configuration, though.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 64634] RemoteIpValve support x-forwarded-for header with port
(Azure)
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64634
--- Comment #3 from Christopher Schultz <ch...@christopherschultz.net> ---
(In reply to cstuhr from comment #0)
> The RemoteIpValve can't parse this, so it fails to work.
Do you get an error, or just a failure to operate as expected?
If an error, please post that.
In either case, please post your configuration (use fictional IPs if you want
to protect your info).
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 64634] RemoteIpValve support x-forwarded-for header with port
(Azure)
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64634
--- Comment #6 from Christopher Schultz <ch...@christopherschultz.net> ---
(In reply to cstuhr from comment #5)
> Well apparently in order to see the affect of the RemoteIpValve in the
> Access Log, you have to set requestAttributesEnabled="true" on the
> AccessLogValve. So now I'm seeing %a change to <ip>:<port> from the
> X-Forwarded-For header.
Good.
> However the IP from request.getRemoteAddr() hasn't changed.
>
> I'm a little surprised to see the port still part of it because of this bit
> of code of RemoteIpValve would seem to strip it:
>
> int portIndex = Host.parse(hostHeaderValue);
> if (portIndex > -1) {
> log.debug(sm.getString("remoteIpValve.invalidHostWithPort",
> hostHeaderValue, hostHeader));
> hostHeaderValue = hostHeaderValue.substring(0, portIndex);
> }
That's for the HOST header, which isn't the client's IP address (with or
without port).
> I'll continue investigating what/where the root issue is.
Please post your configuration.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 64634] RemoteIpValve support x-forwarded-for header with port
(Azure)
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64634
--- Comment #5 from cstuhr@ephibian.com ---
Yeah sorry for the mixup. I had initially tried to get this to work a year ago
and recalled seeing an error then, but I can't seem to replicate it again now.
I had just done a quick test of it again to verify before posting this ticket.
I was expecting to see the ip address change in the Access log %a variable
which it didn't.
Well apparently in order to see the affect of the RemoteIpValve in the Access
Log, you have to set requestAttributesEnabled="true" on the AccessLogValve. So
now I'm seeing %a change to <ip>:<port> from the X-Forwarded-For header.
However the IP from request.getRemoteAddr() hasn't changed.
I'm a little surprised to see the port still part of it because of this bit of
code of RemoteIpValve would seem to strip it:
int portIndex = Host.parse(hostHeaderValue);
if (portIndex > -1) {
log.debug(sm.getString("remoteIpValve.invalidHostWithPort",
hostHeaderValue, hostHeader));
hostHeaderValue = hostHeaderValue.substring(0, portIndex);
}
I'll continue investigating what/where the root issue is.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 64634] RemoteIpValve support x-forwarded-for header with port
(Azure)
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64634
cstuhr@ephibian.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|NEEDINFO |RESOLVED
--- Comment #7 from cstuhr@ephibian.com ---
I was mistaken again. The value I was looking at to verify
request.getRemoteAddr() wasn't actually coming from there in certain cases. Was
finally able to verify that request.getRemoteAddr() was being updated to
<ip>:<host> from RemoteIpValve.
Resolving ticket as invalid.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 64634] RemoteIpValve support x-forwarded-for header with port
(Azure)
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64634
--- Comment #2 from Christopher Schultz <ch...@christopherschultz.net> ---
Is it supplying X-Forwarded-For or X-Forwarded-Host?
X-Forwarded-For should contain the IP address of the client, and having their
port number (some random high-numbered port, likely) is pretty useless.
Looks like Microsoft just went ahead and made-up their own standard for how
these things are done, rather than following established norms[*]. They've also
invented some new things: X-Forwarded-Port (??) and X-Original-Host (why not
X-Forwarded-Host?).
[*] Okay, fine, so Squid invented this stuff and there is no RFC, etc. defining
it, but if all other proxies agree on how to do this, why does Azure have to
change everything? >:/
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 64634] RemoteIpValve support x-forwarded-for header with port
(Azure)
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64634
--- Comment #1 from cstuhr@ephibian.com ---
Documentation on Azure application gateway headers:
https://docs.microsoft.com/en-us/azure/application-gateway/how-application-gateway-works#modifications-to-the-request
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org