Hello, @Inna_Shkolnaya !
Do you have any updates on this?
In other words, I want to allow executing all available API (e.g. DB queries) in CloudCode functions when a client (“Customer” role) triggers the implemented service methods.
And this is only the way the customer should has access to (using implemented REST API in the CloudCode).
Thanks!
@mark-piller, hello!
Could you take a look at this please?: Run the cloud code on behalf of ServerCodeUser - #18 by Boris_Velvetech
I believe, your set up was working because of the internal logic (there are no restaurants for some users based on the internal BL)
My last example is the simple service, querying the table from the DB. And I can’t configure the settings, where the result returns on behalf of the “Customer” role through the custom service API (CloudCode), but returns nothing via the direct DB access.
Thanks!
Hi, @vladimir-upirov,
I have already tried such configuration multiple times.
In that case, both: direct API and CloudeCode return empty response.
What is the user context on your third screenshot? Is it the same with the user you denied access on “User Permission” tab?
Thanks.
Hello @Boris_Velvetech,
Firstly, please restrict the CloudCode API key usage. It should be used only for the Business Logic calls, it’s not public and it’s not secured when users have access to it.
Secondly, please take a look at the permissions priority. The DENIED permission for the user is stronger than the ACCESS for the API key.
Maybe this article also could be useful.
Regards,
Olha
Hi @olhadanylova,
Your response doesn’t cover my question. I want to implement the Business Logic using ClodeCode only. Imagine, we have a “general” and simple web application with backend (node.js/.net core/spring/etc) and the frontend part (angular/vue/react). The server side has access to any resources like DB/Queue instance/File storage. I agree, that access can be restricted via additional validators/hosting configuration and so on. But the frontend part can’t query the DB directly, right? How to replicate the same logic?
I want to allow for my frontend executing of the API implemented in a custom service, and that API should be able to query the DB or the file storage under ther hood. But if I deny access for some role, my cloude code can’t retrieve a response from the DB because of the custom role context.
The article you provided is what I was starting from. Please review my first comment in the ticket: Run the cloud code on behalf of ServerCodeUser
And that article suggests to hack the SDK to not send the user token, that smells bad:
This said, depending on the SDK you use, you can hack it to not send the user-token from the specific call in Cloud Code and thus the flow will become the same as in the case described above. And if you use REST API to make calls from Cloud Code, it’s even simpler — just do not send the user-token header.
How to identify a user if the frontend doesn’t send a token? Why do I need to “hack” the SDK if I want to reach the most basic behaviour?
Thanks!
Hello, @olhadanylova!
Is my previous comment clear? Do you have any solutions except suggested in the article?
Thanks!
Hello Boris,
I will try to figure out the question and answer you tomorrow during the working day.
Thank you for your patience!
Regards,
Stanislaw
Thank you,
I will be waiting for your response!
Hello @Boris_Velvetech,
I have invited you to my app:
https://develop.backendless.com/app/PermissionsDemo
There I tried to configure what you are trying to achieve.
There are table Restaurants with a few objects in it.
There is one user (customer@test.com, password: secret).
There is a custom role Customer assigned to that user.
There is a second user (not-customer@test.com, password: secret), without any custom role.
There is an API Service that retrieves the records from the Restaurants table.
Please note that the permissions for the service itself have also been configured (in addition to the global and table permissions).
Please play around with it and let me know if this is what you are looking for, and if not - what is not working as you would expect in this app.
Thank you!
Regards,
Stanislaw
Thank you for the demo!
I will definitely review your example on Monday.
I briefly look at the settings on the table level.
Is that correct, that you denied permission at the role level:
but grant access for the particular user (i.e. we will need to grant access through the code for every created user):
Thanks!
Is that correct, that you denied permission at the role level, but grant access for the particular user (i.e. we will need to grant access through the code for every created user)
No, I didn’t change user permissions at all (and you will not need to).
The gray colors of X/V mean that permission is inherited (it’s not set explicitly, but inherits parent configuration).
In this case it shows Grant Inherited (gray checkmark) because I have set Explicit Grant (green checkmark) for the Authenticated Role (which all users obviously belong to):
Hi, @stanislaw.grin!
I just tried to replicate the settings in my project.
The strange thing relates to ServerCodeUser in the “Roles Permission” tab. When the “Retrieve” operation for that role is Gray Grant, the response from the “Rest” console is empty. When I set Explicit Grant, it works as expected. What is the difference between Grey Grant and Green Grant checkmarks? (except the inheritance). I believe there should be no difference when a permission inherits parent grant or set it manually.
How to have Green Grant by default then?
By the way, in your project you set Green Grant also. I didn’t change anything in your project, but I’m pretty sure, that the response would have the empty response if you reset the permission for that role (make it Grey Grant).
Thanks.
Hello!
Do you have any updates on that? I temporary set the green checkmark for every existing table in the project, but such a solution is not reliable.
Thanks.
the difference between grey and green is only inheritance between layers. So if you have a grey checkmark, then you actually do not have permission on the current layer. All layers are described in the following doc
For example, you always have permission on the global layer
They never can be grey.
If you go to the specific table role permission and change permission for the created role you will change Table permissions for the user-defined roles. If you edit the system role then it will be Table permissions for system-level roles layer
Hello, @sergey.kuk!
Thank you for the reply. Unfortunetly, my question is still uncovered.
Please take a look at the Demo application provided by your colleague:
https://develop.backendless.com/app/PermissionsDemo
When the ServerCodeUser has explicit green checkmark in Roles Permissions tab at the specific table, the response in Rest Console is expected for the logged-in user with the custom role:
But if I reset permissions in that tab for ServerCodeUser, the checkmark is grey, and the response is empty (ServerCodeUser can’t retrieve data from the DB):
It is annoying to set explicit green checkmark for every table in my app. Even more, I should not to forget to do that when a new table is created. Or I can reset permissions and have to recall about setting explicit green checkmark for ServerCodeUser after that.
The question is how to configure settings to have Green permission on that level by default?
Thank you!
Hello @Boris_Velvetech
Unfortunately, it is impossible to do so. If the permission is inherited (grey check mark), you will have conflicting permissions for the two roles - Customer and ServerCode User. And because there is a deny for the Customer role, the response will be empty. To prioritize the permission for the ServerCodeUser role, you will need to set the Green permission.
Regards,
Inna
Backendless newbie here. I believe I’m trying to do something similar and the solution to hacking the user token ended up being to add this line at the beginning of my cloud code handler before accessing the database.
Backendless.setCurrentUserToken(“”);
Context: I’m writing a high score leaderboard for a game. The clients will submit scores which are processed and put on the leaderboard by cloud code but I don’t want the clients to be able to write to the leaderboard directly.
I set my data ROLES PERMISSIONS to DENY ALL (all X’s), reset ServerCodeUser so that it allows all, and added RETRIEVE permission back to all roles.
Paired with setting the current user token to empty string that seems to do the trick.
BTW today is my first day of using Backendless and I’m very impressed! It’s very full-featured and easy to use. Kudos to the team on making a great product!
1 Like