https://authzed.com logo
Join Discord
Powered by
I can’t get this syntax to work?
# spicedb
s
I can’t get this syntax to work?
k
Combining the two caveats into a single one would work here, afaik multiple caveats for a single relation is currently unsupported, you can open an issue for this
y
correct, relations can only have a single caveat
s
I see. Thank you.
y
you can have multiple variations of a relation with different caveats, though
not sure if that fits your use case
Copy code
definition resource {
  relation viewer: user | user with expiration | user with ip_blocklist
}
if that makes sense
s
thanks @yetitwo appreciate the help. one thing I struggle with caveats is passing along the set value to permissions
y
as in what the call looks like?
s
here's one of my definitions
Copy code
definition solution {
    // Environment Relationship
    relation environment: environment

    // Access Relations
    relation owner: organization
    relation launcher: user | usergroup#member

    // Admin Console Permissions
    permission view = owner->view_solutions
    permission manage = owner->manage_solutions
    permission submit_content = owner->submit_solution_content
    permission approve_review = owner->approve_solution_review
    permission approve_test = owner->approve_solution_test
    permission delete = owner->delete_solutions

    // Deploy Permissions
    // Users must be both a launcher and environment member to launch the solution
    permission launch = launcher & environment->member
}
and i want the permission to 
submit_content
to be conditional based on whether or not the solution is what i'm calling an 
internal
solution, meaning the organization has deemed it to be internal, so i want to allow other users to of the organization to submit_content ... so i tried adding an internal caveat
Copy code
caveat internal(internal bool){
  internal == true
}
but i couldn't figure out how to pass along this boolean to conditionally add a different user as part of the content review
ie
Copy code
definition solution {
  relation owner: organization | organization with internal
  permission submit_content = organization>submit_solution_content + (if internal then include organization>manage_solutions) <<<<<
}
Copy code
solution:my_internal_solution#owner@organization:my_org[internal]
solution:my_solution#owner@organization:my_org
but maybe i shouldn't be trying to use caveats here 😢
y
my rule of thumb is that if something can be expressed with a relation, it should
so if there isn't something that would vary at request time that figures into the permission computation
i wouldn't use a caveat there
and you can use reflexive or wildcard relations to represent "boolean" ideas
the use of arrows is kinda subtle but this sounds like the behavior you're after
s
oh cool, you're referencing resource again ... okay! super helpful
before you sent this example ... we kind of did this, which I'm trying to think if works to 🤔 or if I need to modify mine to work more similar to how your example self references itself
Copy code
definition solution {
    relation owner: organization
    relation internal_to: organization
    
    permission submit_content = internal_to->manage_solutions + owner->submit_solution_content
}
y
that seems like it works fine as well
in that case you're treating two relations between the same two resources as having different semantics, which is a fine and normal thing
s
However your example is able to filter out users who aren’t internal, whereas mine seems to still allow external users to access my internal solution … ugh
Am I able to save a schema instance and share it with you, I don’t see like a save button on the playground? I’m only like 3 days into learning and using spiceDB, so I’m still learning the ropes. But I’d love to show you the assertion that I believe is a gap in my implementation compared to yours
y
you click the "Share" button and it saves a copy and gives you a sharing uRL
s
@yetitwo okay here's my example https://play.authzed.com/s/QDACWubU67aM/schema the access i'm trying to prevent is that even if a solution is "deploy_to" 2 different organizations it should only give my launch permissions to users who are part of the "internal_to" organization ... this should prevent access to outside orgs i should venmo you a coffee if you help me figure this out
y
is it not enough to add 
& internal_to->member
to the 
launch
permission? am i missing something?
s
No you’re right! I got it. Thanks to your help. Appreciate it
y
sure thing!
4 Views
PreviousNext
Powered by