You are correct although it isn't as bad as it seems. There are actually two types of caching going on here. There is the ldap connection cache and the user credential cache. Because the user credentials are cached, subsequent requests from the same user are not actually authenticated directly against LDAP. util_ldap simply checks it own cache to make sure that the user name and password are good. If so, then it by passes the LDAP search. Therefore, the values for the ldap binddn and bindpw would only be replaced when the cached user credentials expire and a reauthentication requires a new ldap search. But over time or if the user credential cache is disabled, this could still be a problem so I have attached a patch that eliminates the repeated allocations from the pconf pool. Please let me know if you see any problems with this additional patch. I would like to get this commited and backported soon.
Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com >>> [EMAIL PROTECTED] Tuesday, April 13, 2004 5:44:19 AM >>> [EMAIL PROTECTED] wrote: > bnicholes 2004/03/31 14:56:08 > > Modified: modules/experimental util_ldap.c > Log: > Update the DN information associated with each LDAP connection after util_ldap_cache_checkuserid() rebinds the connection. > > Revision Changes Path > 1.22 +12 -0 httpd-2.0/modules/experimental/util_ldap.c > > Index: util_ldap.c > =================================================================== > RCS file: /home/cvs/httpd-2.0/modules/experimental/util_ldap.c,v > retrieving revision 1.21 > retrieving revision 1.22 > diff -u -r1.21 -r1.22 > --- util_ldap.c 9 Feb 2004 20:29:18 -0000 1.21 > +++ util_ldap.c 31 Mar 2004 22:56:08 -0000 1.22 > @@ -844,6 +844,18 @@ > ldap_msgfree(res); > return result; > } > + else { > + /* > + * Since we just bound the connection to the authenticating user id, update the > + * ldc->binddn and ldc->bindpw to reflect the change and also to allow the next > + * call to util_ldap_connection_open() to handle the connection reuse appropriately. > + * Otherwise the next time that this connection is reused, it will indicate that > + * it is bound to the original user id specified ldc->binddn when in fact it is > + * bound to a completely different user id. > + */ > + ldc->binddn = apr_pstrdup(st->pool, *binddn); > + ldc->bindpw = apr_pstrdup(st->pool, bindpw); isn't st->pool pconf? (or maybe I'm having trouble tracking ldc and st ;) ) can binddn and bindpw be repeatedly replaced with new values, creating uncontrolled growth of pconf?
util_ldap.c.patch
Description: Binary data
