Security plays an important part in releasing an app on Parse, and Access Control Lists (ACLs) are one of the most powerful ways to secure your app. As Bryan mentioned in part III of his security series, “If you have a production app and you aren’t using ACLs, you’re almost certainly doing it wrong.” In that blog post he examines how to create and save ACLs in code. Another effective way to create and manage ACLs is through the data browser, and today that is much easier with a new and improved ACL editor. The data browser is already one of our most popular and most frequently used tools, and now you can also use the data browser to easily edit and manage your app’s ACLs.
An ACL is essentially a list of users that are allowed to read or write a Parse object. For example, let’s say your social networking app has a
Post object, and you want the user who created that post,
jack, to be the only person who can see it. You would then create an ACL on that object and give Jack read permissions. By default, ACLs are public read and write, so to add an ACL on Jack, first uncheck public read and write, and then type Jack’s username into the ACL editor. Each step is shown in the new editor, along with the equivalent code in iOS.
PFUser *jack =
[PFUser currentUser]; // username
PFObject *post = [PFObject objectWithClassName:@"Post"];
PFACL *acl = [PFACL ACL];
[acl setReadAccess:true forUser:jack];
Now Jack’s post is private, and Jack is the only one who can see it. But nobody has write permissions on the object, so its fields can only be changed by using the master key. What if Jack wants to edit his post? To allow this, you need to give Jack write permissions in the object’s ACL.
[acl setWriteAccess:true forUser:jack];
Now Jack can both see and edit his Post object. But what if Jack wants to share his Post with his friend
jill? Right now Jack is the only user with read or write permissions on the object. You want to allow Jill to be able to see the post, but you don’t want her to be able to edit it. Therefore you need to add read permissions for Jill on the ACL.
PFUser *jill; // username "jill"
[acl setReadAccess:true forUser:jill];
Jack and Jill can see the post now, and Jack is the only person who can edit it. But maybe you want to be able to make sure the content of Jack’s post is appropriate, and so you want a group of administrators to be able to see the post, and to delete it if something is wrong with it. Once you’ve assigned these users to a Role named
admin, you could add permissions on that role to the ACL. Given that delete is included in “write” permissions, you would check both read and write in the ACL editor.
What if Jack wants to publish his post publicly? Now you want to give the post public read permissions. Simply check the read checkbox in the public permissions row at the top of the editor, and anyone can now see the post.
Notice that all of the users and roles in the ACL now have read permissions checked automatically. That is because you have enabled public read, so anybody can read Jack’s post. But public write is still disabled, so the only users who can edit the post are Jack and all users that belong to the
admin role. Click “Save ACL” and now your post object will have all of these permissions set, summarized in its cell by “Public Read, 1 Role, 2 Users”.
post.ACL = acl;
An undefined ACL acts the same as an ACL with public read and write permissions enabled, so when you first click on a cell without an ACL defined, the editor will show the public read and write boxes checked. To add private permissions on a role or user, you must first uncheck public read and/or write.