On Tue, Apr 11, 2017 at 4:41 AM, Heikki Linnakangas <hlinn...@iki.fi> wrote:
> On 04/10/2017 09:33 PM, Álvaro Hernández Tortosa wrote:
>> - If the username used is the one sent in the startup message, rather
>> than leaving it empty in the client-first-message, I would force it to
>> be the same as the used in the startuo message.
> The problem with that is that the SCRAM spec dictates that the username must
> be encoded in UTF-8, but PostgreSQL supports non-UTF-8 usernames.
> Or did you mean that, if the username is sent, it must match the one in the
> startup packet, but an empty string would always be allowed? That would be
> reasonable.

That sounds sensible from here.

>> Otherwise we may confuse
>> some client implementations which would probably consider that as an
>> error; for one, my implementation would currently throw an error if
>> username is empty, and I think that's correct.
> I'm not sure I follow. The username is sent from client to server, and
> currently, the server will ignore it. If you're writing a client library, it
> can send whatever it wants. (Although again I would recommend an empty
> string, to avoid confusion. Sending the same username as in the startup
> packet, as long as it's in UTF-8, seems reasonable too.)
> Thanks for reviewing this! I'll start hacking on code changes to go with
> these docs.

Sounds good to me, thanks! I looked at the doc patch for now, and here
are some nits.

+  <para>
+    SCRAM-SHA-256 is the only implemented SASL mechanism, at the moment. It is
+    described in detail in [RFC7677] and [RFC5741]. (called just
SCRAM from now on)
+  </para>
Perhaps those should be links to the RFCs.

+  Client sends a SASLResponse messsage, with SCRAM
+  <literal>client-final-message</literal> as the content.
Typo. Message needs two 's'.

+  <literal>server-final-message</> in the "additional data" field.
I think that you are missing a </sect1> markup here.

+                Authentication method specific "additional data". If this
+                message contains no additional data, this field is omitted.
So that's for the first message generated by the client in the
exchange. Better than my previous idea. Shouldn't double quotes be
replaced by proper markups?

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to