Gestion des utilisateurs

Sovrium provisionne et gère les utilisateurs sans jamais exiger que vous touchiez à la base de données. Le premier administrateur est créé au démarrage ; chaque utilisateur suivant est créé, listé et géré via l'API d'administration authentifiée. Chaque opération est protégée par RBAC et consignée dans le journal d'audit.

La gestion des utilisateurs n'est disponible que lorsque l'authentification est configurée. Le plugin d'administration s'active dès qu'un bloc auth existe — il n'y a pas d'indicateur distinct.

Amorçage de l'administrateur

Le premier administrateur ne peut pas être créé par un autre administrateur (il n'en existe aucun) ni par auto-inscription (vous ne voulez pas qu'un inconnu s'approprie le siège d'administrateur). Trois chemins complémentaires provisionnent ce compte sur une base de données vierge.

Amorçage par variable d'environnement (sans configuration)

AUTH_ADMIN_EMAIL=admin@example.com
AUTH_ADMIN_PASSWORD=SecureP@ssw0rd!
AUTH_ADMIN_NAME=System Administrator   # optional, defaults to "Administrator"

Au premier démarrage sur une base vierge, le serveur provisionne l'administrateur avec une adresse vérifiée et l'accès complet aux points de terminaison d'administration. Aux démarrages suivants, ce chemin ne fait rien : il ne crée jamais de doublon et ne modifie jamais un utilisateur existant, même si l'adresse correspond déjà à un rôle différent. Le succès est consigné sans le mot de passe.

Amorçage par jeton à usage unique

Lorsque le serveur démarre sans AUTH_ADMIN_EMAIL défini et sans utilisateur en base, il génère un jeton aléatoire de 256 bits, l'affiche une fois dans la bannière de démarrage et accepte une seule réclamation :

# Token appears in the banner as:
#   → First-admin token (POST /api/admin/bootstrap/claim): <64-hex-token>

curl -X POST http://localhost:3000/api/admin/bootstrap/claim \
  -H 'Content-Type: application/json' \
  -d '{ "token": "<64-hex-token>", "email": "admin@example.com", "password": "SecureP@ssw0rd!", "name": "Admin" }'

• Seul le hachage SHA-256 est conservé ; le texte en clair est affiché sur stdout exactement une fois et n'est jamais consigné.
• Le jeton expire après 1 heure et peut être réclamé une seule fois — les rejeux renvoient 401.
• Dès qu'un administrateur existe, la route renvoie 404 : la fenêtre est fermée, et même un jeton valide divulgué ne peut la rouvrir.

C'est le chemin qui rend possible « lancer le binaire sur un serveur vierge, ouvrir l'URL, construire l'application en direct ». Voir Infrastructure de base de données pour la base sans configuration qui l'accompagne.

Création et gestion des utilisateurs

Une fois qu'un administrateur existe, chaque opération du cycle de vie des utilisateurs passe par l'API d'administration. Chaque point de terminaison exige une session d'administrateur authentifiée — les requêtes non authentifiées renvoient 401, et les sessions non administrateur obtiennent 404 : la surface d'administration est invisible pour qui ne peut pas s'en servir, son existence n'est donc pas découvrable.

create-user exige que vous inventiez et transmettiez le mot de passe de l'utilisateur, et ne lui envoie rien. Pour accueillir de vraies personnes, utilisez plutôt une invitation.

Attribution de rôle

Déplacé vers Invitations.

Flux d'invitation

Déplacé vers Invitations.

Pages connexes

• Invitations — intégration sans mot de passe et rôle reçu par un nouvel utilisateur.
• Contrôle de l'inscription — si le public peut s'auto-inscrire.
• Rôles & RBAC — modèle de rôle et permissions par champ.
• Sessions — durée de vie des sessions, révocation, multi-appareils.
• Tableau de bord d'administration — console de lecture de niveau opérateur sur les utilisateurs et les tables.
• Surveillance de l'activité — piste d'audit des actions des utilisateurs et des administrateurs.
• Variables d'environnement — référence complète des variables env incl. AUTH_ADMIN_*.