[
https://issues.jboss.org/browse/WFLY-2196?page=com.atlassian.jira.plugin....
]
Corey Daley edited comment on WFLY-2196 at 12/9/13 4:54 PM:
------------------------------------------------------------
This would also affect running this on an OpenShift gear since there is a node level proxy
in front of them, and only the X-Forwarded-For and such is passed on to the gear, also the
server can not see if the request was https unless you check the x-forwarded-proto
was (Author: cdaley):
This would also affect OpenShift gears since there is a node level proxy in front of
them, and only the X-Forwarded-For and such is passed on to the gear, also the server can
not see if the request was https unless you check the x-forwarded-proto
add x-forwarded-* headers support
---------------------------------
Key: WFLY-2196
URL:
https://issues.jboss.org/browse/WFLY-2196
Project: WildFly
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Reporter: MichaĆ Zegan
Priority: Minor
Hello.
If it is desirable, can you add the possibility for wildfly/undertow subsystem to
retrieve x-forwarded-host and similar headers and set a remote ip address and hostname
based on it?
This header is set by proxy servers to indicate proxies this request has passed and to
indicate the client's real ip address.
It's extremely useful if an application checks and uses the hostname or ip of a
client that connects to it.
In the case of wildfly directly open to the public, the ip and host given will be that of
a client, but if the server where an application is running is just a backend server and
there is a frontend before it that proxies to it, the ip and host will be that of the
proxy, often localhost if the proxy sits on the same machine, that is undesirable because
you don't want to ip-ban a proxy.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira