RE: tls-related ldap_perror misleading in clients

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

At 03:05 AM 2001-09-02, Howard Chu wrote:
>Aside from how the messages are printed, I think that ldap_start_tls_s
>and/or ldap_int_tls_start ought to set ld->ld_errno before returning an
>error. I think
>that's the more immediate fix.

Thou I dislike the mixing of API errors and protocol resultCodes,
I might have to agree here... this would allow more descriptive
information to be made available to the application (such as
the SSL error string).


>  -- Howard Chu
>  Chief Architect, Symas Corp.       Director, Highland Sun
>  http://www.symas.com               http://highlandsun.com/hyc
>
>> -----Original Message-----
>> From: owner-openldap-devel@OpenLDAP.org
>> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga
>> Sent: Sunday, September 02, 2001 1:36 AM
>
>> At 01:26 AM 2001-09-02, Kurt D. Zeilenga wrote:
>> >At 12:48 AM 2001-09-02, Pierangelo Masarati wrote:
>> >>Hi.
>> >>
>> >>I got a nasty behavior out of the clients when using -ZZ, because I was
>> >>having failure of the tls with reason ": Success". This is because the
>> >>failure occurred in ldap_int_tls_start() which didn't properly set the
>> >>error in the LDAP structure. So ldap_start_tls_s returns an error code,
>> >>but when the ldap_perror is invoked by the ldap*.c client the string is
>> >>success. I fixed it by using ldap_err2string() instead of ldap_perror
>> >>(which is deprecated in the code according to a comment);
>> >>if there's consensus I'll patch all the clients.
>> >
>> >For now, this is likely the best solution.
>>
>> Actually, use of just ldap_err2string() will not print the
>> server provided additional information.  So, I suggest using
>> ldap_get_option() to get the resultCode and error message.  If
>> resultCode is not success, then one can mimic ldap_perror()
>> (w/ error message).  If resultCode is success, then then a
>> similar error message should be printed using the
>> ldap_err2string().
>>