Re: [HACKERS] Letting the client choose the protocol to use during aSASL exchange

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 
> getting awkward.
>
> The second patch contains the protocol changes, and adds the 
> documentation for it.
>
> - Heikki
>
    Hi Heikki.
    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
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?
    On a side note, I'd mention that the list of SASL authentication 
mechanisms contains valid IANA Registry SCRAM names 
(https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml#scram)for 
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


-- 

Álvaro Hernández Tortosa


-----------
<8K>data