DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11210>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11210 JNDIRealm successfully authenticated a non-existing user on iPlanet Directory Server ------- Additional Comments From [EMAIL PROTECTED] 2002-07-27 15:08 ------- I downloaded the iPlanet/Netscape/Mozilla Directory SDK 4.1 from Sun and replicated the problem, which is due to a failure of this LDAP provider (com.netscape.jndi.ldap.LdapContextFactory) to conform to the JNDI specification. Section 6.6.2 of the JNDI 1.2 spec on the timeliness of modifications to the context environment says that changes to an environment property should be effective the next time an operation using that property is envoked. JNDIRealm relies on this to authenticate by binding as the user - it changes the principal and password properties and then carries out a search operation with the new environment. This all works as expected when using the default LDAP provider from Sun. The iPlanet implementation, on the other hand, seems to ignore any change to environment properties when the changed property pertains to the connection. (This discrepancy is hinted at in the section on JNDI Environmental Properties in the Netscape documentation). Thus it never even attempts to rebind as the user. This should really be fixed by whoever is now maintaining the Netscape provider, but I have a feeling that may not be trivial. So I've just attached a patch to JNDIRealm to work around the problem. This invokes reconnect() on the context to force an immediate rebind both when switching from administrator to user credentials for authentication and when switching from user to administrator credentials to search for user entries and role information. One, perhaps slight, downside is that the context must now be an LdapContext instead of the more generic DirectoryContext. On the other hand the realm is slightly more efficient than before when using the Sun LDAP provider. With the Netscape provider, it works correctly, but is rather inefficient since this provider closes the LDAP connection and creates a new one when reconnect() is invoked instead of keeping the same connection and rebinding with the new credentials. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>