[Feature Request] Field-level policy: provide a way to "override" model-level rules

[ymc9]

Today, for having access to a field, both model-level and field-level (if any) policies need to be satisfied. This can be very inconvenient for scenarios where a user can only update one field but nothing else.

Concrete example:

• Admin users can update all fields of "User" model
• Regular users can only update "password" field of their own

To allow the second rule, we have to let regular users pass model-level "update" policies, however, then we have to add "@deny" rule on all fields except for "password".

The proposed solution, as discussed with @jasonmacdonald , is to introduce a third parameter to "@Allow" attribute to let it "override" model-level policies:

password String @allow('update', auth() == this, true)

Discord thread: https://discord.com/channels/1035538056146595961/1171196847797325854

[ymc9]

Hi @jasonmacdonald , you also mentioned another case:

Another use-case is the profile relation. If you want to update your Profile, you must update it through a direct profile query if not admin, because any query which "passes through" the user model as nested updates are immediately revoked by the User policy, even if the only field you are trying to update is allowed at the field level.

Could you show the Prisma query that you want to make work? I just want to make sure it's also covered in the implementation. Thanks!

[jasonmacdonald]

Hi @jasonmacdonald , you also mentioned another case:

Another use-case is the profile relation. If you want to update your Profile, you must update it through a direct profile query if not admin, because any query which "passes through" the user model as nested updates are immediately revoked by the User policy, even if the only field you are trying to update is allowed at the field level.

Could you show the Prisma query that you want to make work? I just want to make sure it's also covered in the implementation. Thanks!

Really, it's the same as the first, only on a relation rather than a property.

Example:

model User {
     id  String   @id @unique @default(uuid()) @db.Uuid
    ...
    password  String @allow('update', auth() == this, true)
    profileId  String   @unique 
    profile  Profile  @relation(fields: [profileId], references: [id]) @allow('update', auth() == this, true)
    
    @@allow('create,update,delete', auth().role == 'ADMIN')
    @@allow('read', true)
}

In this scenario, you could not update the password or anything in the Profile, even though you may have permission to update your own profile since the model level @@allow blocks both unless you are admin.

If, however, both @allow calls allow overriding for a user's own data, it's still possible to update the Profile model and the password, while blocking any other changes.

{
   data: {
      password: '12345'
      profile: {
         update: {
           data: { 
               phonenumber: '555-555-5555'
           }
         }
      }
   },
   where: {
        id: 'MyId'
   }
}

I would assume the ability to resolve the first scenario would likely work for the second, so it might just be a matter of ensuring it works.

[ymc9]

Got it. Thanks for providing the details.

I'm actually thinking, if only "profile" is updated, it probably shouldn't trigger User's "update" check at all (both model-level and field-level), since it's not really touching User. I need to think a bit more about this ...

[jasonmacdonald]

Got it. Thanks for providing the details.

I'm actually thinking, if only "profile" is updated, it probably shouldn't trigger User's "update" check at all (both model-level and field-level), since it's not really touching User. I need to think a bit more about this ...

Yes, when no User fields are changed, just skipping the User model checks makes sense, provided the Profile policies are still run against its nested changes - I assume that would be the case.