you must fill in the reverse yourself

Is it possible to have dynamic permissions in schema instead of having few static one ?

no

what, exactly, are you trying to do?

I have requirement like this, Roles Marketing Sales Finance Record A role assigned Markrting and finance and Sales Record B has Role assigned Markrting. User A assigned to Markrting role of Record B and assigned to Sales Role of Record A I want to query as below Fetch all roles that User A has on Record B

you'd use a read relationships for the user on the record if you are using an RBAC-like system

Hi! First of all thank you for setting up this Discord server and allowing people to ask questions! I have a consistency question (I think?). I'm thinking about using SpiceDB in a proxy performing a bunch of authz checks and found myself wondering which consistency would I need to specify when doing CheckPermission there. I wanted to store zedtokens on said proxy level so the services protected by it don't have to care about them. If I store zedtokens in Redis I think following the situation is possible: Starting state: User A has permission to read document stored in a service. ZedToken1 is stored in proxy Redis. T1 - permission is revoked for User A, document is updated, ZedToken2 gets stored in Redis T2 - proxy performs CheckPermission, but because of the Redis consistency ZedToken1 is used If I understand correctly, calling CheckPermission with

fully_consistent

consistency in this situation will guarantee that we will get "no permission", but what about

at_least_as_fresh

using ZedToken1? Is it possible that the permission revoke from T1 is still not propagated in T2 and CheckPermission with

at_least_as_fresh

and ZedToken1 would return "has permission"? Or because of Consistent Hash Load Balancing even though permission revoke is not propagated across all nodes - CheckPermission with

at_least_as_fresh

and ZedToken1 will return "no permission" anyway because we would "talk" to the same node each time?

If you used zedtoken1 it could return “has permission”. Using fully consistent will get you the answer that you want, but at the cost of performance. The general recommendation is to store zedtokens alongside content, and only update the zedtoken when the content changes. Thus, the particular sensitive version of the content will be protected, regardless of what mutations are happening to permissions outside of that.

Hey there! I've been trying to figure out an issue with connection to SpiceDB within Kubernetes cluster. I have 3 pods running and one endpoint on port 80. Maybe I missed something?

<_MultiThreadedRendezvous of RPC that terminated with:
    status = StatusCode.UNAVAILABLE
    details = "failed to connect to all addresses; last error: UNKNOWN: ipv4:172.20.219.130:80: Endpoint is neither UDS or TCP loopback address."
    debug_error_string = "UNKNOWN:failed to connect to all addresses; last error: UNKNOWN: ipv4:172.20.219.130:80: Endpoint is neither UDS or TCP loopback address. {grpc_status:14, created_time:"2022-11-10T22:12:13.945987969+00:00"}"
>
Traceback (most recent call last):
  File "/home/logdna/.cache/pypoetry/virtualenvs/kong-benchmark-tq7C0_9c-py3.7/lib/python3.7/site-packages/locust/user/task.py", line 347, in run
    self.execute_next_task()
  File "/home/logdna/.cache/pypoetry/virtualenvs/kong-benchmark-tq7C0_9c-py3.7/lib/python3.7/site-packages/locust/user/task.py", line 372, in execute_next_task
    self.execute_task(self._task_queue.pop(0))
  File "/home/logdna/.cache/pypoetry/virtualenvs/kong-benchmark-tq7C0_9c-py3.7/lib/python3.7/site-packages/locust/user/task.py", line 490, in execute_task
    task(self.user).run()
  File "/opt/app/kong_bench/spicedb/check_permissions.py", line 83, in __init__
    token_per_user=self.token_per_user,
  File "/opt/app/kong_bench/spicedb/seed.py", line 126, in run
    init_counter=max(user_amount, self.default_amount_to_check),
  File "/opt/app/kong_bench/spicedb/seed.py", line 367, in findLastId
    does_exist = checkId(end)
  File "/opt/app/kong_bench/spicedb/seed.py", line 428, in isUserWithId
    optional_relation='inheritor',

it looks like you need to enable SSL, or use the

insecure_bearer_token_credentials

from our client library: https://github.com/authzed/authzed-py/blob/main/grpcutil/__init__.py#L16 Note, this should almost surely not be used for production.

I use

insecure_bearer_token_credentials

to connect to DB, but still have this error

are you instantiating and using the client like this? https://github.com/authzed/authzed-py/blob/main/examples/v1/check_permissions.py

Yes, this is code to create a client. The usage of client is the same as in your example. It works locally.

self.client = Client(
    self.host,
    insecure_bearer_token_credentials(config.with_spicedb_secret_token)
)

you mean it works when the address is

localhost

?

It works when I run the code on local machine with SpiceDB running locally

can you enable TLS?

This is internal service we don't use TLS internally, only on the Gateway level

I have a nodejs application which is running in the same Kubernetes cluster and it has no problem to connect to the same instance of SpiceDB, same port 80, for nodejs app we use

INSECURE_PLAINTEXT_CREDENTIALS

option to connect

it looks like we made a special dispensation for this in golang, but don't have a helper in the python client, it should be possible to create a new type of authorizer that copies the insecure authorizor code and removes the host checking

here's the equivalent code in go: https://github.com/authzed/grpcutil/blob/main/dial_opts.go#L80

So, you mean we need another option to init connection for python library?

I didn't dig deep into a grpc library, but it looks like I need to figure this out)

If you used zedtoken1 it could return

What is command to check spicedb version

spicedb version

is listed in

spicedb --help

.

spicedb serve

also logs on startup what version you are running.

is it or would it be possible to batch permission checks?

to what end?

Not sure what you mean. I'd like to send check multiple permissions in a single request rather than making multiple requests.

for the same resource and subject and different permissions or...?

different permissions for different resources for different subject