You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: _includes/common/security.md
+37Lines changed: 37 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -394,6 +394,43 @@ Pointer permissions are like virtual ACLs. They don't appear in the ACL column,
394
394
395
395
Note that this ACL is not actually created on each object. Any existing ACLs will not be modified when you add or remove pointer permissions, and any user attempting to interact with an object can only interact with the object if both the virtual ACL created by the pointer permissions, and the real ACL already on the object allow the interaction. For this reason, it can sometimes be confusing to combine pointer permissions and ACLs, so we recommend using pointer permissions for classes that don't have many ACLs set. Fortunately, it's easy to remove pointer permissions if you later decide to use Cloud Code or ACLs to secure your app.
Starting version 2.3.0, parse-server introduces a new Class Level Permission `requiresAuthentication`.
400
+
This CLP prevents any non authenticated user from performing the action protected by the CLP.
401
+
402
+
For example, you want to allow your **authenticated users** to `find` and `get``Announcement`'s from your application and your **admin role** to have all privileged, you would set the CLP:
403
+
404
+
```
405
+
// POST http://my-parse-server.com/schemas/Announcement
406
+
// Set the X-Parse-Application-Id and X-Parse-Master-Key header
407
+
// body:
408
+
{
409
+
classLevelPermissions:
410
+
{
411
+
"find": {
412
+
"requireAuthentication": true,
413
+
"role:admin": true
414
+
},
415
+
"get": {
416
+
"requireAuthentication": true,
417
+
"role:admin": true
418
+
},
419
+
"create": { "role:admin": true },
420
+
"update": { "role:admin": true },
421
+
"delete": { "role:admin": true },
422
+
}
423
+
}
424
+
```
425
+
426
+
Effects:
427
+
428
+
- Non authenticated users won't be able to do anything.
429
+
- Authenticated users (any user with a valid sessionToken) will be able to read all the objects in that class
430
+
- Users belonging to the admin role, will be able to perform all operations.
431
+
432
+
:warning: Note that this is in no way securing your content, if you allow anyone to login to your server, every client will still be able to query this object.
433
+
397
434
### CLP and ACL interaction
398
435
399
436
Class-Level Permissions (CLPs) and Access Control Lists (ACLs) are both powerful tools for securing your app, but they don't always interact exactly how you might expect. They actually represent two separate layers of security that each request has to pass through to return the correct information or make the intended change. These layers, one at the class level, and one at the object level, are shown below. A request must pass through BOTH layers of checks in order to be authorized. Note that despite acting similarly to ACLs, [Pointer Permissions](#security-pointer-permissions) are a type of class level permission, so a request must pass the pointer permission check in order to pass the CLP check.
0 commit comments