Page 1 of 1412345...10...Last »

Feature 23: Block access to all data for the “guest” users

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.

When an application makes an API call by a “guest” user, meaning a user who has not logged in, Backendless associates the user in that session with the NotAuthenticatedUser role. It is a built-in or system role and every Backendless application automatically includes it. You can see that role in the Applications Roles section located in the Users > Security & Restrictions screen of Backendless console.

When you click the NotAuthenticatedUser role, the console displays global security role matrix. To disable access for all operations for the non-authenticated users, click every green checkmark until the screen looks as shown below:

As a result of the changes described above, all API operations made by anonymous users will be rejected by Backendless. It is that easy.


Feature 22: Loading related data objects – the ‘one-step/dynamic’ approach

In my previous post I described how to load complex data objects from the persistent storage using the “auto-load” technique. Using that approach a developer can statically identify specific (child) properties which should be returned along with the parent object(s) when a client app sends a request to load them. That approach works well for object relations which must be unconditionally returned with the parent object. However, there are many scenarios when the client app must control which relations should be preloaded and returned along with the parent.  The API described below allows to accomplish that.

Consider the following example which uses the client-side code generated by Backendless based on the database schema. In that schema the Restaurant table has the “locations” column which represents a one-to-many relationship between the Restaurant and Locations table. This means that a restaurant may have several related locations as shown in the screenshots below:

The restaurant objects:

The related location object for the “Cantina Laredo” restaurant:

Synchronous API (Plain Java only):

Asynchronous API (Android and Plain Java):

Notice the addRelated method on the QueryOptions class. The method requests that the data objects referenced by “locations” column must be initialized and returned with the every parent Restaurant object. The printLocations method displays the loaded Locations objects:

The code above produces the following output. Notice that the “Cantina Laredo” restaurant is fetched with the related location:

See the documentation for more information on loading related objects with the “one-step” approach.


Feature 21: Loading related data objects – the ‘auto-load’ approach

Previously I wrote a post on how to retrieve data objects from Backendless. The code in the article loads a collection of the Restaurant objects and although it does not show it, the related collection of the Location objects arrives un-initialized. That is the default behavior of Backendless when it comes to loading related objects. The code below demonstrates that the collection is indeed empty (null). (The code in these examples is from the article describing how to generate client-side code based on data tables).

Method to print out related locations:

Asynchronous example (Android and plain Java):

Synchronous example (plain Java):

The code output:

There are several approaches for loading related objects for a parent entity. This post reviews one of them – the ‘auto-load’ option. This option is available in Backendless console. The screenshot below shows the Restaurant table. Notice the ‘auto load’ checkbox in the “owner” and “locations” columns:

When the checkbox is selected, Backendless automatically includes the related objects for the column into the response. If you select the auto-load checkbox for the “locations” column and re-run the code above, you will get the following output:

As you can see from the output, the related location for the “Cantina Laredo” restaurant has been loaded without making any changes to the code. All it took is the selected checkbox in the console.


Feature 20: Developer-defined roles – an essential block to securing your app data

In a Backendless backend you can restrict access to API operations and/or application data. A restriction may apply either to specific users or to roles. When a restriction applies to a role, it automatically applies to the users in that role. For example, suppose you have two roles in a job-searching application – employer and job-candidate. Each role will have a certain set of permissions, for instance an employer can see all the candidates who applied for a job.

Backendless supports two types of roles – system-defined and developer-defined roles. System roles automatically come with the backend, Backendless assigns them based on how user logs in or accesses the app. For example, the AuthenticatedUser role is assigned to any users who successfully logs in.

The greatest flexibility in tuning security for an app comes in the form of developer-defined roles. A custom role can be assigned to users based on business rules of your app and have a completely unique set of permissions. These permission may restrict API operations and limit access to app data – data objects, files, geo points and media streams. To create a developer-defined role:

  1. Login to Backendless console, select your app and click the Users icon.
  2. Click the Security and Restrictions menu.
  3. Click the Add Role button In the Application Roles section.
  4. Enter the role name and click the Save button.

Once the role is created, you click the role name to see the global permission matrix (which is a feature on its own and will be discussed separately):

There are many way roles can be used and this feature-a-day series will be discussing them in detail. To see all the security-related features, follow the security tag in the blog.



Feature 19: Handling user logins with the same user credentials

It is a common use-case when two or more users try (or need) to login to an application using the same userid and password combination. Some application allow it (for example Netflix supports concurrent logins with the same credentials from different devices) and other apps restrict it. With Backendless you can easily configure your backend to support either way of handling multiple logins without writing a single line of code. To configure the multiple login policy:

  1. Login to Backendless console, select your app and click the Users icon.
  2. Click the Login menu.
  3. The Enable Multiple Login section is responsible for configuring your backend’s concurrent login policy (for the users who use the same login credentials).

Allowing users of your app to login with the same userid/password:

  1. Click the Enable Multiple Logins toggle to set it to the ON state.
  2. Enter the number of concurrent users into the Maximum number of simultaneous logins for an account text field. This is how many users can login at the same time using the same user/password. Essentially this is how many concurrent user sessions with for the same user account Backendless will allow for your app.

Disable concurrent user sessions for the same user account:

  1. Click the Enable Multiple Logins toggle to set it to the OFF state.
  2. Ignore the Maximum number of simultaneous logins for an account text field.
  3. Make a selection between the First user and Second user radio buttons. If you select First user, then Backendless will terminate the session which was already there any time another user logs in with the same credentials. If you select Second user, then only one user per account will be able to login. Any time a second user tries to login using the same credentials, Backendless will block that login.
Page 1 of 1412345...10...Last »