Outil BDD

Appearance

Synchronisation Console Admin ​

Contexte ​

Le modèle initial reposait sur un cron backend (enterprise.cron.ts) qui synchronisait les donnees de la console d'administration vers la base locale prisma.tool. Historiquement, il lisait directement la base PostgreSQL Supabase via un second client Prisma, retire depuis.

Decision du lead dev : l'Outil BDD ne doit plus avoir de dependance directe a la base AUTH (Supabase). Toute lecture de donnees de la console admin doit passer par son API REST.

Authentification machine-to-machine ​

Le ConsoleAdminService (back/src/api/console-admin/console-admin.service.ts) appelle l'API console admin avec une cle API transmise dans le header x-api-key.

Creer la cle API ​

  1. Se connecter a la console admin en tant que super admin
  2. Aller dans la section Cles API
  3. Creer une cle avec les scopes suivants :
    • enterprises:read
    • profiles:read
  4. Copier la cle generee (affichee une seule fois)

Fonctionnement ​

ConsoleAdminService
  └─ fetch('https://staging.api.console.heriade.fr/enterprises', {
       headers: { 'x-api-key': '<cle API>' }
     })
  └─ pagination automatique (100 items/page, parcourt toutes les pages)
  └─ retourne les donnees aux services BDD qui en ont besoin dynamiquement

L API retourne uniquement les entreprises de type enterprise (hors comptes personnels). Le filtrage par environnement/application est porte par le protocole AUTH -> BDD et le app_access_token.

Variables requises ​

Dans back/.env :

ini
CONSOLE_ADMIN_API_URL=https://staging.api.console.heriade.fr
CONSOLE_ADMIN_API_KEY=heriade_xxxxx  # cle creee dans la console admin
AUTH_APP_URL=https://staging.auth.heriade.fr
APP_ACCESS_TOKEN_SECRET=
ENVIRONMENT=default
APPLICATION=bdd

WARNING

Ne jamais commiter la valeur de CONSOLE_ADMIN_API_KEY. Elle doit etre dans .env uniquement.

Etat actuel ​

Source primaire d acces :

  • AUTH valide l acces a bdd
  • AUTH emet un app_access_token
  • AUTH expose aussi /session-status pour permettre a BDD de verifier que la session SSO existe encore
  • BDD verifie ce jeton signe

L identite locale dans BDD est maintenant provisionnee a la connexion :

  • creation du user local au premier acces
  • mise a jour des champs utiles aux connexions suivantes
  • conservation des FKs locales pour documents et folders

Il n y a plus de synchro d identite active a maintenir.

Usages dynamiques de la console admin ​

  • Liste des entreprises (super admin) : GET /environments/{slug}/enterprises — filtrée par l'environnement Cloud (CONSOLE_ADMIN_ENVIRONMENT_SLUG=default). Implémenté dans ConsoleAdminService.getEnterprisesByEnvironment(), utilisé par FolderService.listEnterprises().
  • Liste des profils : GET /enterprises/{id}/profiles — lecture dynamique par entreprise.
  • Point de vigilance : ne pas réintroduire une synchro globale d'identité.

Limites de contrat constatees ​

  • les roles doivent etre reconstruits depuis profile.role

Strategie recommandee ​

  1. Garder le protocole signe AUTH -> BDD comme unique source primaire d acces.
  2. Garder la verification de session AUTH via /session-status tant qu il n existe pas encore de session maître parent-domaine.
  3. Provisionner localement les users a la connexion ou au besoin metier cible.
  4. Recuperer les listes globales depuis console-admin de maniere dynamique quand necessaire.