After changing my password, I accidentally navigated back to the passwordreset page. My basicauth was cached and permitted with the old password, but the application itself returned the plain ASCII response "Cannot Bind To Ldap Server", presumably associated with a bind failure due to invalid credentials. Consider returning a 401 when a bind failure returns "invalid credentials".
Interesting that it happened like that. I think the app grabs the credentials from the http basic auth, which I thought would have failed and returned the 401. I'm not sure if this is something that can be fixed in the auth section of apache, but regardless I agree it should be fixed. rtucker - can you tweak the passwordreset page to return 401 when a bind failure happens?
What's LDAPCacheTTL set to? Default is 10 minutes, which would explain why trusting Apache is insufficient.
jabba: It would be a global 401 response for a bind failure happening. I don't think it would cause any problems by having a 401 globally for all bind failures. Thoughts?
I'm wondering if there is a failure of the bind that the bind user does to search for the actual user, if that should not be a 401 but rather a 500 or something different, since it's a different type of error. I don't think there currently is a LDAPCacheTTL setting at all, which would indeed explain the issue there. Perhaps setting it explicitly to 0 would be a good fix?
jabba, That very well will fix it, but would the additional load of doing a new lookup every time be too much for the seamicros?
(In reply to Rob Tucker [:rtucker] from comment #3) > jabba: > It would be a global 401 response for a bind failure happening. The bind failure reason is available for inspection. It would be misleading (but probably harmless) return 401 for *all* failure code when you only want to return it for a single specific failure code. (In reply to Justin Dow [:jabba] from comment #4) > I don't think there currently is a LDAPCacheTTL setting at all, which would > indeed explain the issue there. Perhaps setting it explicitly to 0 would be > a good fix? You may want to lower it gradually, rather than shutting off caching entirely. A cache of even just 10 seconds would presumably stop 95%+ of all LDAP queries that would otherwise be sent to the slaves (due to images, styles, etc). A cache of 0 seconds would amplify the # of LDAP queries from "1 per page view at minimum" to "1 per page resource at minimum", which can be 10-20x or more on some pages.
I lowered the LDAPCacheTTL to 10, and tested changing my password on https://ldap-dev.allizom.org/passwordreset. After successfully changing, I hit enter in the URL bar to get the page again and it prompted me again for basic auth and did not accept my firefox-stored "old" password. I think this is fixed. Added to puppet for production as well.