Good idea; file an issue and we’ll get it added

We’ve been investigating an alternative that uses bloom filters to remove the restriction but it’s just a thought right now. I plan to update the proposal after some experimentation

ah neat; cuckoo filters might also be worth trying?

thanks for the insight 🙂

Yeah, it all depends on what the consumer might support

If you experiment yourself, we’d be happy to know the results 🙂

Hello 👋 Quick question: I have most of my authz checks done in the backend but some should be done when loading the frontend UI to gray out / hide some controls for users that doesn't have some permissions. What is the proper pattern there? Should I build some "proxy" APIs in my backend to be called by the frontend and then forward the permissions checks to SpiceDB from there? Is there some people that open SpiceDB publicly?

👋🏻 Hey there, I'll admit I'm not well versed in frontend land so I'm not best suited to answer this question. We do offer a Javascript client https://github.com/authzed/authzed-node but I'm not sure if folks have used it with a public SpiceDB. I hope @Sam or @Joey are able to provide more insight 🙏🏻

I'm already using the authzed-node SDK as my backend is in Typescript, but now that I'm thinking about it, SpiceDB authentication is "API Token" based and I don't want to leak the API Token to my frontend. So I guess that a direct integration with SpiceDB is not possible. But I'm wondering how other people are doing it 🙂 My frontend is React based and all rendering is done client side with APIs calls to load the state.

I guess that I could use some SpiceDB calls/checks when building my User Context in the backend and pass it to the frontend when fetching it.

Right, and I assume you've authenticated the user, so any calls to your backend API would have something like cookies to identify the user. In that scenario, wouldn't authorization requests be done as part of your backends business logic?

Yes, it would! But now that I'm thinking more about it, as the checks are ressource based (some ressources can be read but not edited by some users), I can't really put those results in the "UserContext" objects -> it would mean passing the list of IDs of all ressource that can be edited there and it doesn't really belongs in a UserContext.

So maybe a virtual field on the ressource APIs, like "canBeEdited" that would be dynamic based on the current User doing the call

are all resources visible to all users in your business domain, and what you want to make sure is the frontend renders the the corresponding controls/UI components in case the user has specific permissions?

No, ressources are visible only to users that have a "read" access over them. A subset of user that have the "read" permission can also have an "edit" permission and will see more controls on the UI for those resources

I'm trying to distinguish, for a given user, which ressources can only be read by him and which one can also be edited

Is https://play.authzed.com/ an online only feature or is there a way to run it locally. I am building my own schema now and my internet connection on the train is spotty. I am using

zed validate

, but the web version is a bit nicer 🙂

the API is returning the full set of ressources that can be "read", so I'm wondering how to identify the subset of resources that can be "edited"

there is no way currently to run the playground locally, but technically the playground is mostly client-side (specially after we introduced the WASM compiled spicedb), so I wonder if we could do something to turn it into a PWA so you can use it offline. That'd be a question for @Joey.

I see. Right now there are various options, one is to issue a

LookupResources

with

edit

permission, it will tell you the resources a user can edit. Another option is to do

LookupResources

with

view

and then issue multiple

Check

calls for each one of those resources with

view

permission.

lets say you have a case-object and all parts of the code adds readers to it, Then at some point the case is closed and no one is supposed to read it any longer. Is there a smarter way than to get all reader from spiceDb and remove them. such as only allowing reader to read on cases that was also not related to a singleton "archived" object or similar?

Hi guys I'm experimenting the REST API exposed by Spicedb when it is started with the "--http-enabled" flag When calling the "/v1/permissions/subjects" to lookup all subjects that have permission on a resource, I'm receiving a JSON response that is not a valid JSON, is it by design? I pasted an image showing that

Are tuple writes/deletes idempotent? I would like to be able pass a list of tuples to write/delete and ignore whatever conflict errors are thrown, so in the end I'm sure all tuples I passed are written/deleted

LookupSubjects is streaming, so it will return a list of JSON objects

yes, but if you want to ignore them, use TOUCH and DELETE; CREATE will throw an error (and cancel the transaction) if the relationship already exists; TOUCH will just no-op

Awesome! Couldn't find it in the docs. Thank you very much!

Just found it in the Api docs. Delete seems to throw though:

CREATE will create the relationship only if it doesn't exist, and error otherwise.

TOUCH will upsert the relationship, and will not error if it already exists.

DELETE will delete the relationship and error if it doesn't exist.

Yeah, I thought so. If JSON allowed trailing comma it would be easier to stream a valid array. Thank you 😁

HI All, I am trying to self host spice DB for implementing access management framework in my system. Can anyone please tell, whether are there APIs/mechanism through which I could update my relationship schema based on User-input? For example, My system will ask a user to give restricted access to some resources/modules to his subordinate (new user he is adding) based on his/her requirements, so is there a way through which I could update the relation schema and restrict the module's access for that newly added user only? Thanks in advance

I have a small question on CREATE and TOUCH As per definition >CREATE will create the relationship only if it doesn't exist, and error otherwise. >TOUCH will upsert the relationship, and will not error if it already exists. If I want to change the relationship that the subject has with the resource I will have to delete the existing relationship using

DELETE

operation then call either

CREATE

or

TOUCH

to save new relation Is that correct?