On 12/04/17 19:34, Heikki Linnakangas wrote:
On 04/11/2017 02:32 PM, Álvaro Hernández Tortosa wrote:
So I still see your proposal more awkward and less clear, mixing
things that are separate. But again, your choice :)
So, here's my more full-fledged proposal.
The first patch refactors libpq code, by moving the responsibility of
reading the GSS/SSPI/SASL/MD5 specific data from the authentication
request packet, from the enormous switch-case construct in
PQConnectPoll(), into pg_fe_sendauth(). This isn't strictly necessary,
but I think it's useful cleanup anyway, and now that there's a bit
more structure in the AuthenticationSASL message, the old way was
The second patch contains the protocol changes, and adds the
documentation for it.
Thanks for the patches :)
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
Name of a SASL authentication mechanism.
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
On a side note, I'd mention that the list of SASL authentication
mechanisms contains valid IANA Registry SCRAM names
SCRAM authentication messages (making it more clear what values would be
expected there from the client).
I hope to start testing this from Java the coming weekend. I will
keep you posted.
Álvaro Hernández Tortosa
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: