In my studies at Parse Server I intend to set up the following scenario.
I have the class of “announcements” made by users where only he himself will be able to read and write the records.
However, I need to create an administrator where I will have Read and Write permission as well.
Would that be a “Role”?
That is, I have to create a “role” with the name “administrator” and in this rule put the ObjectId of users who are administrators.
And in the records of the class “ads” the ACL have I maintain that only the owner will have the right to Read and Write and the “role” administrator will also be able to read and write?
In other words, when I am logged in as an administrator, I will have access to all “ads” classes.
Parse iself has the masterKey-concept, where whenever that is available - e.g. in the dashboard - a lot of other checks are ignored, including ACL. If you only have a single user (like yourself), you can use that system.
Yes.
Parse also has the nifty class-based ACL. If you have a field for the user, you can configure the class to only allow access to the user in that field (e.g. an “owner”-field) as well as a global group. That’s only if you want a single group with access to all items. If, instead, there are adminnistrators per item, then it must be configured on the ACL-field for each item, yes.
@gnunicorn , I did a test now and it doesn’t seem to work …
When setting “Edit Class Level Permissions” to “role” administrator, the user does not see the documents, only if they have been set in the registry.
Did I do something bad or does this class rule not work?
author is the field pointing to whoever created the item. admins then is a role that I put my system-wide admins in. The per-item ACL does not restrict my objects.
The ACL that you have in place does not give read/write permission to the admin role and that’s why the admin can’t see the objects. In order to get permission to a certain object, both CLP and ACL rules must allow. See more details here: JavaScript Developers Guide | Parse
@davimacedo , as I understand it in the link you sent me, even if the CLP allows it if the ACL does not allow it, I will not be able to read the document, right?
I understand, so I will have to change my strategy. My SDK Flutter does not allow recording a document as a “role”, in this case I will have to create a class where I will list the administrator users and create a function in the cloud to list the documents if the user is on that list as an administrator.
But my suggestion is: If the CLP is at a higher hierarchical level, it should allow consultation regardless of the ACL.
as @davimacedo said before, and the visualisation shows pretty nicely in the link I shared before, each one acts as a level of denier, it doesn’t overwrite the deny of the other:
Does your object have a field to the user direclty? Like I showed before with the author? Then you could configure the class-level to allow for the value of said field and the admin-role and have the ACL for each row as public-read-write-allowed-ACL. The class level permissions would then prevent any non-admin user-not-the-field to see them, even though they are, on the individual level, not restricted.
