Re: [PoC] Federated Authn/z with OAUTHBEARER

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, Antonin Houska <ah(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
Date: 2024-11-27 17:27:13
Message-ID: 9B417838-B872-453D-BBFB-99FA957EB723@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks for the updated version, it's really starting to take good shape. A few
small comments on v37 from a a first quick skim-through:

+ if (!strcmp(key, AUTH_KEY))
+ if (*expected_bearer && !strcmp(token, expected_bearer))
Nitpickery but these should be (strcmp(xxx) == 0) to match project style.
(ironically, the only !strcmp in the code was my mistake in ebc8b7d4416).

+ foreach(l, elemlist)
This one seems like a good candidate for a foreach_ptr construction.

+ *output = strdup(kvsep);
There is no check to ensure strdup worked AFAICT, and even though it's quite
unlikely to fail we definitely don't want to continue if it did.

fail_validator.c seems to have the #include list copied from validator.c and
pulls in unnecessarily many headers.

+ client's dummy reponse, and issues a FATAL error to end the exchange.
s/reponse/response/

In validate() I wonder if we should doublecheck that have a a proper set of
validator callbacks loaded just to make even more sure that we don't introduce
anything terrible in this codepath.

I will keep reviewing this version to try and provide more feedback.

--
Daniel Gustafsson

Attachment Content-Type Size
v37comments.diff.txt text/plain 4.1 KB
unknown_filename text/plain 1 byte

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-11-27 17:59:38 Re: ECPG cleanup and fix for clang compile-time problem
Previous Message Andrew Dunstan 2024-11-27 17:15:42 Re: pg_parse_json() should not leak token copies on failure