Skip to main content

User login

Bobuild lets you protect your app, or parts of it, with user logins. The mechanism is very flexible and can be adapted to any need.

The basic idea is that users are just normal records of an object that you decide to use for authentication. So, suppose you have an object called "Customers" and you want to allow your customers to access a reserved area, you'll just need to configure that. At the same time, you might want to allow your employees to access a backoffice area: for that, you'll just use a different object (for instance, you might want to call it "Operator"). This mechanism is very flexible because it does not enforce any specific object or role system to be used, and you can configure everything to fit your needs.

Several authentication methods are available:

  • e-mail + password
  • e-mail + magic link sent via e-mail (available soon)
  • Google SSO
  • SPID (available on request)

Login can be enabled for each top-level page (we also call them portals, or sections), which means that you can have different authentication methods for different parts of your app.

Example

In this example, the app contains three portals:

  • a backoffice portal, which is protected by a login based on the Operator object
  • a customer portal, which is protected by a login based on the Customer object and also allows self-service registration
  • a public section, which is not protected by any login

How to set up login​

Open the top-level page you want to protect. You'll notice a "Public" badge in the top bar, which means that the page and its sub-pages are currently not protected by any login:

Clicking on it will bring you to the login settings:

Here you can choose the object to use for user authentication. If the object you intend to use is not listed in the dropdown, make sure it has an e-mail field and a password field.

After selecting an object, the e-mail + password login will be enabled and you can proceed to refine its configuration if needed.

Setting roles and authorizations​

The login mechanism is very flexible and allows you to restrict which users can access which pages. For instance, you might only allow customers to access your portal if they are marked as "active", or you might want to allow only certain employees to access a specific area of your backoffice.

In order to do this, you can set rules like this:

Another way to use rules is to create a "roles" field in your user object, whose type is "Multiple Choice". This way you can attach multiple tags to each user representing their authorizations, and use them in the login rules like this:

Self-service registration and password reset​

If you want to let your users create their account, you can enable self-service registration. This will add a "Register" button to the login page, linked to a specific sub-page that you can freely customize adding a form widget that collects user's data and creates a new record in the user object.

Here are some good ideas to consider when enabling self-service registration:

  • Consider sending an e-mail confirmation to the user after registration. This is easily done by configuring a "Send e-mail" task in the registration form.
  • Consider enabling password reset using the built-in functionality, so that users can recover their password if they forget it.
  • If you want to review and approve new users before they can access the app, create a boolean field named "Active" in your user object (or, alternatively, in case you want to handle multiple statuses, a choice field named "User Status"), and leave it to a default value when users register. Then, in your backoffice portal, create a grid widget to list all users needing approval. Then, configure the login rules to allow access only to users with "Active" set to true as described above.
Example

Single-Sign On with Google​

A very convenient way to authenticate your users is to use Google SSO. This allows users to log in to your app using their Google account, without having to remember yet another password. This is not only convenient for external users, but also for your internal users as you'll rely on Google credentials security, including Two-Factor Authentication.

In order to configure the Google login, you'll need to tell Bobuild how the Google user data relates to your user object fields. This is needed for multiple reasons:

  • to find the user in your app if already present (Google user ID and/or e-mail address will be used as search criteria)
  • to create a new user if not present yet (Google user ID, e-mail address and name will be used to populate the new record)

It is usually enough to map the e-mail field, which will identify the user uniquely. Google user ID and name are optional; if you don't map them, they will be ignored.

Example

SPID​

Bobuild is compatible with the Italian public digital identity, using the metadata and certificate provided by the customer in order to provide a seamless login experience. If you need to enable SPID login, please contact us.

Other login mechanisms​

If you have other needs, please contact us as we have a development roadmap that may fit your needs.