Constraints for create rules

[dennemark]

Hi @stalniy ,
My prisma-extension-casl package is doing well so far, but I am running into an issue, when I try to create entries with prisma.
like client.user.create({ data: { id: 0 } }) or also for connectOrCreate.

My current approach is, to compare the constraints of can('create', 'User', { id: 1 }) with my creation object. In this case it would fail.
However there are cases, where one would like to restrict via relations. This is possible for read/update/delete since they all rely on Where queries. But not for create. I.e.:

can('create', 'User', {
   organisation: {
     is: {
        id: org.id
         owner: my.id
       }
   }
})

I have two approaches to this issue:

1. supply Prisma.CreateUserInput instead of Prisma.WhereUserInput

can('create', 'User', { 
  organisation: {
    connect: {
      id: org.id
         owner: my.id
     }
  }
} as Prisma.CreateUserInput)

2. Keep logic of constraining input only. Write rules separate from prisma client.

ability.can('create', 'User') // with same ability we defined above - if it is wrong, it will fail
client.user.create({
  organisation: {
     connect: {  
       id: org.id
        owner: my.id
     }
  }
})

➖ repeated logic in prisma client
➖ data such as org.id needs to be available within abilities as well as in query

The second approach has quite some disadvantages. However, the first approach does not work with ucast. Do you have an idea from your experience with creating entries?

[dennemark]

I am going to try to do the creation within a transaction. So I create without permissions and check the results, if they have the permission. If not, I am going to throw an error which should rollback changes of the transaction.

Only issue is, that prisma does not support it well in client extensions :/

[stalniy]

Create operation is different. You can’t check it with db query (though your idea with transaction is quite creative 👍 )

In my experience, I create record in memory and check whether it’s possible to create it in runtime before sending actual query to db

[stalniy]

Basically inside extension, If it’s possible to hook into preCreate then you can check permission using Ability in runtime

[dennemark]

Thanks! It seems to work with my transaction approach. I only loose capabilities for sequential transactions in prisma, but interactive ones are still working!
I like this approach, since I do not need to gather all related data in advance, but it will be queried automatically.

So if I do a nested create with a relation ability, it will get the data an check if it is permitted to create.

The commented part is added by the client extension within the extension.

can('create', 'Comment', { post: { is: { owner: me } })
db.post.create({
   data: {
      owner: me,
      comment: {
         create: {
             text: test
           },
//          include: {
//            post: {
//               select: {
//                   owner: true
//                }
//             }
          }
    }
})

and afterwards within a transaction i then check ability.can('create', 'Post', myPost) as well as ability.can('create', 'Comment', myComment) with myPost and myComment having all the necessary data taken from the can rule.

Only issue might be rather large queries, but lets see... I think I would have to do them anyways...