ASPIC/journal/ASPIC-Journal. 24. MIRADOR Branché.md

24. MIRADOR branché — authentification par email, routage dynamique multi-bases, retrait du compte de démonstration (30 août 2026)

Contexte. Reprise de session le même jour que la section 23. Deux chantiers traités à la suite : le retrait du compte de démonstration resté en place depuis le 21 août (signalé sans être traité aux sections 8, 21, 22, 23), puis le branchement effectif de MIRADOR sur l'authentification — jusqu'ici un schéma discuté avec une seule ligne de test (section 21), aucun code applicatif ne le consultant encore.

Retrait du compte de démonstration. identification.html : suppression du tableau UTILISATEURS_DEMO (JMP/aspic2026 en dur), de trouverUtilisateurDemo(), et de la bascule automatique dans verifierIdentifiants() en cas d'échec de aspic.php — un aspic.php injoignable fait désormais échouer proprement l'identification plutôt que de se rabattre sur ce filet. Commentaire résiduel nettoyé dans aspic.php. Commit local dans le clone de travail (git commit), mais push impossible depuis cette session : le blocage du proxy git documenté en section 20 ("access denied by the git proxy: JMP-MS/ASPIC is not in this session's authorized repository set") a été retesté explicitement à cette occasion et reste entier, quel que soit le token fourni — confirmation qu'il s'agit bien d'un blocage au niveau du proxy Anthropic, pas d'un problème de droits GitHub. Le circuit qui fonctionne reste celui de la section 23 (FileZilla → /docker/aspic/src → git push en SSH depuis le VPS).

