[Date Prev][Date Next]
Re: StartTLS URL extension
Philip Guenther wrote:
> On Mon, 6 Oct 2008, Michael Ströder wrote:
>> Pierangelo Masarati wrote:
>>> Michael Ströder wrote:
>>>> Yes I also find it useful. Not sure whether it should be within
>>>> ldap_initialize() or just in the client apps though.
> In ldap_initialize(), please. IMO, the proposal solves two problems:
> 1) it lets you use StartTLS with applications without the application
> author having to add code (and an option, probably) to do so
> 2) it lets you naturally request StartTLS on a per-URI basis
> The former is only obtained if this is done from the library.
I can see the advantages, especially since I have somthing like this in
web2ldap's LDAP URL handling.
>>>> The first could be problematic if client applications just read the LDAP
>>>> URI from some configuration file and pass it as is to ldap_initialize()
>>>> and after that call ldap_start_tls() a second time based on different
>>>> configuration parameters.
> Seem, like a non-problem to me: if the app has an "ldap-tls" option, you
> would document that the user should not turn that option on if using the
> starttls URI extension or vice versa.
> (All of Sendmail's products that use LDAP have such an option, plus logic
> to only use ldap_start_tls_s() on plain ldap:// URIs and not ldaps:// or
> ldapi:// URIs, but I think putting this in the URI is the Right Thing and
> see no long-term problems with supporting this.)
It's slightly different: From my understanding up to now
ldap_initialize() itself did not send out a LDAP PDU. So the error
handling of applications might not be prepared for ldap_initialize()
causing a real error. This is an incompatible API change.
> Such apps have a problem already, as they have to exclude ldaps:// URIs
> from that. This is just like an ldaps URI, except instead of starting
> with "ldaps", it ends with "starttlsOIDgoop".
It's not the same since calling ldap_start_tls() sends out the first
LDAP PDU which might lead to another error.