Security is one of the most critical aspects of releasing a production app, and with Parse there are lots of ways you can secure your app. As Bryan laid out in his 5-part security series, Parse provides a powerful security toolset, including the master key, Access Control Lists (ACLs), Class-Level Permissions (CLPs), and Cloud Code. Every successful production app uses some features out of this toolset, and we are always working to improve its ease of use for Parse developers to take advantage of these effective tools. A few months ago, we released an updated ACL editor, making it much easier to view and edit ACLs in the data browser. Today we are releasing a new and improved CLP editor, so you can view and edit your app’s Class-Level Permissions just as easily as its object-level ACLs!
Just like ACLs, CLPs are lists of users or roles that can access a specific class of your app. As with ACLs, you can give each user/role read or write access. Let’s see how this works in an example. Say we have a restaurant app, with a
Restaurant class. To edit the CLPs for the
Restaurant class, click the ‘Security’ button at the top of the data browser. This will open the new CLP editor, and you will notice that the default permissions for every class is public read and write (with some exceptions).
You may notice that this looks strikingly familiar to the ACL editor. Right now the
Restaurants are completely public, meaning that any user of the app can see every
Restaurant, and can change every
Restaurant. We probably don’t want
Restaurants to be completely public, because then any user could just delete all the
Restaurants in the database and our app wouldn’t do much after that. So, let’s disable public writes.
Now any user can see all the
Restaurants, but nobody can change any
Restaurants (without the master key). But maybe I want my own user to be able to create new
Restaurants, or update old ones. I can add my user to the CLP editor by typing in my username or objectId, and allow writes for that user by clicking the “Write” checkbox.
jamie user can do whatever he wants with all of the objects in the
Restaurant class, while no one else can write to this class. But maybe there are some other users that should be able to write to this class, and I don’t want to keep adding each user one-by-one. Let’s use a role, which we’ve named
admin . First we add all the users we want to have write access to the
admin role, then we type the role name into the next row, and finally we enable write access by clicking on the “Write” checkbox.
Any user in the
admin role can now make changes to the
Restaurant class. But what if we want to let some other group of users – those in the
chef role – add new
Restaurants, but not be able to edit existing
Restaurants? To do that, we first click the settings gear at the top-right of the editor, and switch to the “Advanced” mode of the editor. In the advanced mode we can set more specific permissions on the class for different request types.
There are 6 types of permissions you can manage in the CLP editor, based on the different types of requests you can make to Parse. We group these permissions into “Read” and “Write” categories, with the exception of “Add Field”.
- Get — With Get permissions enabled, users can fetch objects in this class if they know their objectIds.
- Find — Anyone with Find permissions enabled can query all of the objects in the class, even if they don’t know their objectIds. Any table with public Find permissions will be completely readable by the public, unless you put an ACL on each object. (with some exceptions)
- Update — Anyone with Update permissions enabled can modify the fields of any object in the class. For publicly readable data, such as game levels or assets, you should disable this permission.
- Create — Like Update, anyone with Create permissions enabled can create new objects of a class. As with the Update permission, you’ll probably want to turn this off for publicly readable data.
- Delete — With this permission enabled, users can delete any object in the class. All they need is its objectId.
- Add Field — Parse classes have schemas that are inferred when objects are created. While you’re developing your app, this is great, because you can add a new field to your object without having to make any changes on the backend. But once you ship your app, it’s very rare to need to add new fields to your classes automatically. So you should just about always turn off this permission for all of your classes when you submit your app to the public.
Going back to our example, we wanted to ensure that all users in the
chef role could create
Restaurants, but we don’t want them to be able to update or delete any existing restaurants. To accomplish this we simply add a row for the
chef role, and check “Create”.
We could add permissions for any of the other types of requests in just the same way. CLPs are an extremely powerful tool for quickly and easily securing your app. But before you add a bunch of CLPs to your app, make sure you understand how CLPs and ACLs interact with each other.
We are excited to continue giving Parse developers better ways to secure their apps, and we hope this helps you launch safer, more secure production apps! Go check out the new editor in the data browser, and as always, let us know what you think!