From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Letting the client choose the protocol to use during a SASL exchange |
Date: | 2017-04-07 08:33:52 |
Message-ID: | a9dfecf8-d830-d854-c826-6ce0892a08b8@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 04/06/2017 11:05 PM, Tom Lane wrote:
> Perhaps we could turn this around: have the client send (in the connection
> request packet) a list of auth protocols it thinks it is able to handle.
> (I'm envisioning this as being more or less fixed for any one version of
> any one client, since it would basically mean "I have code to do X, Y, or
> Z".) Then the server can pick one that is allowed by pg_hba.conf, or it
> can just ignore the list and send what it wants anyway, probably leading
> to client disconnect.
That list of supported authentication methods would need to be included
in the startup message. Unfortunately, there is no way to add options to
the startup message, without breaking compatibility with old servers. If
there is an option in the startup message that the server doesn't
understand, it will treat it as a GUC, and you get an "unrecognized
configuration parameter" after authentication.
It would be nice to change that, so that the server would ignore
parameters that it doesn't understand that begin with "optional_"
prefix, for example. But it won't help us right now.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2017-04-07 08:57:52 | Re: Letting the client choose the protocol to use during a SASL exchange |
Previous Message | Heikki Linnakangas | 2017-04-07 08:17:43 | Re: Letting the client choose the protocol to use during a SASL exchange |