Page security (for specific users & roles)

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.

Authentication types & page setup

An authentication profile determines which entity will be used to validate users accessing protected pages in an application. Users must provide unique identifiers, usually 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 used to authenticate end-users of a particular application. Usually, that's the Webuser profile in pre-made Betty application templates

• 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 for your application. When you create a new page, first select 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, the 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 on the top right of the builder. Scroll down to the bottom of the page, press Authentication profiles, and select the profile you need. 

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 / Update / Delete record, 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 Actions. Roles and permissions are applied to various actions, ranging from the basic Create or Update Record steps to complex action flows involving public action steps from Block Store.

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:

When setting up the login flow for your application, make sure you have chosen the right authentication profile via the Authenticate User action step: 

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

Securing a page (for one or more in-app roles)

When a page isn’t available for users with a specific authentication profile (that is configured for each page individually), they can be redirected to predefined error pages, such as Error 404 (Not Found) or Error 403 (Unauthorized). However, you can configure only one global error page for the entire application via Application settings:

If you want only users with specific in-app roles under the same authentication profile to access a page and its data—while redirecting all others to a different page (for example, an Error 403 Unauthorized page)—you’ll need to use a slightly different configuration. 

Let’s take our application, where we have three main roles: admin, client and employee. We want: 

• admins and employees to be able to make reservations (not clients) and have access to the Back office page with the Reservations model
• when users with a client role try to reach the Back office - Reservations, they are to be redirected not to the Error 404 page but to the Home page instead. 

Configuration

1. Drag a Data Container to your page. In this dialog box, select the option to ‘Add without configuration’ and click Save.

2. Click on the Data Container and in Model options, select the ‘Role’ model

• Configure it so the left side value is Role.WebUser.id and it equals the current user's WebUser.id.

• Add a new group
• Add a new rule inside the group, select Roles.Name property equals ‘role name’ (e.g. admin)
• Press Save

If the page needs to support multiple roles, add another rule in the group and set the same rule as above, but change the role name to the second role that should have access (e.g., employee)

In such a case, make sure the OR is selected on the right side option!

• Select a page to redirect to; it’s common to create an Error 403 (not authenticated) page to redirect users to in this case

• Expand Advanced options and make sure ‘Only render children when data is present’ is on - this ensures content will not load before the security check is completed.

5. Now comes moving the Data Container into the right spot.

• Open the Component tree tab
• Find your nested Data Containers
• Drag the top Data Container to the very top of the tree
• Now drag the top (parent) page element (which is often a Row or Box component) underneath the nested Data Container (so that it becomes a parent component to the rest of page elements)

This might take a couple of tries to get them in the right place. For pages using the 'Back office' page template (just like in our example), the page must be unlocked first to enable editing the overview section, then create the data containers and drag them under the "Overview + Record View" instead of the top of the tree. 

If everything is configured correctly, users who log in with the Webuser authentication method and have the in-application role 'client' won’t be able to access this page; instead, they’ll be redirected to the Error 403 page.

Securing a component

So far, it should be clear how to secure your pages with authentication and set 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.

However, 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 Webuser 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 Webser and Role models (that isn’t available at the moment). Go to your Webuser 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 as an example

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.