Feedback-ID: ie0a040ee:Fastmail
Message-ID: <effc7572-c7ce-4ff2-9066-91d084401e1c@eisentraut.org>
Date: Wed, 8 Jan 2025 20:37:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Daniel Gustafsson <daniel@yesql.se>, Antonin Houska <ah@cybertec.at>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
References: <d1b467a78e0e36ed85a09adf979d04cf124a9d4b.camel@vmware.com>
 <63648.1728384409@antos> <2453.1729230681@antos>
 <CAOYmi+mJkc4mLD0+LtbZ1VxeFUSOQvXQ_HUx6eBBmHTXLuoK3g@mail.gmail.com>
 <CAOYmi+=xf76rSLy+eMVecgmyJwEnRp+iFXrbdo4z+p5McrxSBA@mail.gmail.com>
 <CAOYmi+mbiD+efRiS+hH1mdTB4J6pjbr053+jo+BsXKrQjopCSg@mail.gmail.com>
 <CAOYmi+kHXMG2Z2KR7y36Cbsop_7t-YugrpfCnOXuXz8BpfaXaw@mail.gmail.com>
 <6bde5f56-9e7a-4148-b81c-eb6532cb3651@eisentraut.org>
 <CAOYmi+=ee8H=GaGNH_gZvBE+YPtmK9eqUdXqemk=zKDnO8YXRw@mail.gmail.com>
 <CAOYmi+kLTJ1wZ6gxRbgtR52E=EyiCpmp6J3mmSvtc1a6i7sZ3Q@mail.gmail.com>
 <CAOYmi+=ceXepXOrQXsxca-u57GxM+x_q34fpyNJ8PLmbUWPwEQ@mail.gmail.com>
 <9B417838-B872-453D-BBFB-99FA957EB723@yesql.se>
 <CAOYmi+=vJQ8EUiVf-iHYBwz4-tLHLrvp8rYDoNicB2yJrBKraw@mail.gmail.com>
 <CAOYmi+=FzVg+C-pQHCwjW0qU-POHmzZaD2z3CdsACj==14H8kQ@mail.gmail.com>
 <b09bc106-32f2-4e71-8c35-4db8608776a1@eisentraut.org>
 <CAOYmi+kjPLfT7iFqNMVV44sAUJ9m10TfrSMRPUYU2OgH5j0AYg@mail.gmail.com>
Content-Language: en-US
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: <CAOYmi+kjPLfT7iFqNMVV44sAUJ9m10TfrSMRPUYU2OgH5j0AYg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/effc7572-c7ce-4ff2-9066-91d084401e1c%40eisentraut.org>
Precedence: bulk

On 07.01.25 23:24, Jacob Champion wrote:
> On Thu, Jan 2, 2025 at 2:11 AM Peter Eisentraut <peter@eisentraut.org> wrote:
>> There is a mix of using "URL" and "URI" throughout the patch.  I tried
>> to look up in the source material (RFCs) what the correct use would
>> be, but even they are mixing it in nonobvious ways.  Maybe this is
>> just hopelessly confused, or maybe there is a system that I don't
>> recognize.
> 
> Ugh, yeah. I think my "system" was whether the RFC I read most
> recently had used "URL" or "URI" more in the text.
> 
> In an ideal world, I'd just switch to "URL" to avoid confusion. There
> are some URNs in use as part of OAuth (e.g.
> `urn:ietf:params:oauth:grant-type:device_code`) but I don't think I
> refer to those as URIs anyway. And more esoteric forms of URI (data:)
> are not allowed.
> 
> However... there are some phrases, like "Well-Known URI", where that's
> just the Name of the Thing. Similarly, when the wire protocol itself
> uses "URI" (say, in JSON field names), I'd rather be consistent to
> make searching easier.
> 
> Is it enough to prefer "URL" in the user-facing documentation (at
> least, when it doesn't conflict with other established naming
> conventions), and accept both in the code?

The above explanation makes sense to me.  I don't know what you mean by 
"accept in the code".  I would agree with "tolerate some inconsistency" 
in the code but not with, like, create alias names for all the interface 
names.

> 
>> * src/interfaces/libpq/libpq-fe.h
>>
>> +#ifdef WIN32
>> +#include <winsock2.h>          /* for SOCKET */
>> +#endif
>>
>> Including a system header like that seems a bit unpleasant.  AFAICT,
>> you only need it for this:
>>
>> +   PostgresPollingStatusType (*async) (PGconn *conn,
>> +                                       struct _PGoauthBearerRequest
>> *request,
>> +                                       SOCKTYPE * altsock);
>>
>> But that function could already get the altsock handle via
>> conn->altsock.  So maybe that is a way to avoid the whole socket type
>> dance in this header.
> 
> It'd also couple clients against libpq-int.h, so they'd have to
> remember to recompile every release. I'm worried that'd cause a bunch
> of ABI problems...

Couldn't that function use PQsocket() to get at the actual socket from 
the PGconn handle?

>> * src/test/modules/oauth_validator/fail_validator.c
>>
>> +{
>> +   elog(FATAL, "fail_validator: sentinel error");
>> +   pg_unreachable();
>> +}
>>
>> This pg_unreachable() is probably not necessary after elog(FATAL).
> 
> Cirrus completes successfully with that, but MSVC starts complaining:
> 
>      warning C4715: 'fail_token': not all control paths return a value
> 
> Is that expected?

Ah yes, because MSVC doesn't support the noreturn attribute.  (See 
<https://www.postgresql.org/message-id/flat/pxr5b3z7jmkpenssra5zroxi7qzzp6eswuggokw64axmdixpnk%40zbwxuq7gbbcw>.) 
  So ok to leave as you had it for now.