Title
#help
m

Matthew Ebeweber

09/30/2022, 2:57 PM
One question for ya’ll today 🙂 thanks for all your help this week as I continue to throw things at you. For this example let’s say I’ve got a bunch of Profiles in my system and I can view them based on the existence of some Connection model (connects me and that profile). So you might have something like a User table, a Profile table and then a Connection (light join table between a User + Profile). Ultimately I'd love for things to be performant + do well when query planning. This information can either live on the Principal or the Resource. The Principal feels more natural, but would require passing all my connections in, which doesn’t feel like it’s going to scale too well. You could make a new resource attribute (R.attr.hasConnection) , that’s a bit principal aware. You could lean on the database here and just check for the existence of some thing. On the query side you want to be able to map this variable to a prisma condition like the below, but I’m not sure if there’s a good way to do this?
some: {
 connection: { id: R.id, user: P.id }
}
2:59 PM
Another solution might be building an additional filter mapping that takes conditions like
R.attr.hasConnection: true
or whatever and does additional mapping to what's expected. But wondering if the
fieldNameMapper
could benefit from non string -> string mapping
Alex Olivier (Cerbos)

Alex Olivier (Cerbos)

09/30/2022, 3:00 PM
The latest Prisma adapter handles relations Prisma Schema Test Policy Test case for some
3:01 PM
Does that work for your case?
m

Matthew Ebeweber

09/30/2022, 3:13 PM
You're too fast Alex 🙂 This definitely helps! If I follow, in the example there if
ownedBy
becomes really large, aren't you still potentially passing a lot of extra information into the
checkResource
calls? Where as the information you might care about is "is the principal an owner?"
Alex Olivier (Cerbos)

Alex Olivier (Cerbos)

09/30/2022, 3:17 PM
If you are authorizing just a single instance (rather than a listing page) and using check resource then indeed if the list is large, then the recommended optimisation would be to just have an
isOwner
boolean as an attribute on the resource
3:17 PM
create it ‘on the fly’ as it were based on your DB query before passing into Cerbos
m

Matthew Ebeweber

09/30/2022, 3:20 PM
So then do I need to balance/handle both to support both the listing/check calls well?
3:23 PM
For example, READ is the action and I want to power a
/list
view and a
/list/:id
where I use the query planner for
/list
but want to check the resource on
/list/:id
Alex Olivier (Cerbos)

Alex Olivier (Cerbos)

09/30/2022, 3:24 PM
in this case i would create two ‘actions’ in the policy. one for ‘list’ which is used on the
/list
and the query plan one for ‘view’ which is used on
/list/:id
3:25 PM
the conditions would be similiar expect for the
owner
field - the first case it would be something like
P.id in R.attr.owners
used to model the relation, in the 2nd it would just be a boolean
m

Matthew Ebeweber

09/30/2022, 3:29 PM
Interesting, but makes sense. I'll do some thinking on that and think about the lift of splitting the two out. Right now, all of our policies are written in a way where we can check + plan. Sounds like we'll have to let go of that at some point.
Alex Olivier (Cerbos)

Alex Olivier (Cerbos)

09/30/2022, 3:31 PM
In most cases keeping it as one works but if you are worried about the size of the owners list then spilting out helps.
m

Matthew Ebeweber

09/30/2022, 3:32 PM
Might be someone else's problem in a year 😛
3:32 PM
and to confirm, we'll throw in v1 if the query planning doesn't work?
3:33 PM
My other fear is an engineer using the query planning incorrectly, shooting themselves in the foot because it doesn't compute and giving access to everything.
Alex Olivier (Cerbos)

Alex Olivier (Cerbos)

09/30/2022, 3:34 PM
Can you expand on that a bit?
3:35 PM
I think I'm good 🙂
8:06 PM
Does cerbos/orm-prisma only support one join (the relationship has to be a string)? I'd love to support something like..
where: { join_1: { join_2: { some: { field: thing } } } }
Alex Olivier (Cerbos)

Alex Olivier (Cerbos)

10/03/2022, 8:07 PM
Currently yes. Open to ideas on how to improve it!
m

Matthew Ebeweber

10/03/2022, 8:11 PM
This would be useful on my end, can look at the orm-prisma library as well to see how you might extend. Supporting it feels like it should be ~fairly straightforward? You could specify something like ['join_1', 'join_2'] to describe the relationship. Field would remain the same.
Alex Olivier (Cerbos)

Alex Olivier (Cerbos)

10/03/2022, 8:12 PM
Hadn’t thought of using a list like that - nice.
8:48 PM
Ok got a couple of ideas. Likely won’t have a chance to look at this until next week now but any PRs are welcome 😉