As the code stands now with only the Novell SDK always calling ldapssl_init(), is this a problem? We really need to get a full blown test case written for this stuff rather than hacking up util_ldap to test it. We need test cases for:
1. ldap:// on 389 2. ldap:// on alternate port 3. ldap://+start_tls on 389 4. ldap://+start_tls on alternate port 5. ldaps:// on 636 6. lsaps:// on alternate port 7. #3,4,5,6 using multiple hosts and multiple certs 8. #3,4,5,6 using mutual authentication Any I've missed? One thing that bothered me while I was testing this. Even if the start_tls fails, authentication still succeeds and content is returned. Since we are assuming forced TLS, authentication should fail if the TLS connection fails. It probably shouldn't be allowed to fall back to unsecure. Brad >>> Graham Leggett <[EMAIL PROTECTED]> Monday, January 10, 2005 12:41:02 PM >>> [EMAIL PROTECTED] wrote: > URL: http://svn.apache.org/viewcvs?view=rev&rev=124824 > Log: > Remove the call to ldapssl_install_routines for the Novell SDK. Do to the warning that states that if any other ldap call is made between the calls to ldap_init() and ldapssl_install_routines(), it is safer for the Novell SDK to always initialize the connection using ldapssl_init(). Suggest that other SDKs do the same. This is incompatible with client certificates on OpenLDAP - here client certs are configured between ldap_init() and apr_ldap_set_option() on a per connection basis, which is impossible if you use ldapssl_init() to init the connection. :( Regards, Graham --
