Today we’re going to take another look at security configurations in Backendless. In this article, we will talk about how to restrict direct access to your data via API and only expose your custom API endpoints. This does not mean you should use some other set of “admin” APIs for data management. Instead, it is accomplished by setting up proper security settings.
Backendless provides ways to set up really granular permissions for your resources, including even row-level security in your data tables. But for this task, we’re only going to need system roles and global permissions. Thus, it won’t require you to do a lot of configurations or create additional assets, such as custom roles.
One of the final steps before you release an app is to setup proper security. Specifically, the security of your File Storage is perhaps the most important since it may contain your business logic code, your public website data, your logs, and any other assets which you probably do not want anyone from the outside to be able to see. This post will provide a few guidelines on how to structure your File Storage with security in mind and instructions on how to set up the permissions properly. The sample use-case will be a bit over-concerned with security, so you most likely won’t need all of this for your specific case, but you’ll be aware of what to do in the worst case.
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.