Has there been any update regarding the performance issues on 1.14.1 I encountered in this thread? In particular the CPU consumption issue https://discord.com/channels/844600078504951838/844600078948630559/1046395550972526632 I'd need to upgrade as there's 2 bugs in 1.13.0 that have been fixed in this version, but I can't without this being tackled

are these permission pre defined i e

the current best practice is to either pre-filter or post-filter: in a pre-filter scenario, you'd run LookupResources to receive the list of objects the user has access to, pass those IDs to your search index for filtering, and return results. in the post-filter scenario, you'd run your filter on the search index, and then issue checks for the results against the user before displaying. which you use depends on how many results you expect to get from each side. longer term, the work we're doing for Tiger cache should address this problem more directly. see https://github.com/authzed/spicedb/issues/280 and https://github.com/authzed/spicedb/issues/207

Thanks Joey. Ye the problem we have is either side can potentially be very high. Like millions. Think iot uc. I’ll have a look at tiger cache

what are you using for your search index side?

The search is done in elastic search

gotcha. yeah, the idea behind Tiger cache is that it would produce roaring bitmaps that could in theory be given to ES as prefilter

Ah sounds interesting, that would probably work nicely

Ah sounds interesting that would

how to list the permissions of an authzed user

as in what permissions they have, or...?

My program is in golang and I added authzed to it, but I need to list the permissions that the users have.

on a particular resource?

like: "all the permissions user FOO has on document BAR"?

oh I understand, I'm just starting with authzed and it's still hard for me, I need it to give me all the resources assigned to a user

you'll want `LookupResources`: https://buf.build/authzed/api/docs/main:authzed.api.v1#authzed.api.v1.PermissionsService.LookupResources

you give it a user and a permission, and it returns all resources that user has that permission to access

yes that i need

Is there a canonical example for caveats including a schema, tuples and assertions? I’ve looked everywhere I can think of. I’ll push the data in with the api so I just need examples

Playground and validation tooling don't yet support caveats; I'm literally writing the PR for it now

if you want an example schema and relationships, I can give you that though

@hcguy any particular example you'd like? or I can just make one

One that works 😀 I just want to prove the concept, learn the ropes and then I can adapt to my case. It will save us a ton of time getting started. Thanks.

sure; here's one that grants a role only on tuesdays:

caveat only_on_tuesday(day_of_week string) {
  day_of_week == 'tuesday'
}

definition user {}

definition resource {
  relation viewer: user with only_on_tuesday
  permission view = viewer
}

you'd write a relationship of the form

resource:someresource#viewer@user:someuser[only_on_tuesday]

and then pass in the current

day_of_week

in the

CheckPermission

request

another example might be to restrict access if the user is not within a specific IP range (or is):

caveat ip_allowlist(user_ip ipaddress, cidr string) {
  user_ip.in_cidr(cidr)
}

definition user {}

definition resource {
  relation viewer: user with ip_allowlist
  permission view = viewer
}

in this case, you could write the

cidr

alongside the relationship:

resource:someresource#viewer@user:someuser[ip_allowlist:{"cidr": "1.2.3.0"}]

and then pass the user's current

user_ip

in the

CheckPermission

request

Thanks 🙏

@Joey @Jake I just want to remind you guys of my question I asked a couple of weeks ago. I have not yet solve that problems. I would be grateful for any help.

so if I understand correctly: you only want a token to have permission if it is attached to a user with permission?

The idea is that a token is always attached to a user, the user has its own permissions it has been granted. And a key feature which haven't implemented yet, a token cannot be granted permissions which are higher than a user permissions.