Nouvelle infrastructure MySQL, mise en place par Jean-Marc avant ce chantier. Trois instances MySQL désormais actives (mysql, mysql2, mysql3), configurées de façon homogène et toutes rejoignables par leur nom de service Docker sur le réseau proxy partagé avec le conteneur crm-app — pas de configuration réseau supplémentaire nécessaire. Bases créées par clonage de l'ASPIC existante : MS-DEV et MS-TST sur l'instance mysql (l'ancienne base ASPIC est conservée telle quelle, en filet de sécurité, non utilisée par le nouveau circuit). MIRADOR dupliquée à l'identique sur mysql2 — c'est cette copie-là que l'application interroge désormais pour l'authentification (voir ROUTER_DB_HOST ci-dessous) ; la copie restée sur mysql n'est plus utilisée par le code, à garder en tête si les deux venaient à diverger un jour. Le compte technique crm_user a été dupliqué à l'identique (mêmes identifiants) sur les trois instances, avec des droits complets sur toutes les bases qu'elles hébergent chacune — ce choix d'homogénéisation simplifie beaucoup le code : une seule paire d'identifiants suffit pour toute connexion, quelle que soit l'instance visée.

docker-compose.yml du conteneur crm-app, mis à jour par Jean-Marc :

    environment:
      DB_HOST: "mysql"
      DB_USER: "crm_user"
      DB_PASS: "***"
      ROUTER_DB_HOST: "mysql2"
      ROUTER_DB_USER: "crm_user"
      ROUTER_DB_PASS: "***"

(DB_NAME, BREVO_API_KEY, LIEN_DOC_CLE_SECRETE inchangées, non reproduites ici — voir section 3 pour le fichier complet.) Pas de ROUTER_DB_NAME ajoutée : db.php utilise MIRADOR par défaut si la variable est absente, ce qui est le cas ici.

Nouvelle architecture de connexion (db.php, réécrit). Deux fonctions désormais :

• getRouterConnection() : connexion fixe vers MIRADOR sur l'instance de routage (ROUTER_DB_HOST/ROUTER_DB_USER/ROUTER_DB_PASS), appelée uniquement par aspic.php à l'identification.
• getDbConnection() : si la session PHP en cours porte des coordonnées de routage ($_SESSION['ASPIC_DB_HOST']/['ASPIC_DB_PORT']/['ASPIC_DB_NAME'], posées par aspic.php après vérification contre MIRADOR), la connexion s'ouvre vers cette base précise — deux utilisateurs connectés en même temps peuvent donc travailler sur deux bases différentes (MS-DEV, MS-TST, ou une base de bêta testeur plus tard), chacun cloisonné dans sa propre session. Sans routage exploitable (pas de session, ex. les scripts publics de prospection — prospects_core.php), repli sur la base par défaut du conteneur (DB_HOST/DB_NAME), exactement comme avant MIRADOR.

Conséquence importante, à valeur générale pour la suite : aucun des autres endpoints (contacts.php, realisations.php, professions.php, statuts.php, preferences.php) n'a eu besoin d'être modifié. Ils appellent tous getDbConnection() sans argument, exactement comme avant — c'est cette fonction seule qui route désormais vers la bonne base selon la session en cours. Choix délibéré plutôt que d'introduire une fonction dédiée aux écrans authentifiés avec un nom différent : minimise le diff, cohérent avec la discipline "pas de sur-ingénierie" déjà en place sur ce projet.

aspic.php, réécrit contre MIRADOR. L'identifiant du formulaire de connexion n'est plus USR_Code (3 caractères) mais MIR_Email (identification.html : champ type="email", placeholder "Adresse mail"). Déroulé :

1. Connexion à MIRADOR (getRouterConnection()), SELECT ... FROM MIR_Users WHERE MIR_Email = ? AND MIR_Actif = 1.
2. Vérification du mot de passe par password_verify() contre MIR_MDPHash — ASP_Users.USR_MDP n'est plus consulté du tout, cette colonne devient un vestige que Jean-Marc pourra retirer de chaque base (ASPIC, MS-DEV, MS-TST...) quand il le souhaite, sans urgence. Un hash bcrypt factice est comparé même quand l'email est inconnu, pour ne pas laisser une différence de temps de réponse trahir l'absence d'un compte — dans le même esprit que le hash_equals() déjà en place ailleurs sur ce projet, geste peu coûteux plutôt que garantie forte.
3. En cas de succès : $_SESSION['USR_Code'] reçoit MIR_Code (qui reprend intégralement le rôle jusqu'ici tenu par USR_Code — REA_CodeUser/OPE_CodeUser, jointure ASP_Users pour les préférences/avatar/ratios) et $_SESSION['ASPIC_DB_HOST']/['ASPIC_DB_PORT']/['ASPIC_DB_NAME'] reçoivent les coordonnées de routage lues dans la ligne MIRADOR.
4. Une connexion à la base cible est ouverte immédiatement (via getDbConnection(), qui voit déjà la session tout juste posée) pour lire USR_Nom — MIRADOR ne porte pas le nom complet de l'utilisateur, seulement email/code/mot de passe/routage. Un échec de connexion à cette base cible à cet instant fait échouer explicitement le login (500) plutôt que de laisser entrer un utilisateur dans une base injoignable, ce qui ferait échouer silencieusement tous les écrans suivants.

Dépendance opérationnelle à garder en tête : pour qu'un utilisateur MIRADOR se connecte pleinement (nom affiché, préférences, badge société), il faut qu'une ligne ASP_Users avec USR_Code = MIR_Code existe dans la base cible désignée par sa ligne MIR_Users. Comme MS-DEV et MS-TST sont des clones de l'ASPIC existante, les comptes déjà présents (JMP, Vik...) devraient déjà correspondre sans action supplémentaire — mais toute nouvelle ligne MIRADOR pointant vers un MIR_Code absent de la base cible laissera l'utilisateur entrer (authentification réussie) tout en cassant preferences.php (404) juste après.

Tests effectués avant livraison (pas d'accès direct aux instances MySQL réelles depuis cette session) : php -l sur les sept fichiers PHP de l'application (les cinq endpoints inchangés inclus, pour non-régression), node --check sur le JavaScript extrait d'identification.html, équilibre des balises <div> (23/23, inchangé). Logique de routage de getDbConnection() vérifiée par un script PHP autonome simulant les deux cas (pas de session → base par défaut du conteneur ; session avec routage MIRADOR → host/port/base exacts de la ligne résolue, testé avec deux jeux de coordonnées différents pour confirmer qu'un second utilisateur simultané serait bien routé ailleurs).

Fichiers livrés le 30 août 2026 : db.php, aspic.php, identification.html. Aucun changement sur contacts.php, realisations.php, professions.php, statuts.php, preferences.php (voir plus haut). Pas de mise à jour de version.php à ce stade — laissé à Jean-Marc, qui incrémente lui-même en fin de session avant le push (convention section 21).

Reste à faire, côté Jean-Marc, avant test réel :

• Vérifier/mettre à jour la ligne MIR_Users de test existante (Jean-Marc lui-même) pour qu'elle pointe bien vers MIR_ServeurHost = mysql, MIR_BaseNom = MS-DEV Fait — voir section 25.
• Ajouter une ligne MIR_Users pour MS-TST Fait — deuxième utilisateur ajouté et testé avec succès, voir section 25.
• Déployer les trois fichiers via le circuit habituel, puis tester la connexion sur aspic.mvl-tls.fr avec les deux comptes Fait et validé — voir section 25.
• Une fois validé, envisager de retirer USR_MDP des tables ASP_Users (ASPIC, MS-DEV, MS-TST) Fait le 30 août 2026 (soir) — voir section 25.
• Redéploiement futur vers aspic.bzh une fois ce mécanisme validé sur aspic.mvl-tls.fr Fait le 30 août 2026 (soir) — aspic.bzh est en ligne avec le même code, voir section 25.