On Wed, Jul 26, 2017 at 6:51 AM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> Hi hackers,
>
> Some LDAP error codes are a bit vague. For example:
>
> LDAP_CONNECT_ERROR Indicates a connection problem.
> LDAP_PROTOCOL_ERROR A protocol violation was detected.
>
> To learn more, you have to call
> ldap_get_option(LDAP_OPT_DIAGNOSTIC_MESSAGE). Should we do that? For
> example, instead of:
>
> LOG: could not start LDAP TLS session: Protocol error
>
> ... you could see:
>
> LOG: could not start LDAP TLS session: Protocol error
> DETAIL: LDAP diagnostic message: unsupported extended operation
>
> Well, that may not be the most illuminating example, but that's a
> message sent back by the LDAP server that we're currently throwing
> away, and can be used to distinguish between unsupported TLS versions,
> missing StartTLS extension and various other cases. Perhaps that
> particular message would also be available via your LDAP server's
> logs, if you can access them, but in some cases we're throwing away
> client-side messages that are not available anywhere else like "TLS:
> unable to get CN from peer certificate", "TLS: hostname does not match
> CN in peer certificate" and more.
>
+1.
> Something like the attached.
The patch prints errdetail() as "No LDAP diagnostic message
available." when LDAP doesn't provide diagnostics. May be some error
messages do not have any diagnostic information. In that case above
error detail may be confusing. May be we should just omit error
details when diagnostic message is not available.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company