Utiliser les options sets de Bubble.io pour gérer les rôles et permissions des utilisateurs dans vos applications.
Table des matières
Une gestion des utilisateurs native, mais sans permissions
Chaque application Bubble.io dispose par défaut d’une gestion des utilisateurs. Cela se traduit par une table Users, 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 (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 généralement de rôle ou bien de groupes.
La gestion des rôles n’est pas native dans Bubble.io, 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.io.
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 les rôles et permissions de notre application.
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 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 un attribut Role ce qui permettra d’affecter un rôle à chaque utilisateur.
Il sera alors possible 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.
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 projet que l’on fait une recette complète des différentes actions et permissions associées et que l’on finalise 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 : Supprime une entité. Seuls les admins doivent pouvoir réaliser cette action.
- EditObject : Édite une entité. Les admins et les users doivent pouvoir réaliser cette action.
Il y existe 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ée 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és 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.
