Bryan
02/28/2022, 11:28 PMBryan
02/28/2022, 11:54 PMJoey
03/01/2022, 12:04 AMwilliamdclt
03/01/2022, 9:47 AMwilliamdclt
03/01/2022, 9:50 AMJoey
03/01/2022, 3:30 PMJoey
03/01/2022, 3:30 PMwilliamdclt
03/01/2022, 3:32 PMJoey
03/01/2022, 3:32 PMJoey
03/01/2022, 3:33 PMBryan
03/01/2022, 4:23 PMrelationships
property. What I was initially doing was
yaml
relationships: >-
document:doc1#owner@user:user1
document:doc1#reader@user:user2
document:doc1#reader@user:user3
I should have been adding a blank line between each tuple:
yaml
relationships: >-
document:doc1#owner@user:user1
document:doc1#reader@user:user2
document:doc1#reader@user:user3
Doing it the first way was causing zed
to read the entire block of text as a single token, which caused bufio.Scanner
to fail.Joey
03/01/2022, 4:24 PMJoey
03/01/2022, 4:24 PMBryan
03/01/2022, 4:45 PMzed import
. It after that, the gRPC request gets too large and zed
would fail with
Error: rpc error: code = ResourceExhausted desc = grpc: received message larger than max (6989893 vs. 4194304)
To get around this, I ended up using one of the gRPC clients the Authzed folks have and I parsed and batched the relationships myself. I think the zed
client could easily be modified to batch very large imports by adding some batching logic here: https://github.com/authzed/zed/blob/e9bfd18aee346632fdbd08ecdb6a38f3a41c6098/cmd/zed/import.go#L144-L150Joey
03/01/2022, 5:34 PMcjs
03/02/2022, 4:14 PMJoey
03/02/2022, 4:14 PMzed
will report the cost when you use verbose/debug logswilliamdclt
03/03/2022, 5:54 PMJake
03/03/2022, 6:59 PMJake
03/03/2022, 6:59 PMalexkorotkikh
03/03/2022, 7:03 PMdefinition org {
relation admin: user
relation member: user
relation partner: partner
permission view = admin + member + partner
}
definition user {
relation self: user
relation org: org
permission view = self + org->admin + org->partner
}
definition partner {}
definition transaction {
relation org: org
relation user: user
permission view = user + org->admin + org->partner
permission edit = user + org->admin
}
We are trying to answer the question "who can view transactions". The idea that the transaction can be viewed by the user who made it, but the admin of the org to which this transaction belongs, and by the partner of the org. As long as we are talking about referencing transaction by id, everything is clear, for the set of relarionships
org:foo#partner@partner:bar
transaction:baz#org@org:foo
assertion transaction:baz#view@partner:bar
evaluates to true
.
What is not clear is, how it should work for the use case when we get multiple transactions based on some filters and pagination. I've read about the Lookup API and found this article https://authzed.com/blog/acl-filtering-in-authzed/, but it's not clear how the workflow should actually look like. Let's extend the example above with one more org-to-partner relationship, and one more transaction for this org
org:qux#partner@partner:bar
transaction:quuz#org@org:qux
Now let's say that partner:bar
requests to view all the transactions of org:qux
. If I use the Lookup API to get the list of all transaction that this partner has access to, I wlil receive 2 transactions id, transaction:baz
and transaction:quuz
.alexkorotkikh
03/03/2022, 7:03 PMorg=qux
) and then take an intersection of two sets, one from the database and one from the Lookup API result. If we have millions of transactions in every set, that doesn't sound reasonable.
I feel like I'm missing something obvious in this use case. Is there a better way to solve the problem I've explained?
Thanks in advance.Joey
03/03/2022, 7:43 PMJoey
03/03/2022, 7:43 PMJoey
03/03/2022, 7:44 PMJoey
03/03/2022, 7:44 PMCheck
each result in parallelJoey
03/03/2022, 7:45 PMwilliamdclt
03/03/2022, 8:02 PMpartner_of_org
. It's basically an object representing the relationship between a single partner and a single org, its ID could be a concatenation of the partner ID and the org ID.williamdclt
03/03/2022, 8:02 PMdefinition partner {}
definition partner_of_org {
partner: partner
}
definition org {
relation admin: user
relation member: user
relation partner: partner_of_org#partner
permission view = admin + member + partner
}
definition user {
relation self: user
relation org: org
permission view = self + org->admin + org->partner
}
definition transaction {
relation org: org
relation user: user
permission view = user + org->admin + org->partner
permission edit = user + org->admin
}
Now, if you want to query all transactions viewable by a partner, you can lookup transaction#viewable
for partner:partner_id
.
If you want to query transactions viewable by a partner in a given org, you can lookup transaction#viewable
for partner_of_org:org_id__partner_id
.
That means you'll need your relations to be like
org:qux#partner@partner_of_org:qux__bar#user
partner_of_org:qux__bar#user@partner:bar
transaction:quuz#org@org:qux
alexkorotkikh
03/03/2022, 8:13 PM