From: Tom Lane <tgl@sss.pgh.pa.us>
To: Adrian Vogelsgesang <avogelsgesang@tableau.com>
cc: "pgsql-interfaces@lists.postgresql.org"
 <pgsql-interfaces@lists.postgresql.org>
Subject: Re: Libpq: Fail connection attempt if server didn't request a
 password
In-reply-to: 
 <BY5PR03MB4965271A9AE58B7367D1DB52A3A70@BY5PR03MB4965.namprd03.prod.outlook.com>
References: 
 <BY5PR03MB4965271A9AE58B7367D1DB52A3A70@BY5PR03MB4965.namprd03.prod.outlook.com>
Comments: In-reply-to Adrian Vogelsgesang <avogelsgesang@tableau.com>
	message dated "Fri, 15 Jan 2021 17:56:54 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1686502.1610752878.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 15 Jan 2021 18:21:18 -0500
Message-ID: <1686503.1610752878@sss.pgh.pa.us>
Precedence: bulk

Adrian Vogelsgesang <avogelsgesang@tableau.com> writes:
> Is there some way to let libpq fail the connection attempt in such a cas=
e, i.e. if a password was provided but not requested from the server?

Why would that be a useful thing to do?

> 1. To identify misconfigured server. In our use case, all servers should=
 require a password. By failing hard and early, we can more easily find mi=
sconfigured servers

I find that argument quite unconvincing.  You can easily look into
pg_hba.conf to see if any lines don't have an auth method you like.
Moreover, that approach scales to requirements that are more complicated
than this specific use-case, and you can be sure that *all* the entries
satisfy your business rule, not just the one you happened to match this
time.

> Can I, as the client, force the authentication used during creating a co=
nnection to be scram-sha-256?

There has been discussion of that, but no one has written a patch yet.

			regards, tom lane