RE: SSL sessions

["Howard Chu" <hyc@highlandsun.com>]

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.

  -- 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.
> >>
>