-
1. Re: Wildfly support for RemoteIpValve
ctomc Apr 26, 2016 5:11 AM (in response to mposolda)2 of 2 people found this helpfulon http/https listener in undertow subsystem you have proxy-address-forwarding option
an example of options
<http-listener name="default" socket-binding="http" proxy-address-forwarding="true" />
-
2. Re: Wildfly support for RemoteIpValve
mposolda Apr 26, 2016 5:35 AM (in response to ctomc)Thanks! Good to know.
However if I understand correctly, it is just boolean flag, so doesn't provide same level of flexibility like RemoteIpValve and possibility to configure trusted proxies etc?
For example, I have loadbalancer on "10.10.10.10", which doesn't just set the "X-Protocol-For" headers, but also forwards the old value of this header. And now assume some "evil" user connects to loadbalancer from "20.20.20.20" but he manually sets the header "X-Protocol-For" to "30.30.30.30". So I have the value of the X-Protocol-For header like this:
30.30.30.30 , 20.20.20.20 , 10.10.10.10
the request.getRemoteAddr() will be incorrectly set to "30.30.30.30". But I want to set it to "20.20.20.20" as that's the real IP of the user (last "trusted" proxy is 10.10.10.10).
-
3. Re: Wildfly support for RemoteIpValve
mposolda Apr 26, 2016 7:11 AM (in response to ctomc)Btv. it seems the functionality is not available for ajp-listener (which is usually used for setup behind loadbalancer). Correct?
-
4. Re: Wildfly support for RemoteIpValve
ctomc Apr 26, 2016 8:45 AM (in response to mposolda)1 of 1 people found this helpfulMarek Posolda wrote:
Btv. it seems the functionality is not available for ajp-listener (which is usually used for setup behind loadbalancer). Correct?
yes as it doesn't need it, ajp protocol itself caries this information, so you don't need to pass it in extra headers to backend.
However if I understand correctly, it is just boolean flag, so doesn't provide same level of flexibility like RemoteIpValve and possibility to configure trusted proxies etc?
For example, I have loadbalancer on "10.10.10.10", which doesn't just set the "X-Protocol-For" headers, but also forwards the old value of this header. And now assume some "evil" user connects to loadbalancer from "20.20.20.20" but he manually sets the header "X-Protocol-For" to "30.30.30.30". So I have the value of the X-Protocol-For header like this:
30.30.30.30 , 20.20.20.20 , 10.10.10.10
the request.getRemoteAddr() will be incorrectly set to "30.30.30.30". But I want to set it to "20.20.20.20" as that's the real IP of the user (last "trusted" proxy is 10.10.10.10).
yes that is correct the http handler ProxyPeerAddressHandler (which is the backing implementation of that flag) doesn't have the support for "trusted proxies"
Maybe we could add support for it in undertow, but in that case it would need to be configured via custom filters instead of flag on the listener.
Can you create new jira Undertow - JBoss Issue Tracker this in undertow tracker, or even better provide pull request with a fix
you can find core for it at: undertow/ProxyPeerAddressHandler.java at master · undertow-io/undertow · GitHub
-
5. Re: Wildfly support for RemoteIpValve
mposolda Apr 27, 2016 2:02 AM (in response to ctomc)> yes as it doesn't need it, ajp protocol itself caries this information, so you don't need to pass it in extra headers to backend.
Yeah, I have the info available in the header itself. But if I want to have servletRequest.getRemoteAddr() to return the correct value of client's host, I need to have the info propagated from the "X-Protocol-For". Basically same functionality what ProxyPeerAddressHandler is doing for HTTP.
Also it seems that in some cases with loadbalancer setup (like mine), the servletRequest.getRemoteAddr() returns "127.0.0.1" with AJP protocol. It is because the AJP packet doesn't have "remote_address" available, so in this line undertow/AjpRequestParser.java at master · undertow-io/undertow · GitHub the result.value is empty String, which is then resolved to 127.0.0.1 (because InetAddress.getByName("") returns "127.0.0.1" at least in my environment). I wonder that in cases, that "remote_address" is not set on AJP packet, it is better to either fallback to "remote_host" - undertow/AjpRequestParser.java at master · undertow-io/undertow · GitHub and if even remote_host is unset, then not call httpServerExchage.setSourceAddress here - undertow/AjpReadListener.java at master · undertow-io/undertow · GitHub , so httpServerExchange.getSourceAddress will fallback to network address (which is the address of loadbalancer) ?
> Can you create new jira Undertow - JBoss Issue Tracker this in undertow tracker, or even better provide pull request with a fix
> you can find core for it at: undertow/ProxyPeerAddressHandler.java at master · undertow-io/undertow · GitHub
Done [UNDERTOW-702] Support for set "trusted proxies" on ProxyPeerAddressHandler - JBoss Issue Tracker . Will be cool to help and contribute to Undertow. But not sure if Keycloak priorities allow me to do so
Thanks!
Marek