Protecting Fields

Parse Server 📡
1

I’m looking for some information on how we can achieve more granular control over fields permissions. ACLs allow us to set read/write access to an entire object, but not separate settings per field.

To be more precise I have a class with multiple fields and I want to achieve something like this:
Field A is hidden from everyone. Field B can be read by everyone, but no one can write to it and Field C can be read by everyone and certain users(based on ACLs) can write to it.

For Field A it’s simple to use protected fields feature, but this feature seems to only allow disabling both r/w access at the same time.

I know there are multiple options to achieve this, like manually checking the user’s access against an object’s ACLs in cloud code and force writing on Field C using the master key, but it feels a bit “hacky”. I could also move Field C to separate class that points to the current one, but it would introduce a bit of extra complexity in queries. Was thinking also thinking about using a beforeSave trigger or validator, but don’t really know how I can make sure in there that the user trying to write has write access in the ACLs.

So, what do you guys think would be the best way to achieve this using the current functionality provided by Parse Server.

2

As far as I know, there are no options for ACL on fields. As you think, you can do it in the triggers.

3

After investigating this a bit, I found that the easiest way to do it is indeed using triggers. What I currently do is that I use a validator object on the beforeSave trigger of that class:

export const MyClass_BeforeSave_Validator = {
    fields: {
        fieldB: { constant: true }
    }
};
Parse.Cloud.beforeSave("MyClass", (request) => { }, MyClass_BeforeSave_Validator);

With this setup I have:

  • CLP Read: everyone
  • CLP Write(Update only): Authenticated
  • Protected fields: fieldA

So:

  • fieldA is not accessible by anyone because because it’s added as a protected field(you can do that from the Security section of the dashboard easily)
  • fieldB can only be set at creation and becomes immutable without using the master key because it is marked as constant in the object validator of the beforeSave trigger
  • fieldC can be accessed as usual based on the object’s ACL

The only downside to this approach is that marking a field as constant in a validator object seems to only silently prevent the field from being updated. It does not throw any error/notification that the operation did not happen. In some cases it might work exactly how you would want to, but it would have been good to have the option to decide whether or not you get an error message when you try to update a constant field. Maybe a different “readOnly” option could be added to achieve this. I might open a PR soon for this.

1 Like