I’m just starting testing backendless and have some questions that I can’t find answers to. Hopefully you can help.
Background: everything is http rest api calls and I’m using backendless cloud. Permissions are currently enabled for everything while initially testing.
api-key does not appear to be enforced. I am calling [myappsubdomain].backendless.app/api/users/login with only email/password and it processes the login without needing the api key. The documentation says the api-key needs sent, but it isn’t needed for this, so I’m puzzled about what needs it?
I have some questions about roles and want to make sure that I understand. First, I do not want any access for unauthenticated users. Does the built-in user login/registration system work correctly if NotAuthenticatedUser is set to Deny All? And if the Rest role has some permissions, would those be added or does not authenticated supersede everything else?
I only want users to have access to their own records. I see that ownerID is automatically created on tables. Do the Owner Policy settings on the table supersede the role permissions? Does this just require the user token sent in the headers? In other words: if I deny all to authenticated and rest users but add owner policy permissions to each table and send the user token in the headers, does this accomplish the permissions how I am thinking it will?
Does the auto-generated OwnerID field replace the need to traditionally add a userID field for the relationship between a user table and data linked to that user? I just want to make sure it can be used in the same way… eg. get all records from table X where ownerID = Y.
On a POST to add a record, does the system add this ownerid automatically when user-token is sent or does ownerID need sent directly?
api-key does not appear to be enforced. I am calling [myappsubdomain].backendless.app/api/users/login with only email/password and it processes the login without needing the api key. The documentation says the api-key needs sent, but it isn’t needed for this, so I’m puzzled about what needs it?
If you use custom domain, that must works without api key.
I have some questions about roles and want to make sure that I understand. First, I do not want any access for unauthenticated users. Does the built-in user login/registration system work correctly if NotAuthenticatedUser is set to Deny All? And if the Rest role has some permissions, would those be added or does not authenticated supersede everything else?
Here is good answer from my colleague.
I only want users to have access to their own records. I see that ownerID is automatically created on tables. Do the Owner Policy settings on the table supersede the role permissions? Does this just require the user token sent in the headers? In other words: if I deny all to authenticated and rest users but add owner policy permissions to each table and send the user token in the headers, does this accomplish the permissions how I am thinking it will?
Does the auto-generated OwnerID field replace the need to traditionally add a userID field for the relationship between a user table and data linked to that user? I just want to make sure it can be used in the same way… eg. get all records from table X where ownerID = Y
Yes, you could simply test it with SQL search or Rest Console in Data Management section
On a POST to add a record, does the system add this ownerid automatically when user-token is sent or does ownerID need sent directly?
I’m still confused by how the permissions should be setup to allow new user registration but lock down other things. I guess I can create a dedicated user to login as that has necessary permissions to create new users - as opposed to just allowing permission for anyone using the rest api.
But what user does the email link confirmation run as? I have tried granting create/update/retrieve permissions for the servercode role on the user table but still get a permissions error when clicking the link.
{"code":4000,"message":"User has no permissions for specified resource","errorData":{}}
The user is registered using one of the keys (Rest, Android etc.), this will be the first role for the user to receive the registration confirmation link. The second role will be “NonAuthenticatedUser”, because the user is not logged in.
When the user confirms the registration, a page will open with a message stating that their registration was successful. The page is in files, which means that File Permissions work here. So, “read” permissions for these two roles need to be configured for the web/system folder.
Thanks for the info. I am using rest and this is how I had expected it to work, but a prior response (below) told me the rest API key was not used when using the dedicated url. (My app is ultramilk.backendless.app).
So my security dilemma is that it seems the rest permissions need read/write for the user table to be able to register a user. But without requiring the api key, anyone with the url alone would be able to write to the user db via rest. Am I missing something with this?
api-key does not appear to be enforced. I am calling [myappsubdomain].backendless.app/api/users/login with only email/password and it processes the login without needing the api key. The documentation says the api-key needs sent, but it isn’t needed for this, so I’m puzzled about what needs it?
If you use custom domain, that must works without api key.
So my security dilemma is that it seems the rest permissions need read/write for the user table
it should be enough only write permission
anyone with the url alone would be able to write to the user db via rest
If you want anyone to be able to register then anyone should be able to write to the user table. But it is ok, because he writes only data that he owns, and has no access to other data.
If you use custom domain, that must works without api key.
under the hood backendless always ties domain and API key. You can choose another API key for the domain under Manage->Custom Domains section. Also you are able to crate your own API key, wich will have higher priority than the system keys in the permission hierarchy, because the custom key will be tied with the custom role.
