Aller au contenu

Permissions (RBAC)

ikloze utilise un contrôle d'accès basé sur les rôles avec un modèle User → Group → Permission.

Format des codenames

Les permissions sont déclarées dans un registre (PermissionRegistry) et synchronisées en base au démarrage de l'application. Le codename suit le format :

<module>.<action>_<resource>      # ex. auth.view_user, forms.add_form

Le registre génère deux familles d'actions :

registry.register('forms', 'form', {
  auto: ['add', 'view', 'change', 'delete'],   // → forms.add_form, forms.view_form, ...
  custom: ['publish_form'],                      // → forms.publish_form
});
  • auto — les CRUD standard add | view | change | delete, produisant <module>.<action>_<resource>.
  • custom — actions métier arbitraires, produisant <module>.<action> tel quel.

Permissions d'administration

Les permissions staff/admin se terminent par le suffixe _admin (ex. users.manage_user_admin). Les permissions CRUD génériques (ex. users.view_user) ne le portent pas. Les méthodes d'admin vivent dans un *AdminService dédié, séparé du service orienté utilisateur.

Vérifier un accès

On vérifie l'accès via :

user.hasPerm('auth.view_user');   // → boolean

Ordre de résolution

hasPerm court-circuite dans cet ordre :

  1. Superutilisateur (user.isSuperuser) → true.
  2. Propriétaire du workspace (workspace.ownerId === user.id) → true.
  3. Sinon → union des permissions issues des groupes de l'utilisateur dans le workspace actif, avec des surcharges explicites allow/deny au niveau de l'adhésion (membership). Les deny l'emportent.

Pas de codename joker

Il n'existe aucun codename *. Les court-circuits superutilisateur/propriétaire sont des raccourcis dans le code (hasPerm), pas des lignes en base. N'introduisez jamais de permission joker.

Synchronisation au démarrage

Au boot, le service de synchronisation des permissions lit PermissionRegistry.getAll() et réconcilie la table des permissions en base. Ajouter une permission = l'enregistrer dans le registre ; elle est créée en base au prochain démarrage.

Groupes (rôles)

Les groupes portent des ensembles de permissions et sont rattachés à un workspace. Un membre reçoit ses permissions via ses groupes, ajustées par les surcharges allow/deny de son adhésion. Voir le module Cœur.

Liens de code

  • domain/permissions/permission.registry.ts — le registre (register / getAll).
  • domain/users/user.model.ts — hasPerm et l'ordre de résolution.
  • app/permissions/ — service et synchronisation.
  • web/permissions/permissions.controller.ts — exposition HTTP des permissions effectives.