844600078504951838 #spicedb

Channels

zanzibar

test-forum

spicedb

Jake

08/24/2022, 1:41 PM

The network requests will use a single pipelined http/2 connection

Jake

08/24/2022, 1:41 PM

So at least that’s not awful

Jeroen (Speedzor)

08/24/2022, 1:44 PM

I suppose the last scenario to think about is a mix of the two.. In a world where some users have very restricted access and some others have very broad access, do you have any suggestions on how to manage that? Is it a case of applying different strategies based on some heuristic specific to that user?

Jake

08/24/2022, 1:50 PM

Can’t really say, seems like something that you would have to figure out on a case by case basis

Jake

08/24/2022, 1:51 PM

Maybe you keep a denormalized copy of access in your db using the proposed lookup watch API

vroldanbet

08/24/2022, 1:55 PM

https://github.com/authzed/spicedb/issues/207

Jeroen (Speedzor)

08/24/2022, 1:57 PM

Thanks 👍 Hopefully this problem is more theoretical than anything and we'll be able to assume access is either one or the other. Appreciate you thinking this through with me

Lanny

08/24/2022, 2:29 PM

is there an API to return a relationship given a permission and resource?

Joey

08/24/2022, 2:42 PM

can you clarify what you're trying to achieve?

Lanny

08/24/2022, 3:14 PM

from the user

i want write permission on a resource

, i would need to translate

write

into

zed relationship create blog/post:1 writer blog/user:danny

. I'm not sure how to find the relationship

writer

from

write

Joey

08/24/2022, 3:17 PM

https://github.com/authzed/spicedb/issues/613

Joey

08/24/2022, 3:17 PM

there is a proposal

Lanny

08/24/2022, 3:23 PM

resource_type=resource, permission=own returns ->[owner] ?

Joey

08/24/2022, 3:23 PM

if the proposal is implemented, yes

jzelinskie

08/24/2022, 4:36 PM

You'll notice that the proposal has moved to having a priority. I've started sketching what the API will look like, but I have nothing yet to PR or share. I'd subscribe to that issue to get updates

Lanny

08/24/2022, 8:52 PM

is there a similar API to LookupResources that returns all the users who have permission to an object?

view

access to

document/13234

-> [lanny,danny, etc]

jzelinskie

08/24/2022, 8:56 PM

That's shipping in the next few days: see https://github.com/authzed/spicedb/pull/736 and https://github.com/authzed/api/pull/36

Lanny

08/24/2022, 8:58 PM

very cool and thank you

Lanny

08/25/2022, 1:57 PM

is there a way to reset my account?

Jake

08/25/2022, 2:20 PM

No, but we could maybe help you clean it out? What are you trying to do?

Lanny

08/25/2022, 2:35 PM

remove all permissions and client APIs

tartignolle

08/25/2022, 2:56 PM

Hello, I have a question about the new

LookupSubject API

and its usage with

Proposal: Lookup Watch API and Tiger Cache for fast ACL-aware filtering

(https://github.com/authzed/spicedb/issues/207). I would have expected the LookupSubject to accept a SubjectReference instead of (ObjectReference and permission) Or at least to set the permission attribute to optional

tartignolle

08/25/2022, 2:58 PM

i.e. let's say, the Watch API notifies that the following relation has been removed:

resource:F1#reader@user:U1

In this case, from what I understand, the Lookup Watch API would call the LookupSubject API with the subject part user:U1 But the permission attribut is required in LookupSubjectsRequest, hence I cannot call the LookupSubject API, i.e.

LookupSubjectsRequest {
  ObjectReference: {
    ObjectType: user,
    ObjectId: U1,
  },
  permission: ???
}

Am I missing something ? thanks!

Joey

08/25/2022, 3:26 PM

can you DM me the name of your permission system?

Joey

08/25/2022, 3:27 PM

LookupSubjects wouldn't be used in that case because

user

is a terminal: we know there can't be any other subjects "beneath" it

Joey

08/25/2022, 3:27 PM

now imagine instead it is

Joey

08/25/2022, 3:28 PM

resource:F1#reader@group:somegroup#member

Joey

08/25/2022, 3:28 PM

in that case, the call to

LookupSubjects

would be

LookupSubjectsRequest {
  ObjectReference: {
    ObjectType: group,
    ObjectId: somegroup,
  },
  permission: member
}

Joey

08/25/2022, 3:28 PM

to find all the reachable users

tartignolle

08/25/2022, 3:36 PM

Thanks @Joey I have the following schema:

definition user {}

definition resource_group {
    relation reader: user
    permission read = reader
}

definition resource {
    relation reader: user
    relation writer: user
    relation parent: resource_group | resource
                
    permission read = reader + writer + parent->read
    permission write = reader
}

I create the following relations

relationship("resource:F1#reader@user:U1"),
relationship("resource:F2#reader@user:U2"),
relationship("resource:F1#parent@resource_group:G1"),
relationship("resource_group:G1#reader@user:U1")

I delete this relation:

relationship("resource:F1#parent@resource_group:G1")

I receive the following result from the Watch API:

watchResponse {
  updates [{
    operation = 3
    relationship = {
      objectType = "resource"
      objectId = "F1"
    }
    relation = "parent"
    subject = {
      object = {
        objectType = "resource_group"
        objectId = "G1"
      }
      optionalRelation = ""
    }

I'd then expect to call the LookupSubject API with something like this:

LookupSubjectsRequest {
  ObjectReference: {
    ObjectType: resource_group,
    ObjectId: G1,
  },
  permission: ???
}

Pb is the permission value Thanks !