Title
#help
p

Petar Mrdalj

11/14/2022, 11:20 AM
Hello I have a question when using nestJS with graphQL and cerbos Currently I have implemented an interceptor which is called before the resolver mutation code is actually called which is the behaviour I am expecting. While using grpc I need to provide a resource id which is not the case as to when using http:
principal: {
        id: userData.userId,
        roles: userData.roles,
      },
      resource: {
        kind: cerbosObject,
        id: "1",
      },
      action: host.getHandler().name,
While looking into these examples https://github.com/cerbos/demo-graphql/blob/main/src/resolvers/Expenses.queries.ts it makes sense to actually call the db and compare the id's. How would you handle the permission check for creating or deleting a certain object from the db in which case you only need to check for the role and you do not need the id in the resource object? It is a required value in the request. Thanks in advance πŸ‘
Alex Olivier (Cerbos)

Alex Olivier (Cerbos)

11/14/2022, 11:24 AM
In this case we recommend just putting in a static value of β€˜new’ so similar. Whatever value you use will appear in the audit logs also. For deleting in most cases you would have the ID of the the resource being deleted I assume?
p

Petar Mrdalj

11/14/2022, 11:33 AM
@Alex Olivier (Cerbos) Thanks for the quick response! πŸ™‚ Checking it out
Andrew Haines (Cerbos)

Andrew Haines (Cerbos)

11/15/2022, 11:28 AM
Another way to get around not having an ID for new resources is that I often put the "create" action on a parent resource. Typically there's logic related to the parent to determine if you can create a child anyway. For example, if your resources were
folder
and
file
, it might make sense to have a
createFile
action on the
folder
resource policy rather than a
create
action on the
file
, because the logic of who is allowed to create a file is mainly determined by on their permissions on the containing folder. This might not be the case for every resource but it's worth considering in the context of your domain πŸ™‚
p

Petar Mrdalj

11/15/2022, 11:35 AM
Thanks @Andrew Haines (Cerbos) currently we have done something similar based on the previous answer. We created a higher level policy which actually determines the access level and after that we are using specific resource access policies πŸ™‚ Currently still testing but looks good Btw nice alpaca πŸ˜„
Andrew Haines (Cerbos)

Andrew Haines (Cerbos)

11/15/2022, 11:37 AM
Awesome! Thanks 😁 πŸ¦™