Graham,
On 12/9/20 08:36, Graham Leggett wrote:
[Downstream use of Tomcat] is the core of the problem - gone are the
days when Tomcat was just a simple server that people downloaded and
used to make bespoke web services and could write code any way they
liked. Now Tomcat is part of other systems, who in turn have other
support horizons unrelated to this project.
Downstream consumers of Tomcat are welcome to re-integrate APR into
their products if they choose to do so. If you are a paying customer and
need a feature, it's up to your vendor (e.g. Atlassian) to either
support you or lose your business.
The AJP deprecation is a problem. For those unaware of what AJP did,
AJP allowed a proxy server and Tomcat to be “glued” together as it
they were one server, and not two discrete entities. The proxy
configuration - that’s SSL, authn and authz - was passed
transparently across to Tomcat which behaved as if Tomcat itself had
performed the SSL, authn and authz. Sure, if you have a bespoke web
service and the budget you can make hack changes to compensate. If
your Tomcat is being provided by a vendor, or if you’re under
financial strain due a pandemic, then no - you have a sudden very
unwelcome headache.
Really, the only "hack" required is to enable the RemoteIPValve[1] and
SSLValve[2]. I consider having to separately-compile and install mod_jk
to be a "hack" at the web server level. httpd ships with mod_proxy
already built-in.
I personally am very interested in deprecating and removing AJP from
Tomcat for a number of reasons (lack of features, unnecessary additional
complexity) but I continue to use AJP in production while I work to
ensure that mod_proxy_* have feature parity with mod_jk (to wit,
https://bz.apache.org/bugzilla/show_bug.cgi?id=64338,
https://bz.apache.org/bugzilla/show_bug.cgi?id=53667, and possibly others).
If mod_proxy_http + Tomcat can't get the job done, let's actively work
to fix those so they CAN get the job done.
The closest RFC compliant solution to this problem is JSON Web Tokens
(JWT), which allows data to be passed across both securely and in an
RFC compliant way over HTTP. Tomcat should have fixed this problem
first, and then deprecated AJP with the clear notice “use this
alternative in future”.
I'm not sure what you mean, here. While I suppose JWT can be used for
just about anything anyone wants, it is typically used to package
authentication and authorization information into a format that the user
can be trusted to handle, rather than something that is maintained
exclusively server-side (e.g. by passing that information from httpd ->
Tomcat without involving the client).
Why would you involve the client here when you can pass anything you
want directly to Tomcat via (RFC-compliant, I might add) HTTP headers?
(I notice that the "tomcatAuthentication" <Connector> attribute is
AJP-only. That would be an obvious improvement to add that to either
another Valve or incorporate into one of the existing proxy-support
Valves in Tomcat.)
-chris
[1]
http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Remote_IP_Valve
[2] http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#SSL_Valve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
