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).

Bubble emoji

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

Option set Permissions

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)
🔴 AdminYesYesYes
⚪ UserNoYesNo

Option set roles

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)
💀 SuperAdmin3
🔴 Admin2
⚪ User1

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)
CreateObject2
DeleteObject2
EditObject1
DeleteAllObjects3

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 ➡.

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.