As discussed, I have shown you on the chat and you can now replicate.
As it stands any user that registers for a backendless app is automatically created as the ownerid for that object.
That user assuming they have an owner policy of update can bypass the Custom Key role permissions and update their object.
Layer two is before the Owner policy.
We investigated this issue further. The reason you’re seeing this behavior is that the roles associated with API keys (such as the TippleUserRole) are handled as system-defined roles and thus are placed at level 7, which is below Owner Policy. The actual problem is that the documentation does not reflect that and I am scheduling an internal ticket to fix that.
In order to achieve the behavior you’re after, you should create a user-defined role, assign it to the user (either in console or via API) and customize the permissions for that role.
Thanks Mark, that now stops the user from being to update directly via the REST console/postman.
The problem I have now is that the user calls a custom api command in business logic, this command does some logic to check that the user can be admin, then tries to set the user property admin to true, it now comes back saying 400 - User has no permission to update entity (1012)
The Server code user has full perms:
Make sure the Admin role has explicit grant permissions for the table where you make the changes. If it is still the Users table, I see that the Admin role has no explicit permissions there. Keep validating against the list below on this page. It is by far the most important piece of information when it comes to security tiers in Backendless:
How does the Admin role fit in here? Are you suggesting login as a user with Admin role set on cloud code to execute the update on the user that’s called the API command? I’ve explicitly set the role to have grant on the table.
The list from the page you references states 4.Table Permissions for the user-defined roles - this we have just set to have deny on update.
The only way I can think is that we somehow tag the user with the admin role when we want to do the update… InvocationContext.setUserRoles("Admin");
This isn’t probably the right way to do it/it doesn’t work.
I want to stop users being able to update their objects directly if they get hold off the app id and key the app is using to communicate with backendless. - This has been done now that we have added a custom role ‘TEST’ that blocks this.
I want the user to be able to call the Business Logic Cloud Code API Endpoint ‘updateUserSetAdmin’ which will process some logic to and make sure the user calling can be an admin, if the logic succeeds then it simply updates the users admin flag to true. Business Cloud code logic for updating object:
The problem we have now is that the user is assigned to role ‘TEST’ and we get an error back saying doesn’t have permission to update object, when the above business logic cloud code executes.
Are you suggesting that in the logic we add the user to the ‘Admin’ role, make the change, then remove the user from the ‘Admin’ role.
There must be an easier way of doing this? I’d expect the backend cloud code to be able to do what it wants regardless of the user calling the endpoint. I think I asked earlier, is there a way to just forget that a user is calling the endpoint so we can do all the processing.
Mark my friend, you are a genius, this solves all the issues. Here’s me worrying I would need to find a new backend provider.
Definitely worth documenting this somewhere as I can imagine there are a large amount of insecure backendless apps around.