All,
*bump*
Any thoughts?
-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