On Dec 1, 2007 12:06 PM, Graham Leggett <[EMAIL PROTECTED]> wrote: > Eric Covener wrote: > > > ldap_ssl_client_init() should be called once per process, not once per > > connection. > > The LDAP SDK uses the ldap_set_option function for both once-per-process > values (LDAP* is NULL) and once-per-connection values, and > apr_ldap_set_option follows this pattern as well. > > Remember that one of the basic design goals of the APR LDAP code is to > offer a consistent interface to 8 distinct APR LDAP clients, regardless > of the underlying LDAP implementation, and this has been a mindbending > task. Adding init code exclusively to apr_ldap_ssl_init() instead of > apr_ldap_set_option() makes the Tivoli support work differently to the > support maintained by other toolkits, and introduces inconsistent > behaviour, which is exactly what the API is trying to avoid.
Upon return from apr_ldap_ssl_init(), SSL has not been initialised on the underlying toolkit. If the entire function, and not just the setting of certificates is deprecated, we should make that more clear. Additionally, it looks like if you "fail" to initialize SSL (native return code indicating "already initialized" but maybe with different SSL parameters) in the per-connection context you're going to trigger a failure in apr_ldap_init() which the program will see unnecessarily and would have a difficult time coping with.. We can more elaborately trap native return codes, and try to ignore some of the OPT_TLS failures, but it makes more sense to me to bake-in the knowledge of when an SDK ought to call these functions at all. > It cannot be assumed that other toolkits may be able to be further > configured after the first LDAP connection is established. the crux of the problem here is that setting the OPT_TLS_CERT and creating the connection are two disjoint operations in APR, whereas to be the most portable you'd want to have the complete set of information available all at once (or have somewhere opaque to stash away the cert info to use on the subsequent init() call) -- Eric Covener [EMAIL PROTECTED]
