0
votes

I'm using the parse REST API.

I need to setup so that for any requests made:

1) only logged in/authenticated users can Read or Write. 2) users can only access/modify records they own.

My current implementation:

1) using the Application key + REST API key. 2) sending request to user login endpoint, on success returning the user data including the session token

for 2), I'm not doing anything with the session token yet.

I understand that parse has:

1) class based permissions 2) object-level permissions (ACL's)

With Read and Write access on the class level, and by simply using the Application Key + REST API Keys, anyone with these two keys can access that class (ofcourse, the Master Key has even more "power").

I want to simply say that they can Read and Write on the class level, if they're logged in/authenticated. And when they Read, Update or Delete, they can only do so if they're owner of the object.

I assume that session token will play a role in the logged in part, and ownership is defined by object-level ACL

Is this correct and how to roughly set this scenario up in parse?

It's not clear to me in the REST API how to handle this (what I think is a common) type of scenario.

Thanks for any feedback

1

1 Answers

0
votes
{"ACL":{"$CURRENT_USER":{"read":true,"write":true}}}

above in acl column will mean at the security level, only the creator has RW permissions. No other user can see these records with this ACL attr value regardless of their access on the CLASS level.

OR

you control the accessor predicates in your app. So you can add a column = 'createdBY' of type pointer_to_class_User.

Any queries just contain predicate ..

'where={"createdBy":{"__type":"Pointer","className":"User","objectId":"$CURRENT_USER"}}'

which enforces ( outside row security level ) idea of only getting result sets containing rows for the current-user.

all depends on how you want to use the security layer.

I would do it using the predicates and resort to the ACL only where you may have stuff like SSN's or Salary where as a policy you dont what general read permissions.