Re: Letting the client choose the protocol to use during a SASL exchange
Michael Paquier <michael.paquier@gmail.com>
From: Michael Paquier <michael.paquier@gmail.com>
To: Álvaro Hernández Tortosa <aht@8kdata.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2017-04-13T02:54:59Z
Lists: pgsql-hackers
On Thu, Apr 13, 2017 at 6:37 AM, Álvaro Hernández Tortosa <aht@8kdata.com> wrote: > By looking at the them, and unless I'm missing something, I don't see > how the extra information for the future implementation of channel binding > would be added (without changing the protocol). Relevant part is: > > The message body is a list of SASL authentication mechanisms, in the > server's order of preference. A zero byte is required as terminator after > the last authentication mechanism name. For each mechanism, there is the > following: > <variablelist> > <varlistentry> > <term> > String > </term> > <listitem> > <para> > Name of a SASL authentication mechanism. > </para> > </listitem> > </varlistentry> > </variablelist> > How do you plan to implement it, in future versions, without modifying > the AuthenticationSASL message? Or is it OK to add new fields to a message > in future PostgreSQL versions, without considering that a protocol change? I don't quite understand the complain here, it is perfectly fine to add as many null-terminated names as you want with this model. The patches would make the server just send one mechanism name now, but nothing prevents the addition of more. -- Michael
Commits
-
Improve the SASL authentication protocol.
- 4f3b87ab780b 10.0 landed
-
Refactor libpq authentication request processing.
- 61bf96cab063 10.0 landed
-
Minor cleanup of backend SCRAM code.
- 00707fa58275 10.0 landed