Re: Time to get rid of PQnoPasswordSupplied? - Mailing list pgsql-hackers

On 19 June 2015 at 22:35, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sun, Jun 14, 2015 at 11:34 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
>>> I frequently see users confused by one of our more common and less
>>> clear error messages:
>>>
>>> fe_sendauth: no password supplied
>
>> I've never seen this error message, but I'm not opposed to improving
>> it in some way.
>
> The reason you don't see it is that psql and other clients take special
> action (ie, prompt you for a password) instead of actually showing you
> that error string when it's returned by libpq.

> Apparently, Craig is responsible for some client-side code that has never
> heard of either convention and just fails instead of prompting for a
> password.  So improving that might be something to put on somebody's
> to-do list.

I'm not responsible for clients that do this, I just interact with
enough communities outside -hackers that I see new users confused by
such clients a *lot*.  It's very common for most libpq based client
libraries, like Python's psycopg2, PHP's pg_connect, etc.

Have a look at

https://www.google.com.au/?q=%22fe_sendauth%3A%20no%20password%20supplied%22

to get an idea of the confusion.


Unfortunately, after some more thought I don't think we can remove it
until the next protocol rev. Sure, the symbol can be removed from the
libpq headers since (as below) there's almost nobody using it, but we
can't actually change the string sent by the server so it does no
good. So it's really a matter of fixing individual clients to actually
use PQconnectionNeedsPassword(...) .

The main reason the string the server sends can't be changed is that
there will be old copies of libpq floating around for ages, and a code
search suggests that there are also lots and lots of copies of libpq
in various random projects' source trees.


For anyone else looking at this later, I've had a look at users of the API.

PgAdmin-III still uses the obsolete API and should be patched. It's
the only reasonably relevant user of PQnoPasswordSupplied that I
found.

Newer versions of Ruby's 'Pg' gem seem to use
PQconnectionNeedsPassword and make no reference to
PQnoPasswordSupplied or a hardcoded string equivalent. Older versions
didn't reference either and just passed the raw message to the user.

RPostgreSQL also uses PQconnectionNeedsPassword .

psycopg2, PHP's pg_connect and PHP's PDO driver for pg, libdbi, and
Perl's DBD::Pg do no password-required detection and just spit
"fe_sendauth: no password supplied" out at the user. There's no
reference to PQnoPasswordSupplied, PQconnectionNeedsPassword or
fe_sendauth in their source trees.

None of these clients will care about the change. Some of them should
be taught to use PQconnectionNeedsPassword, of course, but that's
separate.

A search of http://code.openhub.net/search?s=%22PQnoPasswordSupplied%22
suggests that few users of PQnoPasswordSupplied exist, and most of
those are copies of libpq.

> On the other hand, you could argue that improving the string is going
> to break clients that do the right thing (even if klugily) in order
> to help clients that are doing the wrong thing (ie, failing without
> offering the opportunity to enter a password).  Ideally no client app
> would ever show this message to users and so its readability would not
> matter.

Yes. I think it's basically part of the v3 protocol and we're stuck
with it until the next protocol rev.

I'll poke client driver writers instead.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services