Hmm... they stumbled on the same issue why most programmers wont use macaroons:
There was no specification on the caveats other than the only before
and only after kinds.
("time < 2024-02-04T04:20" and "time > 2024-02-02T13:35" as respective examples)
They call them untypeable utf-8 blobs and link to an podcast that
talks about these kind of tokens where there is a rather hand-wavy
admonisment why that is bad. (Then the podcast goes off into weeds of
trying to shoehorn in userId crap into macaroons. Sure you can use
third party caveats to enforce it but why would you? One kind of first
party caveat, I coded up, that is always true is a comment/blame
caveat that just gets logged with the request. That is that caveats
whole function.)
So the
fly.io folks went off and made their own format that wasnt
written up in the original paper.
But I am definitly going to look at their caveat system and see if
they got something I want to copy.
(btw I am hacking together a macaroon caveats enforcing functions for
use with val.town.
Got four kinds of caveats so far. The aforementioned only before and
after ones, the comment one, and one that is paramExp which specifies
a boolean conditional expression. Basically anything you can put into
the conditional of an if statement in js minus function calls and
blatant side effects. Ping me if you want to know more.)
On Fri, 2 Feb 2024 at 00:47, Alan Karp <
alan...@gmail.com> wrote:
>
>
https://fly.io/blog/macaroons-escalated-quickly/
>
> --------------
> Alan Karp
>
> --