Thanks @User

Hi folks, how do we define a relation which is kinda global for all definitions. For Example, I want a specific group to be admin for all the resources created

definition user {}

definition group {
    relation member: user
}

definition organization {
    relation resource: resource
    relation admin: user
}

definition resource {
    relation admin: user | organization#admin | group#member
    relation viewer: user

    permission manage = admin + viewer
}

We have made seperate resources & their admins, like in example below

definition user {}

definition group {
    relation member: user
}

definition organization {
    relation r1_admin: group#member
    relation r2_admin: group#member
}

definition resource/r1 {
    relation admin: organization#r1_admin | group
    relation viewer: user

    permission manage = admin + viewer
}

definition resource/r2 {
    relation admin: organization#r2_admin | group
    relation viewer: user

    permission manage = admin + viewer
}

It's not static to the schema, but one solution is to simply have a group called Admins and to write a relationship that adds that group as an admin when you create a new resource

There might be better ways than that, depending on what you want to accomplish, but this is a simple solution that works pretty generally.

We are observing that spicedb is taking time to update the relations. Code - https://github.com/rsbh/authz-spicedb/blob/kv We are seeing that if we are not adding the time.sleep after adding & deleting relations, we are getting inconsistent output ### logs: without sleep

written_at:{token:"GgMKATI="}
written_at:{token:"GgMKATM="}
written_at:{token:"GgMKATQ="}
written_at:{token:"GgMKATU="}
written_at:{token:"GgMKATY="}

PERMISSIONSHIP_HAS_PERMISSION
PERMISSIONSHIP_HAS_PERMISSION
PERMISSIONSHIP_NO_PERMISSION

deleted_at:{token:"GgMKATc="}

PERMISSIONSHIP_HAS_PERMISSION
PERMISSIONSHIP_HAS_PERMISSION
PERMISSIONSHIP_NO_PERMISSION

with sleep

written_at:{token:"GgMKATI="}
written_at:{token:"GgMKATM="}
written_at:{token:"GgMKATQ="}
written_at:{token:"GgMKATU="}
written_at:{token:"GgMKATY="}

PERMISSIONSHIP_HAS_PERMISSION
PERMISSIONSHIP_HAS_PERMISSION
PERMISSIONSHIP_HAS_PERMISSION

deleted_at:{token:"GgMKATc="}

PERMISSIONSHIP_NO_PERMISSION
PERMISSIONSHIP_NO_PERMISSION
PERMISSIONSHIP_NO_PERMISSION

@User if the permission check is this one https://github.com/rsbh/authz-spicedb/blob/main/internal/permission/check.go#L15, its likely because you're not sending a ZedToken back

by default, the consistency is "best effort": i.e. caching is used. If you don't send back a ZedToken, and you don't change the consistency level, then there will be a period of time where the cache is used to compute a permission response vs going to the datastore

this is what enables highly scalable computation, since it won't have to retrieve data from the database on every call

normally, this is also okay: its not expected that if you remove someone they need to lose access immediately, because they previously did have access to the protected resource's contents. If the contents of the resource, however, are to be changed, then you need to send a ZedToken to ensure the access loss is accounted in the check

We have a blog post that covers this subject from a conceptual level here: https://authzed.com/blog/new-enemies/

Thanks for prompt reply 🙂

We tried spicedb locally with postgres 13, and have some questions 1. When we tried to run the [code](https://github.com/rsbh/authz-spicedb) against the spiceDB, we in the logs that we are actively querying the database:

4:07PM INF Query args=[] module=pgx pid=232 rowCount=1 sql="SELECT NOW()"
4:07PM INF Query args=["2021-10-12T10:37:24.672923Z"] module=pgx pid=232 rowCount=1 sql="SELECT MIN(id), MAX(id) FROM relation_tuple_transaction WHERE timestamp >= $1"
4:07PM INF Query args=[] module=pgx pid=232 rowCount=1 sql="SELECT MAX(id) FROM relation_tuple_transaction"
4:07PM INF finished server unary call grpc.code=OK grpc.method=CheckPermission grpc.method_type=unary grpc.service=authzed.api.v1.PermissionsService grpc.start_time=2021-10-12T16:07:29+05:30 grpc.time_ms=9.295 kind=server system=grpc

and when we stopped the db, the queries failed. Is there any mode in which we just cache the whole relationship graph in spicedb memory so we dont query pg for reads? something like sync the db whenever there is a write or periodically say every 1 mins Our startup command

$ spicedb serve --grpc-preshared-key "shield" --grpc-no-tls --datastore-engine postgres --datastore-conn-uri "postgres://shield_dev:@0.0.0.0:5432/shield_dev?sslmode=disable"

2. Do we need to run migrations for fresh db only.. right?

$ spicedb migrate HEAD --datastore-engine postgres --datastore-conn-uri "postgres://shield_dev:@0.0.0.0:5432/shield_dev?sslmode=disable"

3. Is there any approach to make it HA? One approach can be to use consul to balance load between multiple spicedb (as its grpc), but if we go with in-memory along with PG (if its possible from question 1), is there a way to sync the updates on all the spicedb instances/pods once there is a write or they could just periodically sync it

Hi @User : 1) The datastore must always be available for SpiceDB, to ensure proper consistency. Caching completely would result in the possibility of the New Enemy Problem (amongst other problems) 2) Migrations only need to be run for a fresh DB, or when SpiceDB adds a new migration 3) Recommendation is to use Cockroach DB, as it was explicitly designed to be a multi-master datastore

thank you!

Hi folks, been recently looking into spicedb and just wondering what api version to use? The docs seem to point to use v0, is v1 still very much work in progress and not fully ready?

You should be using v1 -- v0 just has more documentation from its legacy. We use https://buf.build/authzed/api/docs/main/authzed.api.v1 for API docs now instead of writing our own.

OK cool, cheers

noted though! we need to update the docs to de-emphasize v0

Hi folks, is there a way to get a list of all permissions and/or relations a user has in a given object? Looking at the API don't see an obvious way.

@User you can use the

Read

API to find all the relations on which a user has a relationship for an object

permissions, on the other hand, you'd have to compute, so you'd need to use an

Expand

if the idea is to build something like, say, a permissions panel

yes, something like that, a permissions panel

the recommendation is to call

Expand

on your most permissive permission (typically

view

), and then it'll show all the users who have permission for that object and that permission (and any permissions that are included in that permission) as a tree

as a concrete example, if you had this schema:

definition user {}

definition document {
  relation admin: user
  relation writer: user
  relation viewer: user

  permission write = admin + writer
  permission view = viewer + write
}

calling

Expand

on

document:somedocument

and

view

, will return a tree containing all users who are in relations

viewer

,

writer

and

admin

, since all three form

view

with each set of users placed under their relation

we also recognize this is a common use case, so we're investigating ways to potentially provide an API for making this simpler for this case

but

Expand

does have the full set of info

thanks for the explanation Joey, will have a look at expand if can do what we are looking