Summary: | Authenticated sessions being switched by reverse proxy | ||
---|---|---|---|
Product: | Apache httpd-2 | Reporter: | Duncan Fletcher <duncan.fletcher> |
Component: | mod_proxy | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
Status: | RESOLVED LATER | ||
Severity: | normal | CC: | rvandolson |
Priority: | P2 | Keywords: | MassUpdate |
Version: | 2.2.11 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP |
Description
Duncan Fletcher
2009-05-07 21:56:12 UTC
Please confirm; 2.0.63 reverse proxy to 2.2.11 dav_svn server is flawless. 2.0.54 reverse proxy to 2.2.11 dav_svn server results in crossed logins. If that is correct, this bug would not be addressed; the 2.0.63 version is the current 2.0 release and the ASF does not address bugs in previous versions, although some vendors will depending on their service agreements. No, the 2.0.54 reverse proxy to 2.2.11 dav_svn server is flawless too. It's the 2.2 series that has the problem. i.e: 2.0.X reverse proxy to 2.2.11 dav_svn server is flawless (tested 2.0.54 and 2.0.63) 2.2.X reverse proxy to 2.2.11 dav_svn server results in crossed logins (except for 2.2.6, that one is okay for some reason; tested all released 2.2.X versions) To be clear, 2.2.11 has this issue on our setup; it is not an "old problem with an old release" issue, its a current-release issue. That's a very precise chronology! Just checking the change log, 2.2.6 introduced PR 43472 - breaking keep-alive in proxied HTTP backend connections. This was fixed in 2.2.8. This looks a likely candidate for your observation that 2.2.6 doesn't exhibit this bug. Can you try 2.2.11 with that fix reversed? If this fixes your bug, we can start to think about a fix for both! Please try 2.2.11 with the following patch (there may be an offset, since this is actually against svn 2.2 branch): --- modules/proxy/proxy_util.c (revision 772881) +++ modules/proxy/proxy_util.c (working copy) @@ -2189,7 +2189,7 @@ else return 0; } - else if (APR_STATUS_IS_EAGAIN(status) || APR_STATUS_IS_TIMEUP(status)) { + else if (APR_STATUS_IS_EAGAIN(status)) { return 1; } return 0; I guess this is caused by the fact that your custom authentication module makes wrong assumptions about the HTTP protocol. HTTP is *stateless*. Because of this wrong assumption it is well known that NTLM doesn't work any longer over 2.2.x reverse proxies because it assumes that HTTP is a *statefull* protocol. You have to keep in mind that the reverse proxies eventually maps the same keepalive connection from the client to the reverse proxy to different backend connections for each request. Okay, we just ran another test, this time using "AuthType Basic" instead of "AuthType SSPI" and mod_auth_sspi (we are using v1.0.4 from http://sourceforge.net/projects/mod-auth-sspi). The problem went away under Apache 2.2.11. So it looks like Ruediger is correct and that the problem is in an assumption that mod_auth_sspi is (incorrectly) making about keep-alives being synonymous with sessions. We've been using pre-compiled binaries so although we can break out the compiler to try Nick's suggestion, it'll take time. i.e. I'd like confirmation that it will (likely) add valuable information before we chase that rabbit. In the meantime, we'll look into using mod_authnz_ldap for Windows AD authentication as an alternative to mod_auth_sspi and also track down a copy of the latter's source code to see if its feasible to fix that. Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated. |