Skip to main content

Access Control

Our built-in access control allows your application to specify which forms may be executed by a certain user. We implement a Role-Based Access Control (RBAC) strategy with minimal configuration required.

Roles​

A Role may be seen as a tag or attribute to group users. Roles are managed from both our Cloud Console and our local editor. Once created, their names cannot be changed.

Users​

Users have three authorization levels within our Control Model: they might be anonymous, signed-up, or role-granted users.

  • Anonymous users are those who may interact with your forms but haven't yet verified their email, either through the get_user function or our Access Control system.

  • Signed up users are those whose emails are associated with the given project via the users table in our Cloud Console.

  • Role-granted users have at least one role associated with them. All role-granted users are also signed-up users.

In our model, a signed-up user functions as if they had an implicit "default" role in your system.

Users may sign-up for your project in two ways: manually by the project administrator using our Cloud Console or automatically if your project allows self-sign-up.

Self-Sign-Up Policy​

Your project may specify which users may sign-up without manual operations from an administrator. The variations may range from not allowing any self-sign-up (the default behavior) and requiring all users to be manually signed up from our Cloud Console, allowing self-sign-ups only if the verified user email matches a certain domain (i.e., people from *@abstra.app or *@mycompany.com), or allowing any person with access to your project to sign-up.

Security Levels​

Each view of your project will correspond to one of three levels of security.

Public​

When a person accesses a link associated with a public view, its code is executed without any checks on our side. "Public" doesn't imply being unprotected, as you may implement security verifications in your code using the get_user function or an SMS confirmation code strategy managed by you.

"Public" is the default security level for forms once they are created.

Requires Sign-Up​

Views that require the user to be authenticated and associated with the project to proceed. When anonymous users access a protected page, they are redirected to email authentication. It is during this phase where the email is checked against the self-sign-up policy to determine if the user may or may not be associated with your project.

By default, the kanban view requires sign-up.

Requires Roles​

To access these views, the user must be signed up and have a specific role previously associated with the view.

Test Users​

To facilitate a better development experience, you may register some users in your local editor. These users do not communicate with your production environment and are meant only to ensure locally that the configuration fits what you envisioned before deploying your project.

info

This experience diverges from what happens with Roles: creating a Role from your local editor will be reflected in the Cloud Console.

Since roles are used both in the user management done in the Cloud Console and in the security level management done in the local editor, we decided that their creation should be allowed in both systems.

For security reasons, we only allow Role deletion from the Cloud Console.