On 06/03/2024 08:51, Christopher Schultz wrote:
All,
*bump*
Any thoughts?
I'd go with the RemoteIPValve.
Mark
-chris
On 2/28/24 14:53, Christopher Schultz wrote:
All,
When using AJP, setting tomcatAuthentication="false" allows mod_jk or
mod_proxy_ajp to transmit authenticated user information across the
connection to Tomcat so that request.getRemoteUser() will return
whatever httpd has for REMOTE_USER.
The same is not true for the HTTP connectors.
RemoteIPValve takes care of X-Forwarded-* headers
SSLValve takes care of SSL_* variables for cipher, client cert, etc.
This appears to be one of the only commonly-used pieces of information
that is difficult to transmit across HTTP while it's easy with AJP.
https://lists.apache.org/thread/bmps52nv8h63mkfqhzmh7p5bhhglgbpl
As a part of my crusade to get people to move from AJP to HTTP, I'd
like to propose that we make arrangements for this information to be
transmitted in some reasonable way.
One way to do it would be to add something to RemoteIPValve that would
be willing to accept e.g. X-Remote-User header and assign that to the
request. (This would be disabled by default!) Straightforward,
relatively easy to understand and configure, and uses existing
components. But perhaps X-Remote-User is "out of scope" for
RemoteIPValve?
Another way would be to add tomcatAuthentication="false" as an option
for the HTTP connector. It would behave like its AJP twin, except it
would look in HTTP headers for ... X-Remote-User? REMOTE_USER?
Somethign user-configurable? While this option mirrors the way it's
done for AJP, I don't like it as much as using RemoteIPValve, if for
no other reason than it has nothing to do with the connector itself
and the RemoteIPValve already has similar configuration options for
setting the names of special HTTP headers.
We could introduce a new Valve that just does this, and maybe adds
other things later that we find are also missing. This introduces a
completely new component, makes the valve chain even longer, etc. and
so I still favor adding this to RemoteIPValve.
Thoughts?
Thanks,
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
