Security and User Roles¶
Application's user accounts can be mapped to roles using the API documented below. A Backendless backend contains some system roles and may include developer-defined roles. There several system roles available in all Backendless backends. These roles are automatically assigned to every user under various conditions. Each role can configured with global, container and asset permissions.
Core security roles are assigned based on user authentication status and whether the user logged in via "classic" backendless login or through a social network. These roles are:
Security Role |
Assigned to user when an API request is made by: |
---|---|
NotAuthenticatedUser |
...a user who is not logged in. |
AuthenticatedUser |
...a user who is logged in. |
SocialUser |
...a user who is logged in via a social network (Facebook, Twitter, Google) |
FacebookUser |
...a user who is logged in via Facebook |
GooglePlusUser |
...a user who is logged in via Google |
TwitterUser |
...a user who is logged in via Twitter |
Additionally the following roles are automatically assigned by Backendless to an API request when a corresponding secret API key is used. By configuring access permissions to these roles an application may allow to custom server-side code (ServerCodeUser
role), but completely reject access to the client apps (all other roles).
Security Role |
Role is assigned when API uses secret key: |
---|---|
ASUser |
ActionScript secret key |
AndroidUser |
Android secret key |
DotNetUser |
.NET secret key |
IOSUser |
iOS secret key |
JSUser |
JavaScript secret key |
RestUser |
REST secret key |
ServerCodeUser |
CodeRunner secret key |
Backendless assigns multiple security roles for the same API request. For example, an API request made from a JavaScript application where user is not logged will have the following roles assigned: NotAuthenticatedUser
and JSUser.
When an API call originates from business logic (Java, JS or Codeless), Backendless assigns the ServerCodeUser
role.
Important
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.
Adding Roles¶
A developer-defined role can be added using Backendless Console:
- Login to Console and select an application.
- Click the Users icon.
- Click the Security and Permissions section.
- Click the Add Role button and enter a name for the role.
- Click OK to save the role.
Role Permissions¶
A role may have multiple permissions assigned to it. A permission may either allow (GRANT) or reject (DENY) an API operation. Every operation which can be restricted with a permission has a subject. For example, the subject of a Data Service operation is a data record. For the File Service operations, the subject is a file.
All permissions are organized into a hierarchy: The global permissions apply to everything in the system. They either allow (GRANT) or reject (DENY) an API operation without distinguishing the subject. For example, a global permission may reject the Data Service's find
operations for the users in the NotAuthenticatedRole
. As a result, any not-authenticated user will not be able to retrieve an object from any data table in the application.
The asset container permissions inherit from the global ones and apply to a specific asset container, such as a data table. These permissions are scoped to a specific container type. For example, you may reject the get
operation on file directory /privatefiles/
for the users in role X. As a result, any user who belongs to the role X will not be able to retrieve files from that directory.
Finally, the asset permissions inherit from the ones for the corresponding asset container (if they are available) or from the global set. For example, an asset permission may reject access to a specific data object for one role and grant access to the same object for another role.
The diagram below illustrates the permissions inheritance ladder:
Once a role is assigned to a user account, any permissions assigned to the role (either granting or denying an API operation) automatically apply to the operations executed by the application on behalf of the user.
Retrieving Available User Roles¶
This operation returns a list of the roles associated with the user account currently logged in to the Backendless application. If the request is sent without logging in, the system will return only one role - NotAuthenticatedUser
.
Method:
¶
Future<List<String>> Backendless.userService.getUserRoles();
Example¶
Before retrieving the user roles, log in as described in the Login section. Then, retrieve the user roles as follows:
//login user
Backendless.userService.login("username@foo.com", "secretpassword").then((backendlessUser) {
// user has been logged in. Get user roles.
Backendless.userService.getUserRoles().then((userRoles) {
//here we get all user roles - "userRoles".
});
});
Retrieving Users By Role¶
This operation works only with custom roles, otherwise an error message will be returned in response body. By invoking the getUsersByRole
method, a client sends a request to the server which returns a response body with an array of users found by a specific role.
Non-Blocking API
Backendless.userService.findByRole(roleName,
{bool? loadRoles, DataQueryBuilder? queryBuilder})
where
Argument | Description |
---|---|
roleName |
is a string name of a particular role. |
loadRoles |
is an optional boolean parameter. When set to true , each user in a returned value will have a list of roles associated with that user account. |
query |
an optional parameter that can be a plain object or an instance of Backendless.DataQueryBuilder . The returned list of users will satisfy the query. |
Here is a detailed explanation of the parameters that can be used in the query
object:
where
Argument | Description |
---|---|
pageSize |
sets the page size - which is the number of objects to return in the response. Maximum value is 100. |
offset |
sets the offset - an index in the server-side storage from where the data objects should be retrieved. |
properties |
sets the names of the properties which values must be retrieved from the server. |
excludeProps |
column names that should be excluded from a query. |
where |
sets a search query. A query must be in the SQL-92 syntax (the "where" clause part). |
having |
used with Aggregate Functions. Sets a condition on a aggregate function to filter groups. |
sortBy |
sets an array of column names to sort the data objects in the response by. |
groupBy |
used with Aggregate Functions. Sets the name of a column to group the results by. |
relations |
sets an array of related columns names. Objects from the related columns are included into the response. |
relationsDepth |
sets the number of "levels" in the hierarchy of related objects to include into the response. |
relationsPageSize |
A number of relation objects returned in response body. |
fileReferencePrefix |
when FILE_REFERENCE column is in the table, then fileReferencePrefix can be used to change the initial link to a file. For instance, a user can replace the current base path, to their custom domain where a file is stored, without updating any data in the table. |
Example¶
Backendless.userService.findByRole(roleName, loadRoles: true, queryBuilder: myQueryBuilder)
.then((value) => print(value))
.catchError((error)=> print(error));
Retrieving User Roles By User ID¶
This method can be used both for custom and system roles and returns an array of all available user roles.
Assigning a Role to a User¶
This operation is available only from Custom Business Logic. Applications must use the "Code Runner API key" in order for the API call to be accepted on the server. The reason for this restriction is that a malicious use of this API can easily compromise application's security. As a result, this API must be used from a controlled environment.
Unassigning a Role from a User¶
This operation is available only from Custom Business Logic. Applications must use the "Code Runner API key" in order for the API call to be accepted on the server. The reason for this restriction is that a malicious use of this API can easily compromise application's security. As a result, this API must be used from a controlled environment.
Errors¶
The following errors may occur during the API calls described above. See the Error Handling section for details on how to retrieve the error code when the server returns an error.
Error Code |
Description |
---|---|
2002 |
Version is disabled or provided wrong application info (application id or secret key) |
2005 |
Could not find role. |
3038 |
One of the required parameters (user identity or roleName) is null. |
3057 |
Could not find user by id or identity. |
3058 |
Could not assign role to user. |
3059 |
Could not unassign role to user. |