Hey
i’m having to make 2x the methods because of how security rules work.
wanting only the server code user to have access to the data just like in this Article.
now when a logged-in user make a call to any of my codeless methods he have no access to do any data. so i’m forced to make a “dummy” method for almost all my methods and make the user call the dummy method so i can set the user-token to null and pass the user-token as a parameter to the method and do overhead work to check for the user identity in the method…
so i can not use the built in context block such as the user id one after the dummy method.
this is painful do deal with as my project grow. and increasing my API calls.
i’m requesting that you guys find a way to all us developers to ignore the authenticated user rule just like you did with the not-authenticated user rule
Business logic is the only exception to the rule for assigning NotAuthenticatedUser and AuthenticatedUser roles. When business logic makes an API call and there is no authenticated user in the context of the call, Backendless assigns only the ServerCodeUser role. Otherwise, if there is an authenticated user, then both ServerCodeUser and AuthenticatedUser roles are assigned to the request.
I guess I didn’t understand the most important part, which is this:
Could you please explain why the user has no access?
when a logged-in user make a request to any method he will have the AuthenticatedUser rule.
and backendless will block the access since only ServerCodeUser have the access.
How did you configure access to your database? What roles are allowed and rejected? Please be specific.
As i said only the ServerCodeUser have access… what is not specific about this 
all the other roles are not authorized to access the database
Why don’t you grant access to authenticated users?
i don’t want the users to access the data directly. i want any access or modification to be from the methods and services using codeless.
So you want the API invocations done by Codeless to maintain the identity of the user that called the business logic. Basically, the calls by Codeless should look to Backendless exactly as the calls as if the user called them directly. Is that correct?
No
i want the users to be able to access codeless logic for security and maintain data integrity.
so the user identity is needed in all cases but even if the user have the authorized user role he can not communicate with the data table directly.
so i want the user to communicate with codeless and codeless logic make the changes to the database
Let me approach this differently then. What would be the change you’d like to see to make your job easier? What is it Codeless doesn’t do now or what’s missing?
I guess the easiest solution for any request that originate using codeless user role to ignore the authorized user role if it present.
or a block that will make any action inside of it to have only the ServerCodeUser role.
What this means is any API request sent from Codeless in your case should have only the ServerCodeUser role. All other roles associated with the user who made the request into business logic, should be disregarded. I think we can do that, it means though that the user identity (user-token) will not be sent by Codeless to Backendless (when that option is enabled).
1 Like
Great!
it will be the developer responsibility in codeless logic to set the owner of the object when needed
Hello @mohammad_altoiher
Correct me if I am wrong
- you want to prevent any direct API calls from your app to Backendless Services such as Data, Users, Files, etc. and force it to use your API Services
- you want that inside API Services (BL) all the API to Backendless goes without user-token which the API Service was invoked with, right?
If so, it’s not quite right, because lots of our customers rely on this behaviour and changing this user-token policy might break thousands of apps. Keeping a chain of API calls with the same user-token is one of the most important things and in most cases it helpful when developers set up their permissions based on Owner Policy.
In your case, I can propose a new solution:
- we will add new Codeless blocks to control the current user-token (BKNDLSS-21703), which will give you a possibility to reset the current user-token in the top of your logic and all the next API call will go as from not authenticated user
please let us know if it suits you
Regards, Vlad
Hi @vladimir-upirov
Yes this will do the trick if the result will have the server code user role.