> So in my case the pooled connection that used the old password was valid > and used again?
It's clearly related to the caching of something in the context. I know virtually nothing about OpenDS, so I can't begin to speculate on a more specific cause. > Is the real reason the previous password worked is > because the application failed to close the context when I logged out? No. The lifecycle of LDAP contexts is completely independent of login/logout regardless of pooling. I believe pooled JNDI contexts don't have a termination period, but I'm not certain. > So connection pooling is good to have for production, but I shouldn't > use pooling if I use BindLdapAuthenticationHandler? I'm saying you should not use JNDI context pooling via pooled="true", which is not suitable for an authentication handler where principal changes between a superuser and an ordinary one. I have to retract my suggestion to use PoolingContextSource for authentication. That is not suited, either, for switching principals since it does not provide an interface for modifying the principal after checking out from the pool. We use a separate PoolingContextSource to pull additional attributes about the user from LDAP after authentication. For authentication we use a non-pooled LdapContextSource. > I'm using BindLdapAuthenticationHandler because the users are spread out > over multiple trees in the ldap. You are using the correct handler, then. > Is there a way to use FastBindLdapAuthenticationHandler but look in > multiple trees? The only use case for fast bind is when the DN of a user can be directly constructed from the username, which wouldn't be possible if you have users in multiple branches. M -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
