-
Notifications
You must be signed in to change notification settings - Fork 1.3k
ZedTokens: SpiceDBAuthorizer cleanup #18898
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
dcd42e3 to
ea0acbf
Compare
| await this.tokenCache.set( | ||
| ...updates.map<ZedTokenCacheKV>((u) => [ | ||
| u.relationship?.resource, | ||
| writtenAt, // Make sure that in case we don't get a writtenAt token here, we at least invalidate the cache |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would always expect a token on successful writes. Did you see cases where no writtenAt was returned?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The API gives no guarantee, so I decided to not assume things. 🤷
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I doubt it happens, but let's at least log a warning in those cases
| // following https://github.com/authzed/spicedb/blob/786555c24af98abfe3f832c94dbae5ca518dcf50/pkg/zedtoken/zedtoken.go#L64-L100 | ||
| const decodedBytes = base64decode(token); | ||
| const decodedToken = DecodedZedToken.decode(Buffer.from(decodedBytes, "utf8")).v1; | ||
| if (!decodedToken) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is that not an error case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is a technical error. But it would not break in a user-facing way - except we got a bunch of these, which we need to detect via metrics+alerts.
I think we need to decide (and document) how we see log levels being used, because I heart people (over time) argue for very different perspectives. 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably similar case to the above. I think we should at least log an error
| } | ||
|
|
||
| type ZedTokenCacheKV = [objectRef: v1.ObjectReference | undefined, token: string | undefined]; | ||
| interface ZedTokenCache { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think there's a need for an interface
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not touch the code here yet. Let's do the rollout first.
| export class RequestLocalZedTokenCache implements ZedTokenCache { | ||
| constructor() {} | ||
|
|
||
| async get(objectRef: v1.ObjectReference | undefined): Promise<string | undefined> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
none of these methods need to be async
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also let's remove the unused arguments. We can introduce them when we need them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather go with the current version and get data. 🙂 Removal is very quick.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought the reason for this PR is clean up?
| return getContext().zedToken?.token; | ||
| } | ||
|
|
||
| async set(...kvs: ZedTokenCacheKV[]) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wouldn't it be enough to just pass in a single token and only set it if it is greater than the existing one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We get a bunch of tokens in some cases. As mentioned above, happy to remove all of this once we decided the current implementation is sufficient.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
only because you want to update them per resource which we currently don't do/need
| } | ||
| } | ||
|
|
||
| async consistency(resourceRef: v1.ObjectReference | undefined): Promise<v1.Consistency> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I would pass in the zedtoken and move this method to the authorizer. it seems unrelated to the caching aspect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For this cache implementation: Yes. For others definitely not. Again, happy to remove/fold in if we don't need that stuff. 🤞
svenefftinge
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
(minus the comments regarding the token cache, which we can tackle in a follow up)
|
/unhold |
Description
Follow-up for: #18893
This PR:
readPermissionscalls as well (turns out we are calling them more often then expected)Summary generated by Copilot
🤖 Generated by Copilot at dcd42e3
Refactor the server component to use SpiceDB for authorization and simplify the log context module. Add TypeScript bindings and code generation for SpiceDB protobuf files.
Related Issue(s)
Fixes #
How to test
Documentation
Preview status
Gitpod was successfully deployed to your preview environment.
Build Options
Build
Run the build with werft instead of GHA
Run Leeway with
--dont-testPublish
Installer
Add desired feature flags to the end of the line above, space separated
Preview Environment / Integration Tests
If enabled this will build
install/previewIf enabled this will create the environment on GCE infra
Valid options are
all,workspace,webapp,ide,jetbrains,vscode,ssh. If enabled,with-previewandwith-large-vmwill be enabled./hold