On Wed, 2021-07-07 at 14:08 +0900, Michael Paquier wrote:
> On Tue, Jul 06, 2021 at 06:20:49PM +0000, Jacob Champion wrote:
> > On Mon, 2021-07-05 at 17:17 +0900, Michael Paquier wrote:
> >
> > > Hmm. Does the RFCs tell us anything about that?
> >
> > Just in general terms:
> >
> > > Each authentication exchange consists of a message from the client to
> > > the server requesting authentication via a particular mechanism,
> > > followed by one or more pairs of challenges from the server and
> > > responses from the client, followed by a message from the server
> > > indicating the outcome of the authentication exchange. (Note:
> > > exchanges may also be aborted as discussed in Section 3.5.)
> >
> > So a challenge must be met with a response, or the exchange must be
> > aborted. (And I don't think our protocol implementation provides a
> > client abort message; if something goes wrong, we just tear down the
> > connection.)
>
> Thanks. At the same time, section 3.5 also says that the client may
> send a message to abort. So one can interpret that the client has
> also the choice to abort without sending a response back to the
> server? Or I am just interpreting incorrectly the use of "may" in
> this context?
That's correct. But the client may not simply ignore the challenge and
keep the exchange open waiting for a new one, as pg_SASL_continue()
currently allows. That's what my TODO is referring to.
--Jacob
