Also try to check what set of roles your user have in CodeRunner before you make api requests.
Well from what I can tell from your previous comments the when a custom event is sent by a user the coderunner will inherit those roles when it sends a request. This causes a permission error when I try and save data from a handler but no error when I try to save from for example my bootstrap. So I’d like to remove the assigned roles/user when the event is fired.
Ok, I see. No, you cannot remove these roles.
Please, tell me what is the handler you’re working at? Is it a handler for any operation, or for a custom event?
I’m currently focused on a custom event, it’s used to manage an object without any direct modification of an object by a user.
And how do you invoke this event? I mean whether it’s invoked by authenticated user or not.
The event is invoked by an authenticated user using the Java library.
As I understand, inside handler you call “save” method to some table, and you want to deny access to this table for all other requests?
Exactly. I’d like to avoid using a custom handler to achieve this if possible.
If you use custom handler - then implement the following settings for target table:
- grant access for “ServerCodeUser” and “AuthenticatedUser” roles
- leave “inherited” state for all custom roles
- deny access for all other roles
Finally, you should get something like this: https://monosnap.com/file/YXULTUPi5i8ezAx90geJbF5po17wmz
If you don’t use custom handler, and “save” requests would be executed by Android Authenticated users without any custom roles - then the settings would be like this: https://monosnap.com/file/I2TQVWX9dfdGPgV7aP3uHs8cQ7yztc
And if you want to allow only requests executed by “AdminUser”, set the following: https://monosnap.com/file/TwUyTy7POjaCkZWc2E4DECC1tL8ygA
I think I understand I just want to confirm, does the Auth/NotAuth role take priority over the device type role? For example, if the AuthenticatedUser role was allowed to create and update objects but the AndroidDevice wasn’t, the AndroidDevice would take priority and the action would be denied?
No, its not absolutely correct.
The truth is that higher priority has the role that “denies” operation.
These roles are on the same level, they both are “System”. But for your case higher priority has “AndroidUser” role because it denies operation.
On the other hand, if “AuthUser” is denied and “AndroidUser” is granted - then higher priority would have “AuthUser” because it denies operation.
But if the client has any custom roles - for example, “Admin” - then, if its not in “inherited” state, it would override permission for any of “system” roles.
Alright, the other clarification would be in regards to permission inheritance, when I leave a permission grayed out does that mean it will inherit global permissions, or will it inherit the other permissions on that object?
So if I had the following setup: http://i.imgur.com/RmO6gQB.png
Would a user with the custom role I’ve highlighted running on an Android device be denied action or would they inherit global permissions and be allowed.
“Inherited” is the default permissions state and it means that it’s inherited from the previous level. Here is a sample: permission on object ACL level for AndroidUser role is inherited from permission on table level for AndroidUser. And permission on table level inherits permission from global level.
When making decision about allowing access, Backendless server treats “inherited” state as “not set”.
Let me show you one more example. Lets say that you have an object with name “Bobby” in table “Person”. And client sends a request to update “Bobby”. Now server should find out if the client has corresponding permission, and here is how it’s done:
- Check Object ACL permissions for “Bobby”. If all permissions are “inherited” - go to step 2. If any permission (either for user/his system role/his custom role) is “Granted” (not “inherited granted”!) - then allow access. If any permission is “Denied” and all other are “inherited” - reject request.
- Check users permission for table “Person”. If there is no user (request is being made by not-authenticated user), or permission for this user is “inherited” - go to step 3. If permission for this user is “Granted” - allow access. If permission for this user is “Denied” - reject request.
- Check custom roles permissions for table “Person”. If user doesn’t have custom roles, or permission is “inherited” for all his custom roles - go to step 4. If permission is “Denied” for any custom role - reject request. In all other cases - allow access.
- Check owner policy permissions for table “Person”. If permission is “inherited” - go to step 5. If user is the object “Bobby” owner and the permission is “Granted” - allow access. If user is the object “Bobby” owner and the permission is “Deny” - reject request.
- Check system roles permissions for table “Person”. If permission is “inherited” for all system roles - go to step 6. If permission is “Denied” for any system role - reject request. In all other cases - allow access.
- Check global permissions for custom roles. If any of them is “Denied” - reject request. If all of them are “Granted” - allow access and do not check next level. If user doesn’t have custom roles - go to step 7.
- Check global permissions for system roles. If any of them is “Denied” - reject request. If all of them are “Granted” - allow access.