In my previous post I described how to adjust object’s access control list (ACL) using Backendless console. As I mentioned, in addition to console, object’s permissions can be controlled using API. In fact, for any persisted object, Backendless supports the following capabilities:
granting/rejecting permission to execute find/save/update/delete operation on an object to:
The general API usage pattern is:
DataPermission.<OPERATON>.grantForUser( userObjectId, dataObject )
DataPermission.<OPERATON>.denyForAllRoles( dataObject )
Every data objects saved in Backendless has its own access control list (ACL). Object’s ACL includes permissions for users and roles for all Data service operations. Using ACL an application may be configured to allow users (and/or roles they belong to) to be able to execute Data Service API calls. For example, in a shopping app you may have the Customer and SupportRep roles. Users in the Customer role may have the permission to create and update objects in the Incident table, but may not delete them. A user in the SupportRep role may have the permission to delete those objects.
Object ACL configuration can be done via API or Backendless console. This post review the latter. To get to the ACL screen for a specific object:
This may apply only to some apps, especially if your license agreement explicitly prohibits users from specific countries, or if perhaps you want to allow users only from a specific country. The feature lets you select the countries where users would not be allowed to consume the backend of your app. The feature relies on geo-decoding user’s IP address and we do our best to maintain the mapping between the IP addresses and the countries they are assigned to. If a country is selected as one where the APIs for your app should not be allowed, then any request a user from that country makes would be rejected. To configure geography-based restrictions:
In the previous post I described how to obtain file’s public URL using the Backendless developer console. Even though one may obtain a public URL for a file or directory, it is very easy to change the permissions to restrict file download for anonymous (not authenticated) users. To restrict access:
A user on StackOverflow asked how to load only the data which belongs to the currently logged in user. Although if you read the question it may sound like something else, this is how I understood it. This is indeed an interesting and very common use-case. Backendless (IMHO) handles it beautifully and this feature certainly deserves a place in this feature-a-day series.
What you need to know before we get to the coding sample part is:
Loading data objects which belong to a user does not require any specialized APIs. In fact exactly the same Backendless API you’d use to load objects from the server should be used. The trick is in setting up the security policy to restrict users from accessing data objects and letting Backendless to fall back to what we call the Owner Policy.
The use-case for updating a user account is rather frequent. Either the user herself or the admin may need to update user properties. Backendless provides the API for updating user accounts, although app admins/developers can do it using Backendless console as well. The code below demonstrates the API for updating a user:
It has happened to a lot of people, especially with the online banking applications – you try logging in a couple of times and get your password wrong. Then the screen changes saying the account is locked out and you need to try again in XX minutes. If this is the behavior you would like your app to have, it could not be easier to set up with Backendless:
Can you think of an easier way to configure it? ) Enjoy!
In my previous posts I wrote how to create developer-defined security roles and how to secure data table access for a security role. Ultimately when a client application makes API requests, the security evolves around users, since it is a user who authenticates himself against the system. A user may have roles assigned to him or her and in that case any permissions granted (or denied) to a role would be applicable to the user as well. In this article I will review how to assign roles to users using Backendless console. Keep in mind that these assignments can also be done using API and I will be writing another article in this series on that feature as well.
The instructions below assume you already have some users registered for your app or created using console. Also, you need to have at least one custom security role. To assign roles to users:
The same User Role Management popup can be used to edit role to user assignments. The dialog is smart enough to handle multiple user selection and will properly display conflicting assignments using the three-state checkbox.
In one of my previous posts I described how to restrict access to all data for “guest” users. The Backendless security model lets you control access to data tables, or more generally “asset containers”, at the role and operation levels. That means an application developer can set up security restrictions for API operations on a specific data table for a security role. For example, a job/resume search application may have two application roles: Employer and JobSeeker. Suppose there is a table called JobListing which contains job listing objects submitted by the users in the Employer role. Actions permitted on the table for the JobSeeker role may look like these:
Applications use the Backendless API to access data, run searches, store, update and delete objects in the database. When a user authenticates himself with the backend, all subsequent API calls are executed on the behalf of the logged in user. However, if an API call is made without an authenticated user in the session, it is associated with an anonymous user. As a result, in an application that does not restrict data access, the data is exposed to everyone.
Restricting access for anonymous (non-authenticated) users is a very straight-forward process. Application developer has multiple options ranging from denying access globally for all API calls to restriction at the data table-level or even at the specific object level. In this article I review the process for restricting access globally.