Summary: | ProxyPassMatch with mod_proxy_ajp ignores AJP secret | ||
---|---|---|---|
Product: | Apache httpd-2 | Reporter: | Cedric Roijakkers <ajunne> |
Component: | mod_proxy_ajp | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
Status: | NEEDINFO --- | ||
Severity: | normal | CC: | ajunne, bjoernv |
Priority: | P2 | ||
Version: | 2.4.43 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Linux | ||
Attachments: | ap_proxy_define_match_worker() |
Description
Cedric Roijakkers
2020-06-19 10:26:56 UTC
Does it change anything if you declare the ProxyPass before the ProxyPassMatch? In this specific case that would not help, since the ProxyPass /foo declared before the ProxyPassMatch /foo/bar (and the rest of the regex) would send all traffic over the first proxy rule, instead of splitting it over the two, so that defied the purpose of my configuration. Created attachment 37318 [details] ap_proxy_define_match_worker() Can you please try this patch? This looks like the same issue as bug 43513. The fixes are in trunk but were never backported to 2.4. I've given your patch a test, and indeed this seems to solve the issue. I've re-enabled the secret in our Tomcat application, and I can see the secret is now correctly being used in all different connection pools to the different Tomcat instances. The same configuration that was previously generating 403 errors is now working as expected. Would it be possible to backport this fix to the 2.4 branch for next release? For now, we'll just keep using this patch in our production environment. Update from the trenches: we've been running this patch for a few months in production now, and it has solved the problem. Can it be backported to 2.4 and included in a following release? I was upgrading our Apache server, and wanted to apply this patch since we've been using it for a long time (and need it), but am I right and has this now beed added to release 2.4.48? It's been over a year since my last comment in this thread. We've been running in production with the patch supplied in this bug, everything is working fine. The latest httpd release is now 2.4.54 and this patch has still not made it into the release. We've recently ran into this bug again when using vanilla httpd in a project instead of the custom patched httpd. When will this patch finally make it into a release? This should be fixed in 2.4.54. The code evolved further from the patch attached here. Please retry with 2.4.54. Version 2.4.54 is what I tried with, that got me fooled by looking into this issue again. To be more precise, I based my container on top of docker container httpd:2.4.54-alpine3.16. The full httpd -V output in that container is: Server version: Apache/2.4.54 (Unix) Server built: Jul 18 2022 23:35:13 Server's Module Magic Number: 20120211:124 Server loaded: APR 1.7.0, APR-UTIL 1.6.1, PCRE 8.45 2021-06-15 Compiled using: APR 1.7.0, APR-UTIL 1.6.1, PCRE 8.45 2021-06-15 Architecture: 64-bit Server MPM: event threaded: yes (fixed thread count) forked: yes (variable process count) Server compiled with.... -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_PROC_PTHREAD_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=256 -D HTTPD_ROOT="/usr/local/apache2" -D SUEXEC_BIN="/usr/local/apache2/bin/suexec" -D DEFAULT_PIDLOG="logs/httpd.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf" |