[Date Prev][Date Next]
RE: SSL sessions
At 01:51 PM 2002-09-20, Howard Chu wrote:
>I don't see how. An SSL session has to be associated with a particular
>connection. If you specify multiple hosts/URIs or a particular hostname is a
>multiplexer for several different servers/addresses, the LDAP session handle
>will have multiple connections. Also if the operation causes a referral to be
>followed. Each of those connections to different servers will involve
>distinct SSL sessions and those connections are created/used without any
>possible interaction from the app.
Yes... if the callback can be generalized to do other things, great.
(In redesign the API (if we ever do), I'd treat the LDAP session
handle as a single LDAP session and have some other handle, say
a directory handle, to manage multiple LDAP sessions. But, I'm
not prepared to redesign the API just yet.)
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support
>> -----Original Message-----
>> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
>> At 12:48 PM 2002-09-20, Howard Chu wrote:
>> >Perhaps a callback function for newly created LDAP connections
>> then, to give
>> >the app a chance to set things before the connection gets used.
>> It likely can be done just ldap_set_option()... e.g., no callbacks.
>> > -- Howard Chu
>> > Chief Architect, Symas Corp. Director, Highland Sun
>> > http://www.symas.com http://highlandsun.com/hyc
>> > Symas: Premier OpenSource Development and Support
>> >> -----Original Message-----
>> >> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
>> >> Sent: Friday, September 20, 2002 12:18 PM
>> >> To: Howard Chu
>> >> Cc: openldap-devel@OpenLDAP.org
>> >> Subject: Re: SSL sessions
>> >> At 11:04 PM 2002-09-19, Howard Chu wrote:
>> >> >The second option is to pass back in the SSL_CTX index key.
>> Since the SSL
>> >> >session cache lives longer than an LDAP session handle, libldap can't
>> >> >remember the index key between unbinds, it's up to the
>> >> application to save it
>> >> >and pass it back in when creating a new LDAP session.
>> >> I prefer an approach which allows the application to manage
>> >> its SSL contexts... then we can divorce their issues from
>> >> ours.