Hello,
My situation is very simple. I have backend jobs writing data to Backendless and I have a web app displaying the data to everyone, no log in required. Both read and write are through the Backendless REST api. However, if I have the REST secret key in the JavaScript, then malicious can see it and destroy my data. Currently, I had to setup a proxy server, write some code, add the secret key before proxy the request to Backendless, and only allow ‘GET’ operation.
This sort of works, but now my pure client side web app is tied to my proxy service. I have to keep that proxy service up and running at all time. I wonder if there is a read only REST key that I can use, so I can easily avoid this problem.
Thank you very much!
Hi Gordon,
This problem can be solved with security Roles. Your backendless backend comes with a security role for each API key. The roles are automatically assigned based on the key used by the calling program. For example, if your code uses CodeRunner Key, the ServerCodeUser is assigned to the request. If it REST key, then the RestUser role is assigned. Each role can be configured with global and table-level permissions. The global permissions are managed in the Users > Security&Restrictions screen. Click any of the roles there and you can control permissions globally (they apply to all tables, files, messaging channels, etc). To control access to individual tables, go to the Data screen, select a table and click the “Table Schema and Permissions” button. Then click to the “Roles Permissions” item and you can assign permissions for various operations to the roles for that specific table.
Hope this helps.
Regards,
Mark
Hi Mark,
My backend job is also communicating with Backendless using http REST. I tried to use the CodeRunner key as the ‘secret-key’ in the header of my http REST call. It did not work. I got the following error:
Version is disabled or provided wrong application info (application id or secret key)
So I need multiple REST keys that all works over http REST. I want them to be tied to different security Roles.
Thank you very much!
–Gordon
Hi Gordon,
Is your backend job running in Backendless?
Regards,
Mark
No. It is some existing python script. Running inside a docker on cloud.docker.com which start the docker on an Microsoft Azure machine…
It’s complicated. So it used to save the end result in Parse through http REST api.
So I guess this becomes a feature request. I want to create REST api keys with specific permissions.
Consider creating a special user for your Python code. The user would be special in the sense that you would assign permissions to various tables in order to allow operations for your backend job. Your Python code can login as that user and thus would have the permissions to perform required operations.
Ah, that is a legit workaround. We probably eventually have to deal with user anyway, so why not start now.
Hi Mark,
I need a little more help.
After I login with a special user, I still have to send my request using http REST. I still have to use the REST key, right? Won’t that restrict my access to read only again (assuming I already made the RestUser role to be readonly)? Or should the RestUser still be very powerful but somehow there is a way to make the special user owns all the tables, so any other request not logged in will not be able to modify anything.
Can you walk me through what should I do?
–Gordon
Hi Gordon,
Once you login the user, you will need to make sure you send the user-token assigned to the session and the REST Key. The general security rule is if an operation is not allowed for a role or a user account, it will be rejected by Backendless. Suppose user A has roles AuthenticatedUser and RestUser and the RestUser role is denied access to operation FIND, then all find operations by user A will be rejected.
Regards,
Mark
I think I found it. On the table schema and permission page. The check mark can be clicked 2 times to become a cross marking meaning reject. It is greyed out when nothing is specified which seems to be equivalent to granted which is confusing to me.
Now I’m very confused. http://support.backendless.com/public/attachments/d362642dc87119766fca5dc164c618a4.jpg</img>
http://support.backendless.com/public/attachments/3b45d0b5148f9d9b7ae9eaddf8dda64c.jpg</img>
Will this work?
Could you describe your confusion with words? (in addition to pictures…)
So all my communications to Backendless are through http REST. So I have to give RestUser permission to everything. Then the user can delete stuff without login…
What is the difference between a greyed out check mark vs a green check mark on the permission table?
So I have to give RestUser permission to everything. Then the user can delete stuff without login......
If the NonAuthenticatedUser role does not have permission to delete, then a user without login will not be able to do that.
A greyed out check mark indicated that the permission is inherited (for users from roles, for roles from the global permissions).
I see. I need to specifically set NO to the NonAuthenticatedUser row like this.http://support.backendless.com/public/attachments/0bb4135da12c8d2e8f5b0ca166e6d7ce.jpg</img>
Thank you very much for your help! Though I would say if we can generate multiple REST keys that ties to different roles, it would have been easier.
For your $10,000 we can get it done by tomorrow… ))
I’ll only ask for $9900
Even then I can’t deliver by tomorrow. I have to study your code first for a day. So deliver the day after tomorrow.
Thanks again for your help. I’ll be playing with user permissions for a while.