Bedrud implémente un système de rôles à 5 niveaux pour le contrôle d’accès. Chaque rôle correspond à un ensemble de chaînes d’accès stockées dans l’enregistrement utilisateur et appliquées à la fois au niveau API (middleware backend) et au niveau UI (gardes frontend et rendu conditionnel).

Hiérarchie des rôles

Application backend

Les niveaux d’accès sont appliqués via le middleware RequireAccess sur chaque route admin. Le middleware vérifie le tableau d’accès de l’utilisateur par rapport au niveau minimum requis :

• Les routes nécessitant un accès superadmin rejettent admin, modérateur, utilisateur et invité
• Les routes nécessitant un accès admin autorisent superadmin et admin
• Les routes nécessitant un accès moderator autorisent superadmin, admin et modérateur

Le backend stocke les accès sous forme de chaîne séparée par des virgules dans la base de données (colonne accesses de la table users). Le type GORM StringArray gère la sérialisation et la désérialisation.

Intégration frontend

Type utilisateur

L’interface User dans user.store.ts comprend deux champs booléens dérivés du tableau d’accès :

interface User {
  // ...
  isSuperAdmin: boolean  // accesses.includes('superadmin')
  isAdmin: boolean       // accesses.includes('admin') || accesses.includes('superadmin')
  accesses: string[]     // raw access list from backend
}

Garde admin

La disposition admin (/dashboard/admin) laisse passer superadmin, admin et modérateur. Les modérateurs reçoivent une variable de contexte isReadOnly=true :

// routes/dashboard/admin.tsx
const canAccess = user?.isSuperAdmin || accesses.includes('admin') || accesses.includes('moderator')

Le hook useAdminContext() fournit le flag isReadOnly à toutes les routes enfants :

const { isReadOnly } = useAdminContext()

Ce que les modérateurs peuvent voir vs faire

Sélecteur de rôle

L’interface admin fournit une liste déroulante <Select> à la fois dans le tableau de la liste des utilisateurs et sur la page de détail de l’utilisateur, remplaçant l’ancien bouton binaire superadmin. Options disponibles :

La liste déroulante envoie une requête PUT /api/admin/users/:id/accesses avec le tableau d’accès complet.

Gestion CLI

Les commandes bedrud user promote et bedrud user demote acceptent un flag --role :

# Promote to superadmin (default)
bedrud user promote --email user@example.com
 
# Promote to admin
bedrud user promote --email user@example.com --role admin
 
# Promote to moderator
bedrud user promote --email user@example.com --role moderator
 
# Demote specific role
bedrud user demote --email user@example.com --role admin

Valeurs --role valides : superadmin, admin, moderator, user, guest.

Emplacements du code