public inbox for [email protected]
help / color / mirror / Atom feedFrom: Peter Eisentraut <[email protected]>
To: Jacob Champion <[email protected]>
Cc: Daniel Gustafsson <[email protected]>
Cc: Antonin Houska <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
Date: Wed, 8 Jan 2025 20:37:12 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAOYmi+kjPLfT7iFqNMVV44sAUJ9m10TfrSMRPUYU2OgH5j0AYg@mail.gmail.com>
References: <[email protected]>
<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>
<[email protected]>
<CAOYmi+=ee8H=GaGNH_gZvBE+YPtmK9eqUdXqemk=zKDnO8YXRw@mail.gmail.com>
<CAOYmi+kLTJ1wZ6gxRbgtR52E=EyiCpmp6J3mmSvtc1a6i7sZ3Q@mail.gmail.com>
<CAOYmi+=ceXepXOrQXsxca-u57GxM+x_q34fpyNJ8PLmbUWPwEQ@mail.gmail.com>
<[email protected]>
<CAOYmi+=vJQ8EUiVf-iHYBwz4-tLHLrvp8rYDoNicB2yJrBKraw@mail.gmail.com>
<CAOYmi+=FzVg+C-pQHCwjW0qU-POHmzZaD2z3CdsACj==14H8kQ@mail.gmail.com>
<[email protected]>
<CAOYmi+kjPLfT7iFqNMVV44sAUJ9m10TfrSMRPUYU2OgH5j0AYg@mail.gmail.com>
On 07.01.25 23:24, Jacob Champion wrote:
> On Thu, Jan 2, 2025 at 2:11 AM Peter Eisentraut <[email protected]> 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%40zbwx...;.)
So ok to leave as you had it for now.
view thread (67+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox