The permission is defined on the token. The resource and token have no relationship, but the view logic of the resource depends on the token

hi, does someone has tried auth proxy with spicedb and kubernetes ?

Anyone have an example project illustrating common perm checks? E.g. check if user has permission, list all users with a certain permission etc?

I have two resources, workspaces & projects, and I'm wondering how on earth I can list all users who have access for a given project id, so just trying to find an example

Here's what I'm working with so far;

definition user {}

definition workspace {
  relation owner: user
  relation editor: user
  relation reader: user

  permission read: owner + editor + reader
  permission write: owner
}
 
definition project {
  relation workspace: workspace // Removed the namespace
  relation reader: user
  relation writer: user

  permission read: reader + writer + workspace->editor + workspace->owner
  permission write: writer + workspace->editor + workspace->owner
  permission invite_viewer: workspace->owner + workspace->editor
}

What's the "spicedb" way of listing who has access for a given project id, as well as what access they have?

I've tried doing a read relationships request (multiple, one for read perms and one for write perms) where I specify the resource as the project and give it the project id bit it doesn't seem to be picking up the workspace->project hierarchy?

Hi Andy, you're looking for the

LookupSubjects

API which is currently in proposal

in the meantime, you can call

ExpandPermissionTree

and recursively re-expand where necessary to get all the way to your user type

Cheers Jake I'll take a look later on when I'm back working. Do you have any minimalist examples?

I'm picking this up whilst a coworker is off for a few weeks and pretty much learning this from scratch so any extra help is appreciated :)

Which auth proxy? Like just the concept?

No, I don't have an example already, but you should be able to just call ExpandPermissionTree, iterate the results, and if you get back an intermediate object run expand again.

👍 gotcha, will try that. This will ultimately give me a list of users & their permissions for that specific project?

And presumably by intermediate object you mean a parent object reference which in this case would be the workspace?

Is nested permission checks not allowed in just the playground or also in spicedb itself?

not supported in either

the recommendation is to add a

permission

in the downstream definition(s)

like

yeah I figured I'd have to do it

I can just add something in token which delegates to

application->view_all

I believe

correct

token->app_view_all

and then do

permission app_view_all = application->view_all

in the token

Nice, yeah just did exactly that, just wasn't sure if it was a playground limitation

the limitation is a relic of our older API; since that was just fully removed a week or so ago, I expect we'll add the nested arrows

sweet 👍

Yes, in front of spice DB, i.e kubernetes proxy

Another probably dumb question, but if I'm returning a list of users after doing an ExpandPermissionTree for a permission on a resource, this feels like kind of a bad fit for where we also need to be displaying extra information on the frontend such as name / email / etc. Realistically I'd have to do another db call to where we store that info to grab all that and return it, but feels... bad?

it should be fine unless you're selecting thousands of rows, which you should probably not do solely from a UX perspective