Page security (for a specific role)

Explore the methods of securing your pages and specific components.

After reading this article, you’ll know the following:

• Choosing authentication profiles to view a page

• How to secure your page for a specific role

• Setting the role-based access to specific components and functions

Ensuring data security and user access control is important for any organization. Whether it’s an internal or publicly available application, builders must ensure that some specific data and functionality are locked for certain types of users. In this article, we’ll dive into the practical approaches to securing your application pages, including authentication profiles, role-based access, and conditional components.

Internal authentication vs username/password authentication

An authentication profile determines which entity will be used to validate users accessing protected pages in an application. Users must provide unique identifiers like email and password that match the authentication model’s records to log in successfully.

Our platform has a couple of options to choose from:

• Betty Blocks account login is a default internal authentication method for only users with valid Betty Blocks accounts, and it comes out of the box. This method is mostly applicable to administrators and builders

• Username/password is created with a User model by default, and it is primarily used to authenticate users of a particular application

• Additionally, you can set up a custom authentication which is mainly used for single sign-on flows. More about these methods can be found in this article

You can view authentication as the highest level of security of your application. When you create a new page, select first the type of the page (authenticated or public), and then (if the first type is chosen), you can select an authentication profile that you want this page to belong to. As you can see, Betty Blocks account login is the default one. You can select another option and create a new authentication profile straight from this configuration window.

Once a page is created, you can choose an authentication profile for it at any time. Open the page via the page builder then go to the settings tab at the top of the builder bar. Scroll down to the bottom of the page, press Authentication profiles, and follow the same steps as explained in the previous paragraph.

To access the additional settings for authentication profiles, navigate to Tools > Authentication profiles. Here, you can choose the default authentication profile, designate the login page for a specific profile, and adjust other advanced settings.

Roles and permissions

Roles and permissions play a huge role in your page and application security on different levels. To protect data on the page for specific user actions (like create, edit, delete, etc.), you have to make sure you know what roles are going to be created within an application.

Go to Tools > Roles and permissions. Here you can create new roles for your application and enable permissions to access data models for them. Also, you can apply filter rules for accessing a specific model.

As you can see, only Read permissions are assigned to models in the Roles and permissions overview. This is because the remaining permissions are accessible through the action builder. Roles and permissions are applied to various actions, ranging from the basic create or update record to complex action flows involving AI steps.

Let’s try it out in the example. We’ll open an action with the create record step and get to the action settings in the top right corner of the builder. Then we go to the Permissions tab to view the available options. Here you can:

• Toggle the action as private (untoggled automatically becomes public)

• Select an authentication profile for this action - unauthenticated users will be asked to log in first to proceed with the action

Enable certain roles to perform the action in the Permissions tab:

If you’re interested in managing roles on the organizational level, check this document.

Securing a component

So far, it should be clear how to secure your pages with authentication and setting roles and permissions, but what if you want to make only certain components available for certain roles and make them invisible to others?

Well, there is a trick for such a case which includes using a conditional component along with a data container.

Hiding a button

Let’s see how to secure a specific component for authenticated users. This is our homepage with a button to the Employee overview page. To ensure only authenticated users (those with a Betty Blocks account) can access it, simply make the Employee overview page authenticated. Users without a Betty Blocks account will be redirected to the login page automatically.

But if you want to hide it from one role (e.g. user), while enabling another (e.g. admin) to see it, there is a scenario for that.

This use-case example is based on the start-from-scratch application which already has the User management page prepared (read more about it here). From this page, we can add new users and assign roles to them that will be stored in the User and Role models.

 

1. The first thing we need to do is save the information about our user and its role without creating a ‘many to many’ relation between the User and Role models (that isn’t available at the moment). Go to your User model and create a new text (single line) property, let’s call it ‘user_concat’.

2. Then go to the ‘update user’ action of your application (Page action: User management > update user, by default) and add the expression step before the update record step.

• Type in the expression: ""

• Then add the variable (e.g. Role) and set its value to roles variable

• Fill in the name for the result variable, and leave its type as Text

3. Open the update record step from the same action. Add the user_concat property and set its value to the result variable from the expression step (e.g. secured_role).

4. Now let's return to the page builder and our page. Pick up the data container component and drop it beside the button you want to hide (Employee overview in our case):

• Choose the Logged in user option and the corresponding authentication profile. We chose the default Betty Blocks account.

5. Grab a conditional component and drop it onto the data container, then take the button and drop it on top of the conditional. Navigate back to the conditional and let’s set it up:

• Select User. user_concat property as the right value

• Pick the ‘Contains’ as the compare function

• Type in ‘1’ as a left value.

Number ‘1’ stands for the admin due to concatenation. Accordingly ‘2’ will be user’s.

Testing the page

It’s time to test our use case. Compile your page and try viewing it as both admin and user.

Here we go. As you can see, the button’s visibility now only depends on whether one is logged in as an admin or user.

Note: In case you failed to complete a similar use case, we highly recommend checking the ‘update user’ action with the log message step as shown below: