On 06.11.24 00:33, Jacob Champion wrote:
Done in v36, attached.
Assorted review comments from me:
Everything in the commit message between
= Debug Mode =
and
Several TODOs:
should be moved to the documentation. In some cases, it already is,
but it doesn't always have the same leve
On Tue, Nov 5, 2024 at 3:33 PM Jacob Champion
wrote:
> Done in v36, attached.
Forgot to draw attention to this part:
> +# XXX libcurl must link after libgssapi_krb5 on FreeBSD to avoid
> segfaults
> +# during gss_acquire_cred(). This is possibly related to Curl's Heimdal
> +# depend
On Sun, Nov 3, 2024 at 9:00 PM jian he wrote:
> The above Assert looks very wrong to me.
I can switch to Assert(false) if that's preferred, but it makes part
of the libc assert() report useless. (I wish we had more fluent ways
to say "this shouldn't happen, but if it does, we still need to get
ou
> On 4 Nov 2024, at 06:00, jian he wrote:
> + if (cnt != 1)
> + {
> + /*
> + * Either the lexer screwed up or our assumption above isn't true, and
> + * either way a developer needs to take a look.
> + */
> + Assert(cnt == 1);
> + return 1; /* don't fall through in release builds */
> + }
> The
Hi there.
zero knowledge of Oath, just reading through the v35-0001.
forgive me if my comments are naive.
+static int
+parse_interval(struct async_ctx *actx, const char *interval_str)
+{
+ double parsed;
+ int cnt;
+
+ /*
+ * The JSON lexer has already validated the number, which is stricter than
On Thu, Oct 31, 2024 at 4:05 AM Antonin Houska wrote:
> > > And regardless, the library appears to be loaded by every backend during
> > > authentication. Why isn't it loaded by postmaster like libraries listed
> > > in
> > > shared_preload_libraries? fork() would then ensure that the backe
Jacob Champion wrote:
> On Thu, Oct 17, 2024 at 10:51 PM Antonin Houska wrote:
> > * oauth_validator_library is defined as PGC_SIGHUP - is that intentional?
>
> Yes, I think it's going to be important to let DBAs migrate their
> authentication modules without a full restart. That probably deser
On Tue, Oct 29, 2024 at 10:41 AM Daniel Gustafsson wrote:
> Question is though, if we added PAM
> today would we have done the same?
I assume so; the client can't tell PAM apart from LDAP or any other
plaintext method. (In the same vein, the server can't tell if the
client uses libcurl to grab a
> On 29 Oct 2024, at 17:40, Jacob Champion
> wrote:
>
> On Tue, Oct 29, 2024 at 3:52 AM Daniel Gustafsson wrote:
>> Currently we don't support any conditional compilation which only affects
>> backend or frontend, all --without-XXX flags turn it off for both.
>
> I don't think that's strictly
On Tue, Oct 29, 2024 at 3:52 AM Daniel Gustafsson wrote:
> Currently we don't support any conditional compilation which only affects
> backend or frontend, all --without-XXX flags turn it off for both.
I don't think that's strictly true; see --with-pam which affects only
server-side code, since t
> On 28 Oct 2024, at 17:09, Jacob Champion
> wrote:
> On Mon, Oct 28, 2024 at 6:24 AM Daniel Gustafsson wrote:
>> Looking more at the patchset I think we need to apply conditional compilation
>> of the backend for oauth like how we do with other opt-in schemes in
>> configure
>> and meson. Th
On Mon, Oct 28, 2024 at 6:24 AM Daniel Gustafsson wrote:
> > On 25 Oct 2024, at 20:22, Jacob Champion
> > wrote:
>
> > I have combed almost all of Daniel's feedback backwards into the main
> > patch (just the new bzero code remains, with the open question
> > upthread),
>
> Re-reading I can't se
> On 25 Oct 2024, at 20:22, Jacob Champion
> wrote:
> I have combed almost all of Daniel's feedback backwards into the main
> patch (just the new bzero code remains, with the open question
> upthread),
Re-reading I can't see a vector there, I guess I am just scarred from what
seemed to be harml
On Fri, Oct 18, 2024 at 4:38 AM Daniel Gustafsson wrote:
> In validate() it seems to me we should clear out ret->authn_id on failure to
> pair belts with suspenders. Fixed by calling explicit_bzero on it in the error
> path.
The new hunk says:
> cleanup:
> /*
> * Clear and free the vali
On Thu, Oct 17, 2024 at 10:51 PM Antonin Houska wrote:
> This is the 1st round, based on reading the code. I'll continue paying
> attention to the project and possibly post some more comments in the future.
Thanks again for the reviews!
> * Information on the new method should be added to pg_hba
Antonin Houska wrote:
> I'd like to play with the code a bit and provide some review before or during
> the next CF. That will probably generate some more questions.
This is the 1st round, based on reading the code. I'll continue paying
attention to the project and possibly post some more commen
On 15.10.24 20:10, Jacob Champion wrote:
On Tue, Oct 15, 2024 at 11:00 AM Alexander Lakhin wrote:
I've discovered that starting from 0785d1b8b,
make check -C src/bin/pg_combinebackup
fails under Valgrind, with the following diagnostics:
Yep, sorry for that (and thanks for the report!). It's c
On Tue, Oct 15, 2024 at 11:00 AM Alexander Lakhin wrote:
> I've discovered that starting from 0785d1b8b,
> make check -C src/bin/pg_combinebackup
> fails under Valgrind, with the following diagnostics:
Yep, sorry for that (and thanks for the report!). It's currently
tracked over at [1], but I sho
Hello Peter,
11.09.2024 10:37, Peter Eisentraut wrote:
This has been committed.
I've discovered that starting from 0785d1b8b,
make check -C src/bin/pg_combinebackup
fails under Valgrind, with the following diagnostics:
2024-10-15 14:29:52.883 UTC [3338981] 002_compare_backups.pl STATEMENT:
On Tue, Oct 8, 2024 at 3:46 AM Antonin Houska wrote:
> Perhaps I understand now. I use getmail [2] to retrieve email messages from my
> Google account. What made me confused is that the getmail application,
> although installed on my workstation (and thus the bearer token it eventually
> gets cont
Jacob Champion wrote:
> On Mon, Sep 30, 2024 at 6:38 AM Antonin Houska wrote:
> >
> > Are you sure you can legitimately acquire the bearer token containing my
> > email
> > address?
>
> Yes. In general that's how OpenID-based "Sign in with "
> works. All those third-party services are running
On Mon, Sep 30, 2024 at 6:38 AM Antonin Houska wrote:
>
> Jacob Champion wrote:
>
> > On Fri, Sep 27, 2024 at 10:58 AM Antonin Houska wrote:
> > That's why people are so pedantic about saying that OAuth is an
> > authorization framework and not an authentication framework.
>
> This statement alo
Antonin Houska wrote:
> Jacob Champion wrote:
> > Now, the token introspection endpoint I mentioned upthread
>
> Can you please point me to the particular message?
Please ignore this dumb question. You probably referred to the email I was
responding to.
--
Antonin Houska
Web: https://www.cyb
Jacob Champion wrote:
> On Fri, Sep 27, 2024 at 10:58 AM Antonin Houska wrote:
> > Have you considered sending the token for validation to the server, like
> > this
> >
> > curl -X GET "https://www.googleapis.com/oauth2/v3/userinfo"; -H
> > "Authorization: Bearer $TOKEN"
>
> In short, no, but
On Fri, Sep 27, 2024 at 10:58 AM Antonin Houska wrote:
> Have you considered sending the token for validation to the server, like this
>
> curl -X GET "https://www.googleapis.com/oauth2/v3/userinfo"; -H
> "Authorization: Bearer $TOKEN"
In short, no, but I'm glad you asked. I think it's going to
Jacob Champion wrote:
> Peter asked me if there were plans to provide a "standard" validator
> module, say as part of contrib. The tricky thing is that Bearer
> validation is issuer-specific, and many providers give you an opaque
> token that you're not supposed to introspect at all.
>
> We coul
On Wed, Sep 11, 2024 at 3:54 PM Jacob Champion
wrote:
> Yeah, and I still owe you all an updated roadmap.
Okay, here goes. New reviewers: start here!
== What is This? ==
OAuth 2.0 is a way for a trusted third party (a "provider") to tell a
server whether a client on the other end of the line is
(Thanks for the commit, Peter!)
On Wed, Sep 11, 2024 at 6:44 AM Daniel Gustafsson wrote:
>
> > On 11 Sep 2024, at 09:37, Peter Eisentraut wrote:
>
> > Is there any sense in dealing with the libpq and backend patches separately
> > in sequence, or is this split just for ease of handling?
>
> I t
On 04.09.24 11:28, Peter Eisentraut wrote:
On 03.09.24 22:56, Jacob Champion wrote:
The parse_strval field could use a better explanation.
I actually don't understand the need for this field. AFAICT, this is
just used to record whether strval is valid.
No, it's meant to track the value of the
On 03.09.24 22:56, Jacob Champion wrote:
The parse_strval field could use a better explanation.
I actually don't understand the need for this field. AFAICT, this is
just used to record whether strval is valid.
No, it's meant to track the value of the need_escapes argument to the
constructor. I
On 28.08.24 18:31, Jacob Champion wrote:
On Mon, Aug 26, 2024 at 4:23 PM Jacob Champion
wrote:
I was having trouble reasoning about the palloc-that-isn't-palloc code
during the first few drafts, so I will try a round with the jsonapi_
prefix.
v27 takes a stab at that. I have kept the ALLOC/FR
On Mon, Aug 26, 2024 at 1:18 AM Peter Eisentraut wrote:
> Or, if people find that too scary, something like
>
> #ifdef JSONAPI_USE_PQEXPBUFFER
>
> #define jsonapi_StringInfo PQExpBuffer
> [...]
>
> That way, it's at least more easy to follow the source code because
> you see a mostly-familiar API.
On 13.08.24 23:11, Jacob Champion wrote:
On Sun, Aug 11, 2024 at 11:37 PM Peter Eisentraut wrote:
I have committed 0002 now.
Thanks Peter! Rebased over both in v26.
I have looked again at the jsonapi memory management patch (v26-0001).
As previously mentioned, I think adding a third or four
On 07.08.24 09:34, Peter Eisentraut wrote:
On 05.08.24 19:53, Jacob Champion wrote:
On Fri, Aug 2, 2024 at 11:48 AM Peter Eisentraut
wrote:
Yes, I think with an adjusted comment and commit message, the actual
change makes sense.
Done in v25.
...along with a bunch of other stuff:
I have co
On 05.08.24 19:53, Jacob Champion wrote:
On Fri, Aug 2, 2024 at 11:48 AM Peter Eisentraut wrote:
Yes, I think with an adjusted comment and commit message, the actual
change makes sense.
Done in v25.
...along with a bunch of other stuff:
I have committed 0001, and I plan to backpatch it onc
On 02.08.24 19:51, Jacob Champion wrote:
But it sounds like we agree that we shouldn't be using fe_memutils at
all in shlib builds. (If you can't use palloc -- it calls exit -- then
you can't use pfree either.) Is 0002 still worth pursuing, once I've
correctly wordsmithed the commit? Or did I mis
On Fri, Aug 2, 2024 at 10:13 AM Peter Eisentraut wrote:
> You shouldn't use pfree() interchangeably with free(), even if that is
> not enforced because it's the same thing underneath. First, it just
> makes sense to keep the alloc and free pairs matched up. And second, on
> Windows there is some
On 30.07.24 00:30, Jacob Champion wrote:
But under what circumstances does "the linker doesn't strip out" happen?
If this happens accidentally, then we should have seen some buildfarm
failures or something?
On my machine, for example, I see differences with optimization
levels. Say you inadve
On Mon, Jul 29, 2024 at 1:51 PM Daniel Gustafsson wrote:
> Together with a colleage we found the Azure provider use "verification_url"
> rather than xxx_uri.
Yeah, I think that's originally a Google-ism. (As far as I can tell
they helped author the spec for this and then didn't follow it. :/ ) I
On Mon, Jul 29, 2024 at 5:02 AM Peter Eisentraut wrote:
> We should take the check for exit() calls from libpq and expand it to
> cover the other libraries as well. Maybe there are other problems like
> this?
Seems reasonable, yeah.
> But under what circumstances does "the linker doesn't strip
Thanks for working on this patchset, I'm looking over 0004 and 0005 but came
across a thing I wanted to bring up one thing sooner than waiting for the
review. In parse_device_authz we have this:
{"user_code", JSON_TOKEN_STRING, {&authz->user_code}, REQUIRED},
{"verification_uri", JSON_TOKEN_ST
I have some comments about the first three patches, that deal with
memory management.
v24-0001-Revert-ECPG-s-use-of-pnstrdup.patch
This looks right.
I suppose another approach would be to put a full replacement for
strndup() into src/port/. But since there is currently only one user,
and mo
On Thu, Mar 28, 2024 at 3:34 PM Daniel Gustafsson wrote:
> In jsonapi.c, makeJsonLexContextCstringLen initialize a JsonLexContext with
> palloc0 which would need to be ported over to use ALLOC for frontend code.
Seems reasonable (but see below, too).
> On
> that note, the errorhandling in parse_
On Thu, Feb 29, 2024 at 1:08 PM Daniel Gustafsson wrote:
> + /* TODO */
> + CHECK_SETOPT(actx, CURLOPT_WRITEDATA, stderr);
> I might be missing something, but what this is intended for in
> setup_curl_handles()?
Ah, that's cruft left over from early debugging, just so that I could
see what wa
On Wed, Feb 28, 2024 at 9:40 AM Daniel Gustafsson wrote:
> +#define ALLOC(size) malloc(size)
> I wonder if we should use pg_malloc_extended(size, MCXT_ALLOC_NO_OOM) instead
> to self document the code. We clearly don't want feature-parity with server-
> side palloc here. I know we use malloc in
> On 27 Feb 2024, at 20:20, Jacob Champion
> wrote:
>
> On Fri, Feb 23, 2024 at 5:01 PM Jacob Champion
> wrote:
>> The
>> patchset is now carrying a lot of squash-cruft, and I plan to flatten
>> it in the next version.
>
> This is done in v17, which is also now based on the two patches pulled
[re-adding the CC list I dropped earlier]
On Wed, Feb 28, 2024 at 1:52 PM Daniel Gustafsson wrote:
>
> > On 28 Feb 2024, at 22:50, Andrew Dunstan wrote:
> > Can you give some more details about what this python gadget would buy us?
> > I note that there are a couple of CPAN modules that provide
> On 28 Feb 2024, at 22:50, Andrew Dunstan wrote:
>
> On 2024-02-28 We 09:05, Jacob Champion wrote:
>>
>> Daniel and I discussed trying a Python version of the test server,
>> since the standard library there should give us more goodies to work
>> with. A proof of concept is in 0009. I think the
On 2024-02-28 We 09:05, Jacob Champion wrote:
Daniel and I discussed trying a Python version of the test server,
since the standard library there should give us more goodies to work
with. A proof of concept is in 0009. I think the big question I have
for it is, how would we communicate what we
> On 28 Feb 2024, at 15:05, Jacob Champion
> wrote:
>
> [Trying again, with all patches unzipped and the CC list temporarily
> removed to avoid flooding people's inboxes. Original message follows.]
>
> On Fri, Feb 23, 2024 at 5:01 PM Jacob Champion
> wrote:
>> The
>> patchset is now carrying a
On Tue, Feb 27, 2024 at 11:20 AM Jacob Champion
wrote:
> This is done in v17, which is also now based on the two patches pulled
> out by Daniel in [1].
It looks like my patchset has been eaten by a malware scanner:
550 Message content failed content scanning
(Sanesecurity.Foxhole.Mail_gz.UNO
Hi all,
v14 rebases over latest and fixes a warning when assertions are
disabled. 0006 is temporary and hacks past a couple of issues I have
not yet root caused -- one of which makes me wonder if 0001 needs to
be considered alongside the recent pg_combinebackup and incremental
JSON work...?
--Jac
On Tue, Dec 5, 2023 at 1:44 AM Daniel Gustafsson wrote:
>
> > On 8 Nov 2023, at 20:00, Jacob Champion wrote:
>
> > Unfortunately the configure/Makefile build of libpq now seems to be
> > pulling in an `exit()` dependency in a way that Meson does not.
>
> I believe this comes from the libcurl and
> On 8 Nov 2023, at 20:00, Jacob Champion wrote:
> Unfortunately the configure/Makefile build of libpq now seems to be
> pulling in an `exit()` dependency in a way that Meson does not.
I believe this comes from the libcurl and specifically the ntlm_wb support
which is often enabled in system and
On Thu, Nov 9, 2023 at 5:43 PM Andrey Chudnovsky wrote:
> Do you plan to support adding an extension hook to validate the token?
>
> It would allow a more efficient integration, then spinning a separate process.
I think an API in the style of archive modules might probably be a
good way to go, ye
Hi Jacob,
Wanted to follow up on one of the topics discussed here in the past:
Do you plan to support adding an extension hook to validate the token?
It would allow a more efficient integration, then spinning a separate
process.
Thanks!
Andrey.
On Wed, Nov 8, 2023 at 11:00 AM Jacob Champion wr
On Fri, Nov 3, 2023 at 5:28 AM Shlok Kyal wrote:
> Just want to make sure you are aware of these failures.
Thanks for the nudge! Looks like I need to reconcile with the changes
to JsonLexContext in 1c99cde2. I should be able to get to that next
week; in the meantime I'll mark it Waiting on Author
Hi,
On Fri, 3 Nov 2023 at 17:14, Jacob Champion wrote:
>
> v12 implements a first draft of a client hook, so applications can
> replace either the device prompt or the entire OAuth flow. (Andrey and
> Mahendrakar: hopefully this is close to what you need.) It also cleans
> up some of the JSON tec
v11 is a quick rebase over the recent Cirrus changes, and I've dropped
0006 now that psycopg2 can build against BSD/Meson setups (thanks Daniele!).
--Jacob1: 0278c7ba90 = 1: 36409a76ce common/jsonapi: support FRONTEND clients
2: bb3ce4b6a9 = 2: 1356b729db libpq: add OAUTHBEARER SASL mechanism
On Tue, Jul 18, 2023 at 4:04 PM Thomas Munro wrote:
> On Tue, Jul 18, 2023 at 11:55 AM Jacob Champion
> wrote:
> +1 for EV_RECEIPT ("just tell me about errors, don't drain any
> events").
Sounds good.
> While comparing the cousin OSs' man pages just now, I noticed that
> it's not only macOS th
On Tue, Jul 18, 2023 at 11:55 AM Jacob Champion wrote:
> We're not setting EV_RECEIPT for these -- is that because none of the
> filters we're using are EV_CLEAR, and so it doesn't matter if we
> accidentally pull pending events off the queue during the kevent() call?
+1 for EV_RECEIPT ("just tel
> > - Parameters are strings, so callback is not provided yet.
> > 2. Client gets PgConn from PQconnectStart return value and updates
> > conn->async_auth to its own callback.
>
> This is where some sort of official authn callback registration (see
> above reply to Daniele) would probably come in
On Wed, Jul 12, 2023 at 5:50 AM Jacob Champion wrote:
> Oh, whoops, it's just the missed CLOEXEC flag in the final patch. (If
> the write side of the pipe gets copied around, it hangs open and the
> validator never sees the "end" of the token.) I'll switch the logic
> around to set the flag on the
On Mon, Jul 10, 2023 at 4:50 PM Jacob Champion wrote:
> I don't understand why the
> server-side tests are failing on FreeBSD, but they shouldn't be using
> the libpq code at all, so I think your kqueue implementation is in the
> clear.
Oh, whoops, it's just the missed CLOEXEC flag in the final p
On Fri, Jul 7, 2023 at 6:01 PM Thomas Munro wrote:
>
> On Fri, Jul 7, 2023 at 4:57 AM Jacob Champion wrote:
> > On Wed, Jul 5, 2023 at 3:07 PM Thomas Munro wrote:
> > > BTW I will happily do the epoll->kqueue port work if necessary.
> >
> > And I will happily take you up on that; thanks!
>
> Som
On Fri, Jul 7, 2023 at 2:16 PM Andrey Chudnovsky wrote:
> Please confirm my understanding of the flow is correct:
> 1. Client calls PQconnectStart.
> - The client doesn't know yet what is the issuer and the scope.
Right. (Strictly speaking it doesn't even know that OAuth will be used
for the co
On Fri, Jul 7, 2023 at 4:57 AM Jacob Champion wrote:
> On Wed, Jul 5, 2023 at 3:07 PM Thomas Munro wrote:
> > BTW I will happily do the epoll->kqueue port work if necessary.
>
> And I will happily take you up on that; thanks!
Some initial hacking, about 2 coffees' worth:
https://github.com/macdi
Thanks Jacob for making progress on this.
> 3) Is the current conn->async_auth() entry point sufficient for an
> application to implement the Microsoft flows discussed upthread?
Please confirm my understanding of the flow is correct:
1. Client calls PQconnectStart.
- The client doesn't know yet
On Thu, Jul 6, 2023 at 1:48 PM Thomas Munro wrote:
> On Fri, Jul 7, 2023 at 4:57 AM Jacob Champion wrote:
> > Something analogous to libcurl's socket and timeout callbacks [1],
> > then? Or is there an existing libpq API you were thinking about using?
>
> Yeah. Libpq already has an event concept
On Fri, Jul 7, 2023 at 4:57 AM Jacob Champion wrote:
> On Wed, Jul 5, 2023 at 3:07 PM Thomas Munro wrote:
> > 2. Convert those events into new libpq events like 'I want you to
> > call me back in 100ms', and 'call me back when socket #42 has data',
> > and let clients handle that by managing the
On Wed, Jul 5, 2023 at 3:07 PM Thomas Munro wrote:
> I guess there are a couple of ways to do it if we give up the goal of
> no-code-change-for-the-client:
>
> 1. Generalised PQsocket(), that so that a client can call something like:
>
> int PQpollset(const PGConn *conn, struct pollfd fds[], int
On Thu, Jul 6, 2023 at 9:00 AM Jacob Champion wrote:
> My goal is to maintain compatibility with existing PQconnectPoll()
> applications, where the only way we get to communicate with the client
> is through the PQsocket() for the connection. Ideally, you shouldn't
> have to completely rewrite you
On Fri, Jun 30, 2023 at 9:29 PM Thomas Munro wrote:
>
> On Sat, May 20, 2023 at 10:01 AM Jacob Champion
> wrote:
> > - The client implementation is currently epoll-/Linux-specific. I think
> > kqueue shouldn't be too much trouble for the BSDs, but it's even more
> > code to maintain.
>
> I guess
On Sat, May 20, 2023 at 10:01 AM Jacob Champion wrote:
> - The client implementation is currently epoll-/Linux-specific. I think
> kqueue shouldn't be too much trouble for the BSDs, but it's even more
> code to maintain.
I guess you also need a fallback that uses plain old POSIX poll()? I
see yo
On 5/19/23 15:01, Jacob Champion wrote:
> But I don't want to
> gold-plate it if this overall approach is unacceptable. So, questions
> for the gallery:
>
> 1) Would starting up a background thread (pooled or not) be acceptable
> on Windows? Alternatively, does anyone know enough Winsock deep ma
On Tue, May 23, 2023 at 4:22 AM Daniele Varrazzo
wrote:
> On Sat, 20 May 2023 at 00:01, Jacob Champion wrote:
> > - Some clients in the wild (psycopg2/psycopg) suppress all notifications
> > during PQconnectPoll().
>
> If there is anything we can improve in psycopg please reach out.
Will do, tha
On Sat, 20 May 2023 at 00:01, Jacob Champion wrote:
> - Some clients in the wild (psycopg2/psycopg) suppress all notifications
> during PQconnectPoll().
If there is anything we can improve in psycopg please reach out.
-- Daniele
On Fri, Sep 23, 2022 at 3:39 PM Jacob Champion wrote:
> Here's a newly rebased v5. (They're all zipped now, which I probably
> should have done a while back, sorry.)
To keep this current, v7 is rebased over latest, without the pluggable
authentication patches. This doesn't yet address the archite
Greetings,
* Andrey Chudnovsky (achudnovs...@gmail.com) wrote:
> > This really doesn't feel like a great area to try and do hooks or
> > similar in, not the least because that approach has been tried and tried
> > again (PAM, GSSAPI, SASL would all be examples..) and frankly none of
> > them has t
> This really doesn't feel like a great area to try and do hooks or
> similar in, not the least because that approach has been tried and tried
> again (PAM, GSSAPI, SASL would all be examples..) and frankly none of
> them has turned out great (which is why we can't just tell people "well,
> install
Greetings,
* Jacob Champion (jchamp...@timescale.com) wrote:
> On Mon, Feb 20, 2023 at 2:35 PM Stephen Frost wrote:
> > Having skimmed back through this thread again, I still feel that the
> > direction that was originally being taken (actually support something in
> > libpq and the backend, be i
Thanks for the feedback,
> Having skimmed back through this thread again, I still feel that the
> direction that was originally being taken (actually support something in
> libpq and the backend, be it with libiddawc or something else or even
> our own code, and not just throw hooks in various pla
On Mon, Feb 20, 2023 at 2:35 PM Stephen Frost wrote:
> Having skimmed back through this thread again, I still feel that the
> direction that was originally being taken (actually support something in
> libpq and the backend, be it with libiddawc or something else or even
> our own code, and not jus
Greetings,
* mahendrakar s (mahendrakarfo...@gmail.com) wrote:
> The "issuer" field has been removed to align with the RFC
> implementation - https://www.rfc-editor.org/rfc/rfc7628.
> This patch "v6" is a single patch to support the OAUTH BEARER token
> through psql connection string.
> Below fl
Hi All,
The "issuer" field has been removed to align with the RFC
implementation - https://www.rfc-editor.org/rfc/rfc7628.
This patch "v6" is a single patch to support the OAUTH BEARER token
through psql connection string.
Below flow is supported. Added the documentation in the commit messages.
> All of this points at a bigger question to the community: if we choose
> not to provide a flow implementation in libpq, is adding OAUTHBEARER
> worth the additional maintenance cost?
> My personal vote would be "no". I think the hook-only approach proposed
> here would ensure that only larger pr
On Sun, Jan 15, 2023 at 12:03 PM Andrey Chudnovsky
wrote:
> 2. Removed Device Code implementation in libpq. Several reasons:
>- Reduce scope and focus on the protocol first.
>- Device code implementation uses iddawc dependency. Taking this
> dependency is a controversial step which require
More information on the latest patch.
1. We aligned the implementation with the barebone SASL for OAUTH
described here - https://www.rfc-editor.org/rfc/rfc7628
The flow can be explained in the diagram below:
+--+ +--+
| +
Hi All,
Changes added to Jacob's patch(v2) as per the discussion in the thread.
The changes allow the customer to send the OAUTH BEARER token through psql
connection string.
Example:
psql -U u...@example.com -d 'dbname=postgres oauth_bearer_token=abc'
To configure OAUTH, the pg_hba.conf line l
On Mon, Dec 12, 2022 at 9:06 PM Andrey Chudnovsky
wrote:
> If your concern is extension not honoring the DBA configured values:
> Would a server-side logic to prefer HBA value over extension-provided
> resolve this concern?
Yeah. It also seals the role of the extension here as "optional".
> We a
> The server hook is the right place to check the scopes, yes, but I think
> the DBA should be able to specify what those scopes are to begin with.
> The provider of the extension shouldn't be expected by the architecture
> to hardcode those decisions, even if Azure AD chooses to short-circuit
> th
On Wed, Dec 7, 2022 at 3:22 PM Andrey Chudnovsky
wrote:
>
>> I think it's okay to have the extension and HBA collaborate to
>> provide discovery information. Your proposal goes further than
>> that, though, and makes the server aware of the chosen client flow.
>> That appears to be an architectur
That being said, the Diagram 2 would look like this with our proposal:
+--+ +--+
| +---+ | Postgres |
| PQconnect ->| | |
> I think it's okay to have the extension and HBA collaborate to provide
> discovery information. Your proposal goes further than that, though,
> and makes the server aware of the chosen client flow. That appears to
> be an architectural violation: why does an OAuth resource server need
> to know t
On Mon, Dec 5, 2022 at 4:15 PM Andrey Chudnovsky wrote:
> I think we can focus on the roles and responsibilities of the components
> first.
> Details of the patch can be elaborated. Like "flow type code" is a
> mistake on our side, and we will use the term "grant_type" which is
> defined by OIDC
Jacob,
Thanks for your feedback.
I think we can focus on the roles and responsibilities of the components first.
Details of the patch can be elaborated. Like "flow type code" is a
mistake on our side, and we will use the term "grant_type" which is
defined by OIDC spec. As well as details of usage o
On 11/24/22 00:20, mahendrakar s wrote:
> I had validated Github by skipping the discovery mechanism and letting
> the provider extension pass on the endpoints. This is just for
> validation purposes.
> If it needs to be supported, then need a way to send the discovery
> document from extension.
Y
On 11/23/22 19:45, Andrey Chudnovsky wrote:
> Mostly terminology questions here. OAUTHBEARER SASL appears to be the
> spec about using OAUTH2 tokens for Authentication.
> While any OAUTH2 can generally work, we propose to specifically
> highlight that only OIDC providers can be supported, as we nee
Hi Jacob,
I had validated Github by skipping the discovery mechanism and letting
the provider extension pass on the endpoints. This is just for
validation purposes.
If it needs to be supported, then need a way to send the discovery
document from extension.
Thanks,
Mahendrakar.
On Thu, 24 Nov 20
> How does this differ from the previous proposal? The OAUTHBEARER SASL
> mechanism already relies on OIDC for discovery. (I think that decision
> is confusing from an architectural and naming standpoint, but I don't
> think they really had an alternative...)
Mostly terminology questions here. OAUT
1 - 100 of 128 matches
Mail list logo
