httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: cvs commit: httpd-2.0/modules/experimental util_ldap.c
Date Tue, 13 Apr 2004 20:23:11 GMT
   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 

>>> trawick@attglobal.net Tuesday, April 13, 2004 5:44:19 AM >>>
bnicholes@apache.org 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?

Mime
View raw message