[Date Prev][Date Next] [Chronological] [Thread] [Top]

back-ldap connection caching, proxy controls?


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

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

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.


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