nas-runbooks/hermes-tt/rla-api-users-superadmin.md

4.0 KiB

rla-api — Gestion des utilisateurs & superadmin par défaut

Date : 2026-07-04, MAJ 2026-07-05 · Tags : infra, rla-api, users, superadmin, bcrypt, gitea, volume, btrfs

MAJ 2026-07-05 — FIX DÉFINITIF APPLIQUÉ

/volume1/docker/rla-api/data/ est désormais monté en volume sur /app/data (compose commit 018bbb2 sur le repo app). Les comptes survivent à tous les rebuilds/recreates sans modification — plus besoin de toucher au repo pour un utilisateur. Modif = éditer /volume1/docker/rla-api/data/users.json (relu à chaque appel, pas de restart) ou l'UI. Le data/users.json du repo n'est plus qu'un seed masqué par le volume. La procédure « 3 endroits » ci-dessous reste comme référence historique.

Récupération post-incident : les mdp UI d'avant le recreate du 04/07 sont irrécupérables (couche btrfs de l'ancien conteneur détruite avec lui). Vérifié par scan complet : docker run --rm -v /volume1/@docker:/dr:ro alpine find /dr/btrfs/subvolumes -name users.json + mapping subvolume→container via cat /dr/image/btrfs/layerdb/mounts/<container-id>/mount-id (astuce réutilisable pour toute récup de fichier de conteneur). Le seul users.json plus récent trouvé appartenait à gsparc-mezzouna-api. Le hash de nabil a été restauré depuis le seed USERS du .env (probable mdp d'origine du conteneur standalone).

Contexte

rla-api (Gestion des Marchés RLA, TT Zone Sud) — conteneur sur le NAS, port 3005, stack /volume1/docker/rla-api/, source Gitea bolbol/Gestion-des-Marches-RLA.

Le piège (pourquoi les mots de passe « reviennent » après une MAJ)

Les comptes vivent dans /app/data/users.json dans le conteneur, sans volume monté, ET ce fichier est tracké dans le repo Gitea → baké dans l'image à chaque build.

  • La variable USERS du .env ne sert de seed que si le fichier n'existe pas — jamais le cas puisque l'image le contient déjà.
  • Conséquence : tout rebuild écrase les comptes créés/modifiés via l'UI avec la version du repo. C'est ce qui a restauré un ancien mot de passe le 2026-07-04 lors de la régularisation compose.

Superadmin par défaut (depuis 2026-07-04)

Nabil.Derouiche / 03167442rla — role superadmin, region all, id 4. Présent dans les 3 sources (users.json live, .env, repo Gitea commit aca99e7) → survit aux MAJ. Comptes conservés : nabil (id 1, mdp inconnu), admin (id 2), ikram (id 3).

Procédure : ajouter/modifier un utilisateur de façon PÉRENNE

  1. Générer le hash bcrypt (dans le conteneur, bcryptjs dispo) :
    ssh nas "/usr/local/bin/docker exec rla-api node -e \"console.log(require('bcryptjs').hashSync('LE_MDP',10))\""
    
  2. Mettre à jour les 3 endroits :
    • Repo Gitea data/users.json (le seul qui compte au prochain build) — via API PUT /api/v1/repos/bolbol/Gestion-des-Marches-RLA/contents/data/users.json (base64 + sha), creds bolbol.
    • Live : docker exec -i rla-api sh -c 'cat > /app/data/users.json' < users.json (pris en compte immédiatement, pas de restart — getUsers() relit le fichier à chaque appel).
    • .env (/Volumes/docker/rla-api/.env via SMB) variable USERS — filet de sécurité si le fichier disparaît.
  3. Tester : curl -s -X POST http://192.168.100.33:3005/api/auth/login -H 'Content-Type: application/json' -d '{"username":"...","password":"..."}' → doit renvoyer {"token":...}.

Ce qui NE marche PAS

  • Créer l'utilisateur via l'UI/POST /api/users seulement → perdu au prochain rebuild (écrit uniquement dans le users.json du conteneur).
  • Modifier USERS dans .env seulement → ignoré tant que /app/data/users.json existe (donc toujours).
  • grep --include dans le conteneur : BusyBox, pas GNU grep.

Fix définitif possible (non appliqué)

Monter /volume1/docker/rla-api/data:/app/data dans le compose + retirer data/users.json du repo (.dockerignore/.gitignore) → les comptes UI survivraient aux rebuilds. À faire lors d'une prochaine MAJ si besoin.