From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>, mahendrakar s <mahendrakarforpg(at)gmail(dot)com>, Andrey Chudnovsky <achudnovskij(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, "hlinnaka(at)iki(dot)fi" <hlinnaka(at)iki(dot)fi>, "michael(at)paquier(dot)xyz" <michael(at)paquier(dot)xyz>, "smilingsamay(at)gmail(dot)com" <smilingsamay(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Eisentraut <peter(at)eisentraut(dot)org> |
Subject: | Re: [PoC] Federated Authn/z with OAUTHBEARER |
Date: | 2024-07-29 20:51:20 |
Message-ID: | 9CB61297-FC3A-4640-BE11-EABF63829634@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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_STRING, {&authz->verification_uri}, REQUIRED},
/*
* The following fields are technically REQUIRED, but we don't use
* them anywhere yet:
*
* - expires_in
*/
{"interval", JSON_TOKEN_NUMBER, {&authz->interval_str}, OPTIONAL},
Together with a colleage we found the Azure provider use "verification_url"
rather than xxx_uri. Another discrepancy is that it uses a string for the
interval (ie: "interval":"5"). One can of course argue that Azure is wrong and
should feel bad, but I fear that virtually all (major) providers will have
differences like this, so we will have to deal with it in an extensible fashion
(compile time, not runtime configurable).
I was toying with making the name json_field name member an array, to allow
variations. That won't help with the fieldtype differences though, so another
train of thought was to have some form of REQUIRED_XOR where fields can tied
together. What do you think about something along these lines?
Another thing, shouldn't we really parse and interpret *all* REQUIRED fields
even if we don't use them to ensure that the JSON is wellformed? If the JSON
we get is malformed in any way it seems like the safe/conservative option to
error out.
--
Daniel Gustafsson
From | Date | Subject | |
---|---|---|---|
Next Message | Euler Taveira | 2024-07-29 21:11:32 | Re: speed up a logical replica setup |
Previous Message | Joel Jacobson | 2024-07-29 20:40:16 | Is *fast* 32-bit support still important? |