Hey @DharsanB - why can’t you use a UUID? SpiceDB needs some unique ID for the resource you’d like to check access too - in your case resource. To ensure uniqueness and security, a UUID is recommended as best practice.

We've UUID for individual objects but since we're evaluating against the request path and if the user has access, sometimes path elements might repeat. We're using the ext-authz https://www.getambassador.io/docs/edge-stack/latest/topics/running/services/ext-authz

Hey @DharsanB - I'm sorry for missing your message

So, in the current Authorization system, we’ll compare if the user has access to /orgs/{orgId}/app/{appId}

Thanks! And is there any reason you can’t take the id from your request path in your application to make a check request call to SpiceDB? Eg you can first make sure that the caller has access to orgid and then that they have access to appid (you can make these calls synchronously since SpiceDB is a GRPC api)

Some people are given access to app directly instead of org and the app name is unique in an org but not across orgs

Cool - you can handle all of this in your SpiceDB Schema Design

Currently it is not But we're going to make it because if the old one gets deleted and new app is created with the same name, sometimes the older values are populated before GC kicks in.

You can always combine UUIDs to get a unique value in SpiceDB - eg orguuid:appuuid

sorry to miss this y'all. I'm not sure I'm having all the context. It appears that we want to perform a

Check

request over a

resource

whose identifier is obtained from the end-user web request path. I'm not sure to see where the problem is. It's mentioned users may have access to either org or app, and that seems like something that could (and probably should) be modelled explicitly in the schema. Could you guys help me understand the problem? 🙏🏻

Thanks @vroldanbet - @DharsanB let us know if there is anything we can clarify

Sure Will try it out and let you know Thanks @dsieczko @vroldanbet

Sure thing!