Une gestion des utilisateurs native mais sans permissions
Chaque application Bubble dispose par défaut d’une gestion des utilisateurs. Cela se traduit concrètement par une table Users et la mise à disposition de fonctions telles que
When current user is logged in ainsi que toutes les actions permettant de créer des comptes utilisateur.
Il est souvent nécessaire d’avoir différents types d’utilisateurs avec des autorisations différentes. Par exemple, on peut avoir besoin d’utilisateurs avancés ou “admin” par opposition aux utilisateurs sans autorisations particulière. Un autre cas de figure est une différenciation par métier dans une application d’entreprise. En informatique, on parle souvent de rôle ou bien de groupes.
La gestion des rôles n’est pas native dans Bubble, probablement pour offrir un maximum de liberté aux concepteurs d’application. Nous allons voir ici comment implémenter facilement un système de rôles / permissions dans une application Bubble.
Les Option sets
Les Option sets sont des constantes définies au niveau de l’application (onglet Data) et facilement utilisables dans les workflows et dans les conditions. C’est ici que nous allons définir et stocker les rôles et permissions de notre application.
⚠️ Les Option Sets ne sont pas modifiables à l’intérieur de l’application. En pratique, cela veut dire qu’il sera possible au sein de l’application de paramétrer les rôles des utilisateurs, mais il ne sera pas possible de créer un nouveau rôle par exemple.
⚠️ Les Option Sets sont visibles publiquement sur l’application. Ce n’est pas une faille de sécurité en soit, mais il faut en avoir conscience.
Dans certains cas d’usage, les Option sets peuvent donc ne pas être la meilleure solution pour implémenter les rôles et permissions des utilisateurs. Les différentes logiques ci-dessous peuvent tout-à-fait être implémentées sur des Data Types plutôt que des Option Sets.
Table des rôles
On crée donc un “set” d’options appelé Role dans lequel on crée deux entrées : Admin et User. On modifie également le type User
pour ajouter une attribut Role permettant d’affecter un rôle à chaque utilisateur.
Cela permettra d’écrire des conditions telles que
When Current user's Role is Admin afin de gérer la visibilité des composants de l’application, ainsi que les conditions d’exécution des Workflows.
ℹ Dans le nom des options il est possible d’utiliser des émojis pour améliorer le confort visuel (ici ronds blanc et rouge).
Permissions associées aux rôles
Une bonne pratique consiste à rendre facilement paramétrable les différentes permissions de l’application. Cela évite de devoir modifier tous ses workflows pour faire un ajustement sur les permissions. Bien souvent c’est à la fin du projets que l’on fait une recette complète des differentes actions et permissions associées et que l’on ajuste les permissions.
Prenons l’exemple d’une application ayant les 3 actions suivantes:
- CreateObject : Créer une nouvelle entité dans une table (arbitraire pour l’exemple). Seuls les admins doivent pouvoir réaliser cette action.
- DeleteObject : Supprimme une entité. Seuls les admins doivent pouvoir réaliser cette action.
- EditObject : Edite une entité. Les admins et les users doivent pouvoir réaliser cette action.
Il y a deux manières de modéliser les permissions avec les Option sets.
Solution 1 : avec un nouvel Option sets “Permission”
Il s’agit de créer un nouvel Option set nommé “Permissions”. On crée une option pour chaque action de l’application (ici CreateObject,
DeleteObject et EditObject). Chaque option aura un attribut Roles de type List of Roles et représentant la liste des rôles autorisés
à réaliser l’action.
Option set “Permission” :
| Display (nom de l’option) | Roles (List of Roles) |
|---|---|
| CreateObject | 🔴 Admin |
| DeleteObject | 🔴 Admin |
| EditObject | 🔴 Admin, ⚪ User |
Ensuite, dans l’éditeur de l’application, il suffit d’utiliser la condition
Get an option, choisir Permission, puis l’option CreateObject par exemple et compléter la condition pour obtenir
When CreateObject's Roles contains Current User's Role.
Cette condition peut être utilisées sur comme condition de visibilité d’un bouton ainsi que sur les conditions d’exécution des workflows (Only when).
Solution 2 : avec l'Option sets “Role”
La seconde option consiste à ajouter des attributs de type Yes / No sur l'Option set “Role” pour chaque action.
Option set “Role” :
| Display (nom de l’option) | CreateObject (Yes/No) | EditObject (Yes/No) | DeleteObject (Yes/No) |
|---|---|---|---|
| 🔴 Admin | Yes | Yes | Yes |
| ⚪ User | No | Yes | No |
La condition à utiliser au niveau des boutons ou des workflows sera alors When Current Users's Role's CreateObject is "yes".
Solution 3 : par niveau d’accréditation
Cette solution consiste à attribuer à chaque rôle un niveau d’accréditation (Level) représenté par une valeur numérique. Plus la valeur est élevée, plus elle offre de permissions. Dans notre exemple :
| Display (nom de l’option) | Level (Number) |
|---|---|
| 💀 SuperAdmin | 3 |
| 🔴 Admin | 2 |
| ⚪ User | 1 |
Ensuite, crée comme en Solution 1 un Option Set “Permission”, mais ici chaque permission ne sera pas associée à une liste de rôles, mais à un niveau d’accréditation minimal :
| Display (nom de l’option) | MinLevel (Number) |
|---|---|
| CreateObject | 2 |
| DeleteObject | 2 |
| EditObject | 1 |
| DeleteAllObjects | 3 |
La condition à utiliser au niveau des boutons ou des workflows sera alors Current User's Role's Level >= CreateObject's MinLevel (en passant par l’étape Get an option).
Avec cette solution, un rôle donné sera autorisé à réaliser les actions de son niveau, mais également toutes les actions de niveaux inférieurs.
Tests
Depuis la table des utilisateurs, il est possible de charger l’application en se connectant sur le compte des différents utilisateurs pour faire des tests une fois les différentes permissions paramétrées. Pour cela, depuis Data > App data, charge la table des Users et faites Run as ➡.
Et les Privacy settings ?
Ces rôles et conditions qui en découlent peuvent également êtres utilisées au niveau des Privacy settings pour sécuriser l’application. Attention
le paramétrage des Privacy settings peut être plus complexe qu’il n’y parait et fera l’objet d’un article à part entière ultérieurement.