anytime

I should note that the proposal is active development: ReachableResources is merged and LookupSubjects is in review

once that is merged, then the next step will be the first implementation of the LookupWatch API

I might then just fetch all resource IDs and store them in a Redis cache with Write-Through strategy until then

Definitely looking forward to this along with pagination support in LookupResources

Hello, I'm trying to set a permission that refers to the subject itself, and one way I found is to do this:

definition user {
  relation self: user

  permission edit = self
}

with this approach I would have to create a

self

relationships for every user. Is there any way to refer to "self" without explicitly having this relation?

currently, no. there is, however, a proposal: https://github.com/authzed/spicedb/issues/338

thanks

To upload a schema through REST API, we need to manually add /n what's best way to handle this?

can you clarify that a bit?

I am using REST API to interact with SpiceDB Services, To upload a schema using write-schema API we provide the SchemText value as String inside API Request Body, something as below{ "schemaText": "definition secure_group {}\n\ndefinition resource {\n\trelation creator: secure_group\n\trelation viewer: secure_group\n\tpermission create = creator\n\tpermission view = viewer + creator\n}" }

look at all those \n and \t need to add these manually. I was wondering if there is any better way to achieve the same.

how are you invoking the API call?

JSON libraries should do it for you

I am using POSTMAN, playing around it. I shall be using Java client later.

Is there any simple way to create Java POJO from SchemaText value.

If you're manually specifying the schema in postman requests you'll have to concat the lines as you mentioned unfortunately. There's a collection for the v1 API if you wanted to easily try out other requests https://www.postman.com/authzed/workspace/c1b9ce6b-7482-4363-8a09-71521355b6d9/overview

POJOs for the definitions from your schema? What's the interaction with the schema you're looking for?

Thanks Sam, If I have to perform certain validation on a specific portion of schema, like only specific type of permissions allowed for any specific resource type. What approach would you suggest ?

Ah I see, generally that's done using actual permissions checks. That'd be assertions if you're using the playground and the integration testing mode if you're running test code. This way, you can be sure to exercise the actual check logic which is especially important as you have more computed permissions

SpiceDB's

LookupResources

is an excellent API to find the data a user has access to if it's a relatively small subset of the overall number of documents. What about an alternative world where most users have access to most data? Presumably I don't want to get into a scenario where

LookupResources

returns 10 million IDs and I include all that in my DB lookup -- how should we handle those situations?

Can you instead look up the resources they don’t have access to and filter them out?

The

LookupResources

API seems to only accept inclusivity: https://buf.build/authzed/api/docs/main:authzed.api.v1#authzed.api.v1.PermissionsService.LookupResources. Do you mean that we'd change the underlying idea behind the schema so that relationships indicate a lack of access instead?

Only if that made sense for your schema

Like if users lost access by being banned or something

Hmm potentially. I'm not entirely sure yet how it will go to market, i.e. whether we will give broad access to data or restricted (which clearly impacts the decision here). Is there an alternative to changing the schema or is that the best option in the "broad access" scenario?

The other would be to load a set of candidates from your db, and then send each one off to check in parallel

As in, fetch the data from the DB without any filter and then do the lookup afterwards inside Zanzibar using

CheckPermission

?

Yep

Got it, thanks. That comes with some disadvantages (complicated pagination & multiple network requests) but there's not much to do about that