Cannot rule with properties not included in query

[dennemark]

Hi,
I am currently trying to create a prisma client extension that integrates casl. But there is a case that is not resolving properly. I have the following two rules:

can('read', 'User', {
            id: 0
        })
cannot('read', 'User', 'email', {
            id: 1
        })

If I get their query via accessibleBy(ability, 'read').User it results in:

{ OR: [ { id: 1 } ] }

And if I try to get omitted or permitted properties I use permittedFieldsOf it only iterates over the first rule in fieldsFrom. Similarly rulesToFields(ability, 'read', 'User') only returns the can rule.

However if I leave out the property from cannot rule:

can('read', 'User', {
            id: 0
        })
cannot('read', 'User', {
            id: 1
        })

It results in this query:

      OR: [ { id: 1 } ],
      AND: [ { NOT: { id: 0 } } ]
    }

Is there some logic behind it or is this a bug?

I think there might be similar issues when using

can('read', 'User')
cannot('read', 'User', ['email'])

since permittedFields will return nothing.

casl/packages/casl-ability/spec/permitted_fields.spec.js

Line 36 in 14bf935

cannot('read', 'Post', ['description'])

[dennemark]

Fresh from the oven: https://www.npmjs.com/package/prisma-extension-casl
@stalniy the issue above is the only unresolved test within my package right now. I think I solved the last case by getting all permitted fields even if some are omitted: https://github.com/dennemark/prisma-extension-casl/blob/68e3f9db33330e7bffd334e032df0320e7b20962/src/helpers.ts#L86

[serhiistotskyi]

Well, yes, it seems you found a bug in rulesToQuery helper function which is responsible for collecting conditions into single object

Nice catch!

[serhiistotskyi]

basically if there is an inverted rule with fields it should be added to OR condition as regular rules. So, in your case casl must return:

{ OR: [ { id: 1 }, { id: 0 } ] }

[dennemark]

This seems to be a tricky case. Since it is conditional.

I am going to try to write out what I would expect:

1. For

can('read', 'User')
cannot('read', 'User', ['email'])

I would expect permittedFields to return all but email. This is difficult though, if not all fields are known by CASL. I can do this within prisma though, since I can access them through prisma.dmmf.....
For plain CASL I am not sure how to solve this.

2. The expected case for

can('read', 'User', {
            id: 0
        })
cannot('read', 'User', {
            id: 1
        })

Seems to be correct

{
    OR: [ { id: 0 } ],
      AND: [ { NOT: { id: 1 } } ]
    }

And this one is very challenging because it is conditional:

can('read', 'User', {
            id: 0
        })
cannot('read', 'User', 'email', {
            id: 1
        })

PermittedFields should only return no email, if id is 1. This cannot be represented in a where query. I guess this is why it is not added to it? So this data would need to be filtered afterwards.

I was trying to bring this logic in my client extension. I can transform the props into select queries, but for this conditional logic, it is very difficult (if not impossible) to handle. Since the only query I could come up with is this:

{
select: {
  email: false
},
 where: {
    {
    OR: [ { id: 0 } ],
    AND: [ { NOT: { id: 1 } } ]   // does not work with or without
    }
 }
}

However one thing I could try, is checking if the where clause matches the cannot condition, and if it applies, then I have to remove the email.
So going from

{ where: { id: 1 } }

to

{ where: { id: 1 }, select: { email: false } }

This question is quite specific for the client extension, maybe not so much for CASL. But I think the only part stopping me from implementing this, is the issue, that this rule is not being handled by permittedFieldsOf:

cannot('read', 'User', 'email', {
            id: 1
        })

So if this boils down to a bug in rulesToQuery I hope it can be solved without issues :)

[serhiistotskyi]

OK, let's step back to this particular example:

can('read', 'User', { id: 0 })
cannot('read', 'User', 'email', { id: 1 })

and say it in human language:

you can read user with id = 0 but cannot read user email with id =1

The issue with this statement is that you cannot read User with id = 1 at all :) What you should say instead is

can('read', 'User', { id: { IN: [0, 1] } })
cannot('read', 'User', 'email', { id: 1 })

In this case on conditions level you will get { id: { IN: [0, 1] } } which is correct and fields you will need to filter out on client side or create a complex switch/case statement (which is not possible in cross db env I guess)

[serhiistotskyi]

In postgres you could say something like:

SELECT id, name, 
  CASE
  WHEN id != 1 THEN email
  ELSE null
 END AS email
FROM users

[dennemark]

🤦‍♂️ true you cannot read id 1 at all..

Also transforming this conversion would not work:

{ where: { id: 1 } }
to
{ where: { id: 1 }, select: { email: false } }

since one could easily escape it.

Would be great if prisma would be postgres only :D

[dennemark]

Now I am wondering if I should make a query to prisma and run the result afterwards through CASL abilities, too. Haven't thought it through yet, but might be another good option.

[dennemark]

I am trying to do the filtering now after the query. The approach is slightly better, but I am running into another issue. I have been reading a bit through some issues on prisma. And it seems I have to write my nested rules like this:

can('read', 'Post', 'id', {
                thread: {
                    is: {
                        creatorId: 0
                    }
                }
            })

However, I am not able to get the fields via one of these calls:

// this first call would be great. I could just supply prisma query results and filter unwanted fields
permittedFieldsOf(abilities, action, subject('Post', { thread: { creatorId: 0 } }), fieldsFrom: rule => rule.fields || modelFields)
// this second call does not help either
permittedFieldsOf(abilities, action, subject('Post', { thread: { is: { creatorId: 0 } } }), fieldsFrom: rule => rule.fields || modelFields)

When I go through the rules separatly, the matchConditions function returns undefined. Would you have some recommendation @stalniy ?

PermittedFieldsOf does not use prismaQuery under the hood does it? Because this one works:

expect(prismaQuery({ thread: { is: {creatorId: 0}}})({ 
                thread: { creatorId: 0}
            })).toBe(true)

This one might work though as an alternative to permittedFieldsOf - though I am not sure about inverted rule right now:

        const fieldSet = new Set()
        abilities.possibleRulesFor(action,model).forEach((rule)=>{
            if(!rule.inverted && rule.fields && rule.conditions && prismaQuery(rule.conditions)(obj)){
                fieldSet.add(rule.fields)
            }

        })