On Sun, Nov 3, 2024 at 9:00 PM jian he <jian.universality@gmail.com> 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
out safely.")
> we can also use PG_INT32_MAX, instead of INT_MAX
> (generally i think PG_INT32_MAX looks more intuitive to me)
That's a fixed-width max; we want the maximum for the `int` type here.
> expires_in
> REQUIRED. The lifetime in seconds of the "device_code" and
> "user_code".
> interval
> OPTIONAL. The minimum amount of time in seconds that the client
> SHOULD wait between polling requests to the token endpoint. If no
> value is provided, clients MUST use 5 as the default.
> "
> these two fields seem to differ from struct device_authz.
Yeah, Daniel and I had talked about being stricter about REQUIRED
fields that are not currently used. There's a comment making note of
this in parse_device_authz(). The v1 code will need to make expires_in
REQUIRED, so that future developers can develop features that depend
on it without worrying about breaking
currently-working-but-noncompliant deployments. (And if there are any
noncompliant deployments out there now, we need to know about them so
we can have that explicit discussion.)
Thanks,
--Jacob
