back-ldap connection caching, proxy controls?

["Pierangelo Masarati" <masarati@aero.polimi.it>]

Howard, 

sorry for replying so late to your message; I set it aside
because I wanted to think about it, and urgent things overcame
it. 

Your point should be clear, I guess; actually there's one flaw
even in repeatedly doing binds with the same handle: think what
happens if a system is (mis)configured like 

access to attrs=userPassword
	by anonymous auth
	by users none 

which would result in successful first bind and unsuccessful
following binds.  Another point is that pam_ldap, auth_ldap and
so usually do a search followed by a bind, because users usually
know their userid, not their dn (exploiting the rewrite features
of back-ldap/back-meta you could turn a dn-looking userid into a
dn before bind takes place ;).  What about caching handles based
on bound dn? If a connection comes with a certain dn, and there's
already one for that dn it could be reused (mutex-protected); when
a bind takes place for a dn that's not cached yet, a new handle
could be created and added to the cache (as soon as the bind
succeeds). 

This approach, although fairly simple (maybe I'm missing some key
point) should be fairly feasible; this could also lead to
bund dn/related caches, because what prevents cacheing in back-ldap
is actually the fact that search results may vary based on the
bound dn. 

Pierangelo. 

Dr. Pierangelo Masarati               | voice: +39 02 2399 8309
Dip. Ing. Aerospaziale                | fax:   +39 02 2399 8334
Politecnico di Milano                 | mailto:pierangelo.masarati@polimi.it
via La Masa 34, 20156 Milano, Italy   | http://www.aero.polimi.it/~masarati