I am trying to delete an entity in afterCreate event handler (in case some post-processing logic produced an error, I need to rollback the creation). However, I get the following error: “User has no permission to delete elements from persistence storage.”
I have granted all permissions to AuthenticatedUser for this table ![]()
http://support.backendless.com/public/attachments/5f129d78e53285c86b1c8b5d7376edb3.png</img>And I am able to see following user roles in afterCreate event handler:
[
“RestUser”,
“TM_71A5C48D-361D-755F-FF57-B35E28DD3200”,
“AuthenticatedUser”
]
What may be the reason?
Hello, Kateryna!
What is the setting for “ServerCodeUser” role?
Also try to grant access for “NotAuthenticatedUser” and notify us about result.
Thank you.
Alex
For “ServerCodeUser” all actions are allowed.
After granting permissions to “NotAuthenticatedUser” deletion works, but I don’t want to allow unauthenticated users to delete entities in this table.
What language are you using for servercode?
Ok, I’ve got it.
The problem is that JS coderunner doesn’t use parent request context for inner requests. So all requests from the inside are made by “NotAuth ServerCode” user until “login” is called directly in the servercode. This logic would be changed in the future. However, Java coderunner saves the context.
For now you can use a few workarounds:
- Grant “remove” operation for “NotAuthenticated” and “ServerCodeUser” roles and deny for all other roles. This way only requests made from coderunner would pass. However, all other clients requests and requests from authenticated users would be rejected.
- Make “login” call directly in the “afterCreate” handler before “remove” method invocation. This way you’ll set context for “remove” request and it would pass.
- Use Java coderunner for now. As I said before, it saves request context.
Could you explain how option 1 works, because I thought that if I grant permissions to 2 different roles, it means that one or another role can perform the action. So if I grant delete permission to “NotAuthenticated” and “ServerCodeUser”, it means that “NotAuthenticated” should be able to delete. However, it works as you described: no users (authenticated or not) are able to delete, while deletion from business logic works.
Take a look at my last comment in this topic: http://support.backendless.com/t/clarification-on-data-permission-system
Please do not hesitate to ask if something stays unclear.
O_O
You should definitely have this as a diagram somewhere in the documentation.
Do I understand correctly, that if I deny delete permission to all roles except “NotAuthenticated” and “ServerCodeUser”, then not authenticated user, who performs request from a client, won’t be able to delete the entry, because there is an additional client role he has (like “JSUser” from js app)?
Yes, almost right. I just can add that permissions for “NotAuth” and “ServerCode” roles should be exactly “grant”, not “inherited grant”.
Each request has at least 2 roles in context: auth | not-auth role, and “client-type” role like “JS”, “Android” etc. And that’s the trick - if at least one of these roles is “denied” - request would be rejected.
I see, thank you for the explanation.
