Re: Sane error messages for SSL retry cases - Mailing list pgsql-hackers

Is this a TODO?  I don't see how it is a new problem, meaning it
probably is for 8.3.

---------------------------------------------------------------------------

Tom Lane wrote:
> As per a recent discussion in pgsql-admin,
> http://archives.postgresql.org/pgsql-admin/2006-09/msg00297.php
> libpq doesn't cope well with the situation where the server is
> configured to allow only SSL connections (or only non-SSL connections)
> and there is some unrelated-to-SSL connection problem such as wrong
> password.  The reason is that libpq is set up to retry with the other
> kind of connection (either dropping or adding SSL) for just about any
> sort of error returned by the server.  This may lead to reporting "no
> pg_hba.conf entry", or some such, rather than the more useful "password
> authentication failed".
> 
> I am tempted to propose that libpq should only retry in the other mode
> when the server specifically returns "no pg_hba.conf entry", and not for
> other server errors (beyond the initial do-you-do-SSL-at-all handshake
> of course).  This would save a useless fork() cycle on the server as
> well as make it more likely that we return a useful error message.
> 
> There are some corner cases where this might fail to connect when
> a blind retry would have succeeded, but they all involve the server
> offering different auth methods depending on SSL or not --- an example
> is "hostssl + ident" and "hostnossl + password", and you fail the ident
> test but could have produced the correct password.  ISTM that is a
> scenario where the user should use the "sslmode" parameter to control
> which method is tried first.
> 
> One problem with implementing this proposal is that we currently use the
> generic INVALID_AUTHORIZATION_SPECIFICATION sqlstate for a bunch of
> distinct conditions including "no pg_hba.conf entry".  Looking directly
> at the error string is of course not localization-proof, so we'd have to
> break down that errcode into some more-specific categories.  Which is
> probably not a bad idea anyway, but it would mean that the nicer
> behavior would only happen when talking to an 8.2 or later server.
> 
> Thoughts?  Is this something to tackle during beta, or must we put it
> off till 8.3?
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
> 
>                http://www.postgresql.org/docs/faq

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +