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

Reply via email to