Re: svn commit: r124824 - /apr/apr-util/trunk/ldap/apr_ldap_option.c

[Brad Nicholes <BN...@novell.com>]

  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 <mi...@sharp.fm> Monday, January 10, 2005 12:41:02
PM >>>
bnicholes@apache.org 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
--