Permissions des tables

Sovrium contrôle l'accès aux enregistrements avec un contrôle d'accès basé sur les rôles (RBAC) au niveau de la table, des permissions par champ pour un contrôle granulaire des colonnes, et des prédicats au niveau ligne optionnels pour un cloisonnement par ligne. Un accès non autorisé renvoie 404 (jamais 403) afin d'empêcher l'énumération des enregistrements.

Valeurs de permission

Chaque opération accepte l'un de trois formats :

Les trois rôles intégrés sont admin, member et viewer (du plus élevé au plus bas). Des noms de rôles personnalisés sont également acceptés dans la forme tableau.

Permissions au niveau de la table

Définissez permissions sur une table pour conditionner chaque opération.

permissions:
  read: all
  comment: authenticated
  create: [admin, editor]
  update: [admin, editor]
  delete: [admin]

Restauration et suppression définitive

Il n'existe pas d'opération restore ni permanentDelete distincte.

La restauration partage l'autorisation delete. Restaurer est l'inverse de supprimer en douceur : les deux sens passent donc par la même porte, et quiconque peut supprimer un enregistrement en douceur peut le restaurer. Une autorisation distincte laisserait les deux côtés diverger, l'un devenant une porte plus faible sur la même opération.

La suppression définitive est réservée aux administrateurs et n'est pas configurable. ?permanent=true efface la ligne de façon irréversible : cette opération est donc réservée au rôle admin sur toutes les tables, quelles que soient les permissions. Les tentatives non administrateur renvoient 404 (anti-énumération), comme tout autre accès non autorisé.

Permissions par champ

Restreignez l'accès en lecture/écriture à des colonnes spécifiques sous permissions.fields. Chaque entrée nomme un field et, optionnellement, ses audiences read et write (mêmes trois formats). Lorsqu'une permission de champ est omise, elle hérite du read au niveau de la table (pour la lecture) ou de create/update (pour l'écriture).

Un champ qu'un rôle ne peut pas lire n'est pas non plus interrogeable par ce rôle : filter, groupBy et aggregate sur ce champ renvoient 404 (anti-énumération), car une colonne masquée divulguerait autrement ses valeurs via le jeu de résultats — groupBy en renvoie les valeurs distinctes, et aggregate son minimum et son maximum. Un champ que le rôle peut lire reste entièrement interrogeable.

permissions:
  read: authenticated
  fields:
    - { field: salary, read: [admin, hr], write: [admin] }
    - { field: department, read: all, write: [admin] }

Permissions au niveau ligne

Définissez rowLevelPermissions pour un cloisonnement en défense en profondeur. Chaque opération CRUD peut porter un prédicat when côté serveur qui est ajouté comme filtre à chaque requête retournant des enregistrements. La barrière de rôle s'exécute en premier ; le prédicat au niveau ligne filtre ensuite dans la portée du rôle autorisé.

Un prédicat est { field, operator, value } :

rowLevelPermissions:
  read:
    when:
      field: client_id
      operator: in
      value: { kind: currentUser, path: { kind: assignment, tableSlug: clients } }
  write:
    when:
      field: client_id
      operator: in
      value: { kind: currentUser, path: { kind: assignment, tableSlug: clients } }

Permissions Ressource:Action

Pour des contextes de permission plus larges (plugin admin, clés API), Sovrium prend également en charge une carte resource: [actions] où chaque ressource liste les actions autorisées et * signifie toutes les actions :

users: [read, list]
posts: [create, read, update, delete]
analytics: ['*']