In various methods, we have used REST blocks to write to the database, the reason being that we want to trigger event handlers. It is our understanding that if we use the cloud code Update blocks, event handlers are not triggered.
In order to improve our security, we have added system users and added a method that logs in a system user before each REST block is called. This has allowed us to eliminate the NotAuthenticatedUser permission.
The logic currently is as follows:
- we first get the system user from a table that contains user name and userToken
- we check if the user token is valid
- if not, we log in the user and save the user token to the DB
- we construct our HTTP request and sendit.
This works but it is consuming a lot of API calls.
As of now, we have 4 System(Admin) users. Each System User are used for one purpose.
- System User - Creating data [POST REST BLOCK]
- SystemGet User - Retrieving data [GET REST BLOCK]
- SystemPut User - Updating data [PUT REST BLOCK]
- SystemDelete User - Deleting data [DELETE REST BLOCK]
Is it not a best practice to be using REST blocks and logging them in with system users?
Is there a better way to ensure all REST blocks have an authenticated user role?
Is there generally a better way to do this? Thanks
1 Like
Hello @Andreas_Marinopoulos,
I can suggest creating a separate custom API Key and using it without user authorization.
The protection mechanism is the same as for the Cloud Code API Key - it’s etter not to use it on the client side. But since it will only be used it inside the services API, and won’t be used on the client side, it will be safe.
Regards,
Olha
But this means we will need to reenable NotAuthenticatedUser?
Hi @Andreas_Marinopoulos,
no, you don’t have to reenable NotAuthenticatedUser.
You just need to grant explicit (green checkmarks, not grey) permissions for the role that is created along with your custom API Key.
@stanislaw.grin we are doing something wrong I think. Trying to replicate your example but we are not getting the data
Custom role created and granted explicit permissions:
Getting data returns an empty list:
As soon as we log in, we get the full list:
@Andreas_Marinopoulos ,
Sorry for misguiding you.
I will give you a short explanation first about how security for system roles works so you will understand situation better.
Permission based on system roles is calculated using “and” logical operator. It means that if for some of the roles associated with a request “deny” permission is set, the result for request will be also “deny” even if for other roles “grant” was set explicitly.
“NotAuthenticatedUser” role is bound for any request made with any API key except “CloudCode” API key. Exception for “CloudCode” API key was made only because it should be used for “CloudCode” logic which ensures that you have full control over execution flow and none will be able to mess around with malicious API calls.
Now to the point of your problem.
As I understood only your “CloudCode” service are allowed to write to specific set of tables and you do not write to those tables directly via Data API. If that is correct then you should set “deny” for create/update/delete operations for each of your API keys except of that custom API key which you will use for modification (and CloudCode if you want to modify data using it) for each of those tables. At the same time you should remove explicit “deny” from “NotAuthenticatedUser” role - it should have or explicit or inherited “grant”.
With such configuration you will be able to write to each of those tables only with your custom API key but read with any API key.
If you want also to forbid reading operations for all other API keys then you can do it in the same way as you did for create/update/delete operations.
Could you please write me back if I correctly understood your problem and if this solution will work for your case?
Regards, Andriy
Hi Andriy,
I am a bit confused, maybe it is best to use a fictional example?
I currently have table A.
If I use CloudCode” API key, I can use Logic blocks to read/create/update/delete.
I have also created a Custom API key. I wish to read/create/update/delete with Custom API key.
I wish to forbid read/create/update/delete with any other API key.
Is this possible? What would be the correct configuration?
@Andreas_Marinopoulos ,
Yes, this is possible. Your permissions configuration will look in the next way
As you can see on the screenshot, permissions for all API key related roles (except for CloudCode and Custom API keys) were set to “deny” for the table A.
With this configuration only CloudCode and Custom API keys will be able to read/create/update/delete data in the table A.
Regards, Andriy
So does this mean we need to complete these settings for each and every table? Is there maybe a global setup where we can set the global security roles accordingly?
I understand NotAuthenticatedUser needs to be allowed in this case, but since you are setting deny for all API key related roles except Cloudcode and Custom, it is still secure?
@Andreas_Marinopoulos ,
So does this mean we need to complete these settings for each and every table? Is there maybe a global setup where we can set the global security roles accordingly?
In case if all your tables should be modified only via Custom or CloudCode API keys you can set “deny” permission for API key related roles globally in “Users” > “Security Roles”. But by doing this you will also forbid registration under those API keys.
I understand NotAuthenticatedUser needs to be allowed in this case, but since you are setting deny for all API key related roles except Cloudcode and Custom, it is still secure?
As I understand, both, Custom and CloudCode, API keys will be used only in your CloudCode services. In this case, as long as nobody knows them, it is safe to use them in such way since all API calls with them will come from CloudCode and there is no way to find their values from the client program.
Regards, Andriy
