Re: ldap_bind

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 06:14 PM 1/28/00 +1100, bernard.gardner@au.uu.net wrote:
>In libraries/libldap/bind.c the ldap_bind client call is
>implemented as a switch statement on the authmethod
>parameter, which (if HAVE_KERBEROS isn't defined) has
>only one case. This case calls the ldap_simple_bind
>function, which then hard codes the value of authmethod
>to LDAP_AUTH_SIMPLE.
>
>This seems like it's arse about to me. Why not implement
>the less general routine as a call to the more general,
>with the arguments hard coded appropriately?

ldap_bind is a deprecated routine.  It would be inappropriate
to depend ldap_simple_bind(), which is not deprecated, in
terms of ldap_bind().

>Is there any reason why the client library needs to be
>particularly aware of the bind method in use, or refuse
>to allow unknown bind methods?

Yes.  The library needs to know how to encode/decode
BIND messages.  BIND message encoding is authentication
method dependent.

Note that the library does support application specified
authentication mechanisms via SASL.  As the encoding
is independent of mechanism, the library need to know
what mechanism is in use.

>anything other than a
>NULL terminated string, but why prevent a client from
>sending a strange authmethod to the server, which might
>well support it, and is surely capable of returning
>LDAP_AUTH_UNKNOWN or LDAP_UNWILLING_TO_PERFORM if it's
>not in the mood?

Or LDAP_PROTOCOL_ERROR.  In networking, it is generally
viewed as good practice to only generate messages which
strictly adhere to specifications.