Subscribe rss
Blog categories

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:

  • a user
  • a role
  • all users
  • all roles

The general API usage pattern is:

Where <OPERATION> can be FIND , UPDATE , REMOVE. There are many more methods available on the <OPERATION> class supporting all the combinations listed above.
Continue reading

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:

  1. Login to Backendless console, select your app and click the Data icon.
  2. Select the table to get to the data object you need to modify the ACL of.
  3. Click the “key” icon in the ACL column:
  4. Select Users Permissions or Roles Permissions In the ACL screen.
  5. Adjust the permissions for the roles and/or users as you see fit. A permission can be adjusted by clicking an icon at the intersection of a row representing user or role and a column which represents an operation. For example the following screenshot restricts access to an object for any not-authenticated user and does not allow users in the Customer role to delete the object:

Previously I wrote about how to store and retrieve objects to and from server-side in-memory cache. Quite often when working with cache, it is required to check if an object already exists in cache. Backendless provides an API for that function. The code below checks if an object exists in cache, if not, it places it in there and then runs the existence check again:

Continue reading
Posted in Feature-a-Day

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:

Continue reading

Previously I wrote about enabling email address confirmation for the app users after they register and before the login. The feature sends out an email with a link a user must click in order to confirm his/her email address. The text of the email can be easily customized:

  1. Login to Backendless console, select your app and click the Users icon.
  2. Click the Email Templates menu and select Confirmation template from the drop-down menu.
  3. The console displays email text editor:
  4. Continue reading

Once a user of a Backendless-powered app logs in, a session is established. The session has an inactivity timeout that is reset with every new API call made within the session. The default timeout value is 3600 seconds (1 hour). It means Backendless will keep a session alive 1 hour after the most recent API request. The inactivity timeout value is configurable in Backendless console:

The Enable Session Timeout configuration is located under Users > Login. The default setting if the configuration property is OFF. In that case, the inactivity timeout is set to 3600 as described above. To change the setting, enter a timeout value in the inactivity timeout textbox and click the toggle to set it to the ON state. The maximum allowed value is 30 days, which is 2592000 seconds.

In addition to the app development APIs, we also make available a very rich set of administrative and management functions. Every single feature available in Backendless console, is also available via specialized REST API. Whether it is performing a data import/export, setting up database schema or retrieving application’s analytics – all of these can be done with a REST call. These APIs are available for any customer who upgrades to Backendless Plus or the Cloud Enterprise plans. When you decide to upgrade, contact us and request your Admin API manual.

Continue reading

Posted in Feature-a-Day

Previously I wrote how to change user’s password using Backendless console. Additionally, there are ways to change user’s password using the API. In this post I review the API which can be used to change the password IF a user can login. A different scenario is possible when a user cannot login for the reason that he/she forgot the password. That scenario will be reviewed in a separate post.

Continue reading

Backendless supports two ways for deleting a user: using the API or using the console. The API approach is described using the code below. The code retrieves a user object by ID and then subsequently deletes it:

Continue reading

In my post yesterday I wrote about support for multiple environments for your apps’ mBaaS backend. These could include development, testing, staging and/or production. As backend advances through its stages, an obvious question is how to migrate the backend’s data from one environment to another. Backendless provides a very advanced facility for backend migration between the environments. Take a look at the following interface:

Continue reading

Posted in Feature-a-Day