Zedtoken on resource after group membership change
# spicedb
h
Hi. I am using RBAC. My schema has a resource, that has a relationship to user | group#members. When I assign a group to my resource and remember the zed token, and afterwards assign a user to the group, the zed token remembered at the resource is earlier then the zed token of the group. What’s best practice for hierarchies like that? Should I update the zed token after the group membership change on all resources that have a relationship to that group?
a
I recall a discussion about this recently. You could do that, but if there are many resources it may be impractical (or introduce its own race conditions). I think the idea of zedtokens is they can easily prevent false positives after the content of a resource changes, because that's the new enemy problem. Delays on access updates to contents someone was already able to see, or couldn't have seen before, are less sensitive. I could be wrong but that's my understanding 🙂
j
that's correct @Alec
h
Don’t we have the new enemy problem if someone was removed from a group but the zed token of the resource is before that?
I am not sure how to defend against new enemy without updating zed tokens on all resources the group was referenced.
j
no
new enemy is about the content of the document/resource
if you remove someone from the group that has access to the document, but the contents of the document don't change, no new enemy
and if the contents do change, you should be updating the zedtoken for the document at that point
which would mean the group change is reflected at that point
realistically, unless you have a concern about that specific issue, its not necessary to worry about it
h
Ok, understood. When the content of the document changes, how can I get the current zed token which reflects the group change?
As far as I know I only get one after writing relations to spicedb. Would I have to load the groups zed tokens and take the latest?
j
check rerturns it too
and you're checking if a user can write
so just store that
h
So I only want to update the zed token of the resource when the resource changes. And not if any of its relationships changes. Thanks for helping me understand that.
j
yep
and only if you really care about new enemy
if you don't care if someone might have access to new content for ~15s after a relationship changes, then nothing to worry about
h
I suppose the same applies to resource hierarchies, correct? I have a child resource that has a permission that references a parent permission. Now the parent relationships change. If I then access the child resource directly, it might have an earlier zed token. But since the child resource itself didn’t change, its ok if the check does not take the changed parent relationships into account.
j
yes
h
What if the group membership or parent permission manages more than simple read access permissions? How should I deal with write or delete requests to my resource?
j
full consistency
you always want to use full consistency on a modification operation IF you want to ensure the most safety
this once again assumes a small window is not allowed