https://authzed.com logo
Join Discord
Powered by
set `relation owner_with_balance:
# spicedb
j
set 
relation owner_with_balance: account#owner
and only write a single relationship
h
Yes, but you have to write two if you want to check access and withdraw permission for the same user
and at the same access permission does not require any additional context
j
no
you link the account to itself
once
and then it flows through to the user
h
oh I see
j
any "object level attribute" can be represented by a caveated relation from the object to another relation/permission on itself
because that's really what it is
h
Let me try this in my example
I think I found a bug, let me describe it here and you can tell me if this is a bug or not and where to post an issue
but once I run a zed perm check
It's automatically deleted with err msg:
Copy code
// Relationship must be of the form `resourcetype:resourceid#relation@subjecttype:subjectid[caveatName]`: account:a1#owner_with_balance@account:a1#owner[check_balance:{}]
https://cdn.discordapp.com/attachments/1253449804034478211/1253461586874466384/image.png?ex=6675f092&is=66749f12&hm=81bd7f168b644b2a0d7235d85dd8731b9c2b429419fb5b0f9ee2890f4e55b24b&
Maybe I'm doing sth wrong here
and got true in response
and got false
j
yes, there is a formatting bug with calling zed in the playground
use the check watch panel
h
I'm thinking about what you wrote: > any "object level attribute" can be represented by a caveated relation from the object to another relation/permission on itself And I have a question about this appraoch - with this approach it is not possible to store a partial context per owner right, sth like keep the balance in the spicedb, and only pass amount while calling a permision check https://cdn.discordapp.com/attachments/1253449804034478211/1253463770659950742/image.png?ex=6675f29b&is=6674a11b&hm=28e7291d2135c4fc60df525d66041b832260dd7f74ee4b8b336b5ba5a1607bbb&
If I want to store partial context in spicedb and the rest should be supplied from the caller I need to create relation per caveat right?
j
if it is per owner, then it needs to be on the owner -> user
because the context applies to that relationship
but you shouldn't keep the balance in SpiceDB
you should keep the comparison there, if anything
h
> but you shouldn't keep the balance in SpiceDB Ok, I've been thiking about this approach. My usecase for that is - I have a system with ReBAC and ABAC. For ABAC I have two types of fields - one are set at the creation of relation and almost never change, the other are more dynamic in their nature. I have 10-20 of those, half of them are more static and half are dynamic. I was thinking about storing the const field in spicedb to avoid supplying all fileds by a caller every time. But from what you're telling me this is not the approach spicedb recommends. Do you have any plans to extend the schema for usecase like the one I described? I mean I know this is already possible, but with the large amount of fields (+ matrix between them) the schema quickly becomes unmaintanable imo
j
if it is truly const, store it
but if it dynamic, do not
dynamic should be passed as context
h
https://play.authzed.com/s/orBOW3ldRfAV/schema- Based on our discussion, I've created a list with a few approaches that I took. I write pros and cons for each of them and also add a solution with "a new syntax." - going back to my question, is something like solution 4/5 on your roadmap? Does someone need such a usecase? Where is the best place to add an issue like this?
In this thread (https://discord.com/channels/844600078504951838/1170026158495113246/1170054955814621274) you wrote: > Permify copied our caveats implementation but did so solely as "attributes", which makes it strictly less powerful than caveats in terms of being able to conditionally link together objects based on various attributes Do you have a spice schema example that shows how caveats are more powerful than attributes and what can't be achieved in permify?
j
what I showed above
an object-level attribute is merely a caveat on a relation from the object to itself
data that doesn't change should be represented structurally, not via caveats
and you can have a caveat that is the combination of others
h
I see, thanks for the explanation, that was really helpful!
3 Views
PreviousNext
Powered by