V 1.004 ToDoList et Journal découpé

journal/ASPIC-Journal. 21. MIRADOR Base d'Authentification Centralisée.md

@@ -0,0 +1,75 @@
+## 21. MIRADOR — base d'authentification centralisée multi-instances, numéro de version applicatif (28 août 2026, soir)
+
+**Contexte.** Reprise de session le soir même, après l'annonce de deux évolutions d'infrastructure par Jean-Marc : installation d'une nouvelle instance MySQL sur le serveur, et achat prochain du nom de domaine `aspic.bzh` (toujours pas acquis à ce stade — voir réflexions stratégiques, section 7). Ces deux annonces ont ouvert une réflexion approfondie sur l'architecture d'accès multi-environnements d'ASPIC, capturée ici pour la partie strictement technique (schéma de données, code livré) — le raisonnement business sous-jacent (bêta test, modèle SaaS envisagé) reste dans les réflexions stratégiques.
+
+**Topologie retenue.** Une fois `aspic.bzh` actif, deux publics distincts accèderont à la dernière version de l'application : Jean-Marc lui-même (essais avec des données propres) et de futurs bêta testeurs, chacun avec sa propre base. Décision actée : la première instance MySQL (celle utilisée aujourd'hui) hébergera deux bases distinctes, **`MS-DEV`** (nouveau nom de baptême de la base ASPIC actuelle, celle du bac à sable `aspic.mvl-tls.fr` — renommage restant à faire par Jean-Marc, y compris le `DB_NAME` du `docker-compose.yml` correspondant) et **`MS-EXP`** (nouvelle base, usage personnel de Jean-Marc sur `aspic.bzh`). La deuxième instance MySQL, toute nouvelle, hébergera autant de bases que nécessaire pour les bêta testeurs, une base par testeur — cohérent avec le principe déjà retenu dans les réflexions stratégiques (isolation par base plutôt que colonne `client_id` partagée). Convention de nommage des bases actée : lisible/thématique (`MS-DEV`, `MS-EXP`) plutôt que numérotée (`ASPIC_001`, etc.) — **vérifié que le tiret ne pose aucun problème technique** : l'application ne fait jamais de requête inter-bases (chaque connexion PDO cible une seule base via le DSN, `dbname=MS-DEV`), donc aucune requête SQL n'a jamais à qualifier ou échapper le nom du schéma. **⚠️ Topologie finalement mise en place le 30 août 2026 (section 24) : trois instances (mysql/mysql2/mysql3), MS-DEV et MS-TST (pas MS-EXP) créées par clonage sur `mysql`, MIRADOR dupliquée sur `mysql2` — voir cette section pour l'état réel.**
+
+**Nouvelle base MIRADOR — authentification et dispatch centralisés.** Le routage vers la bonne base ne peut pas se faire par sous-domaine (principe déjà acté le 28 août au matin, réflexions stratégiques section 8 : un seul point d'entrée `aspic.bzh`, aucun `toto.aspic.bzh` visible). Décision : une base à part entière, nommée **MIRADOR**, porte l'identité et le routage de tous les utilisateurs, quelle que soit l'instance/base cible. Évolution assumée par rapport à l'idée du 28 août matin (vérifier le mot de passe *dans* la base cible après un premier aiguillage) : l'authentification est désormais **entièrement centralisée dans MIRADOR** — l'appli y vérifie l'identifiant et le mot de passe, obtient en retour les coordonnées de connexion de la base cible, puis ouvre une seconde connexion vers cette base pour le travail applicatif.
+
+**Structure proposée pour `MIR_Users`** (schéma discuté et validé avec Jean-Marc, **non encore créé en base à ce stade** — une seule ligne de test existe, créée manuellement par Jean-Marc) :
+
+```sql
+CREATE TABLE `MIR_Users` (
+  `MIR_Incr` int NOT NULL AUTO_INCREMENT,
+  `MIR_Email` varchar(100) NOT NULL,
+  `MIR_Code` varchar(3) NOT NULL,
+  `MIR_MDPHash` varchar(255) NOT NULL,
+  `MIR_ServeurHost` varchar(100) NOT NULL,
+  `MIR_ServeurPort` smallint UNSIGNED NOT NULL DEFAULT 3306,
+  `MIR_BaseNom` varchar(64) NOT NULL,
+  `MIR_Actif` tinyint(1) NOT NULL DEFAULT '1',
+  `MIR_Creation` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
+  PRIMARY KEY (`MIR_Incr`),
+  UNIQUE KEY `MIR_Email` (`MIR_Email`),
+  UNIQUE KEY `MIR_BaseNom_Code` (`MIR_BaseNom`, `MIR_Code`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
+```
+
+Choix actés dans cette structure :
+
+- **`MIR_Email` comme identifiant de connexion**, unique — remplace l'idée du 28 août matin d'un identifiant structuré type `code_client-code_user` (réflexions stratégiques, section 8). Évolution assumée : l'email est plus naturel pour des bêta testeurs externes, qui n'ont pas de convention de code à retenir.
+- **`MIR_Code` (3 caractères) conservé** pour son rôle déjà existant de signature dans les tables tenant (`REA_CodeUser`/`OPE_CodeUser`), mais **unique seulement au sein d'une même base cible** (contrainte `UNIQUE (MIR_BaseNom, MIR_Code)`), pas globalement — argument de Jean-Marc : "au maximum une BDD est utilisée par 2 ou 3 utilisateurs au maximum, le jour où il y en aura plus par instance, c'est que les problèmes auront changé de forme."
+- **`MIR_ServeurHost`/`MIR_ServeurPort`/`MIR_BaseNom` dupliqués par ligne utilisateur**, pas factorisés dans une table "instances" séparée — même principe "pas de sur-ingénierie" déjà appliqué ailleurs sur ce projet (règle des 3 répétitions, section 6), réévaluable si le nombre d'instances grossit vraiment.
+- **Les identifiants MySQL applicatifs (le compte technique utilisé par le conteneur PHP pour se connecter, ex. `crm_user`) restent volontairement absents de cette table** — ce sont des identifiants d'infrastructure, pas une donnée par utilisateur. Ils continuent de vivre dans les variables d'environnement du conteneur, un compte par instance avec des droits sur toutes les bases qu'elle héberge. MIRADOR ne dit donc que QUELLE base rejoindre, jamais AVEC QUEL compte technique s'y connecter. **Confirmé/simplifié le 30 août 2026 (section 24) : Jean-Marc a choisi de dupliquer le même compte `crm_user` (mêmes identifiants) sur toutes les instances, ce qui évite toute logique de correspondance host→identifiants côté code.**
+- **`MIR_MDPHash` plutôt que `MIR_MDP`**, choix de nommage délibéré pour ne jamais confondre avec l'ancienne convention en clair (`USR_MDP`, voir section 2).
+- **`MIR_Actif`** : suppression logique, même principe universel déjà appliqué sur `CNT_Actif`/`PSP_Actif`.
+
+**Abandon du mot de passe en clair.** Le compromis assumé depuis le 19 août sur `ASP_Users.USR_MDP` ("à revoir si ASPIC est un jour proposée à un client externe", section 2) est explicitement revu ici : MIRADOR stocke un hash bcrypt (`password_hash()`/`password_verify()` en PHP), pas un mot de passe en clair — déclenché précisément par l'arrivée de bêta testeurs externes.
+
+**Hébergement de MIRADOR — décision et raisonnement.** MIRADOR est hébergée sur l'instance MySQL actuelle (celle qui portera aussi MS-DEV/MS-EXP), plutôt que sur une instance dédiée dès le départ, malgré un risque théorique réel identifié en discussion : une indisponibilité de cette instance couperait l'authentification de tout le monde, y compris de futurs bêta testeurs dont les données réelles seraient pourtant intactes sur l'instance 2. Ce risque n'est pas jugé réel tant qu'aucun bêta testeur ne dépend effectivement du service — même logique que la règle des répétitions déjà appliquée ailleurs sur ce projet (généraliser/isoler à partir du besoin réel constaté, pas par anticipation). **Déclencheur retenu pour la migration future vers une instance dédiée : avant l'onboarding du premier vrai bêta testeur**, pas la date d'activation technique de `aspic.bzh` elle-même (un délai peut s'écouler entre les deux). Migration anticipée comme peu coûteuse le moment venu (table probablement très petite, export/import + changement de paramètres de connexion côté appli). Bonne pratique retenue indépendamment de la topologie : le compte MySQL applicatif qui interroge MIRADOR devrait être un compte à part, avec des droits limités à cette seule base — pas encore mis en place, à faire à la création réelle de la base. **⚠️ Choix révisé le 30 août 2026 (section 24) : MIRADOR a en réalité été dupliquée sur une deuxième instance (`mysql2`), pas hébergée sur la première comme envisagé ici — l'app interroge désormais cette copie sur `mysql2`.**
+
+**Génération des mots de passe hashés — pas de nouvel outil nécessaire.** Question posée par Jean-Marc : un hash en base nécessite-t-il un petit logiciel d'administration, contrairement au mot de passe en clair qu'il pouvait taper directement dans phpMyAdmin ? Réponse : non, `MIR_Users` reste une table "gérée à la main" comme les autres tables de référence, à un détail près — le hash doit être calculé par PHP (`password_hash()`), pas par phpMyAdmin. Geste ajouté : une commande `docker exec -it <nom_du_conteneur> php -r "echo password_hash('...', PASSWORD_DEFAULT) . PHP_EOL;"` (nom réel du conteneur à vérifier avec `docker ps`, le nom du service dans `docker-compose.yml` n'étant pas forcément le nom réel du conteneur — **confirmé le 30 août 2026 : le conteneur ASPIC se nomme `aspic-crm-app-1`, service `crm-app` défini dans `/docker/aspic/docker-compose.yml`, voir section 23**), dont le résultat est ensuite collé tel quel dans `MIR_MDPHash` via phpMyAdmin. **Un vrai outil d'administration (formulaire dédié) sera envisagé seulement si l'onboarding de bêta testeurs devient fréquent** — même règle des répétitions.
+
+**Contournement pratique du jour.** La console Hostinger (accès terminal embarqué dans le panneau web) refusait de s'ouvrir au moment de générer le premier hash (souci déjà rencontré par Jean-Marc par le passé, non résolu ici — relève du projet de gestion du serveur ; piste donnée : essayer un accès SSH direct depuis un vrai terminal plutôt que la console web, `ssh -l "email@domaine" ip_vps` si l'identifiant est une adresse mail contenant un `@`). En attendant, le hash du tout premier utilisateur MIRADOR (Jean-Marc lui-même) a été généré directement dans l'environnement de travail de Claude (PHP 8.4 disponible, format bcrypt identique et compatible avec le PHP 8.3 de production), vérifié par un aller-retour `password_hash()`/`password_verify()` avant transmission. Jean-Marc a ensuite créé la ligne correspondante dans `MIR_Users` manuellement et testé avec succès ("Carton plein !"). **Ce souci de console Hostinger est résolu depuis (30 août 2026) : Jean-Marc dispose maintenant d'un accès terminal fonctionnel avec clé SSH paramétrée sur le VPS — voir section 23, où cet accès a servi à un tout autre usage (push GitHub) mais lève au passage cette limitation.**
+
+**⚠️ Point de vigilance important pour la suite : MIRADOR n'est à ce stade qu'un schéma discuté avec une seule ligne de test — aucun code applicatif ne la consulte encore.** Le login réel d'ASPIC (`aspic.php`) continue de fonctionner exactement comme avant (vérification directe contre `ASP_Users` de la base cible). Le branchement effectif de l'écran d'identification sur MIRADOR (interroger MIRADOR en premier, puis router vers la base cible) reste entièrement à faire. **Fait le 30 août 2026 — voir section 24.**
+
+**Numéro de version applicatif (`V1.000`, livré et validé en production le 28 août 2026).** Fonctionnalité demandée par Jean-Marc en cours de session : afficher discrètement, sur l'écran d'identification et sur l'écran liste des contacts, le numéro de version du code déployé sur l'environnement consulté.
+
+*Décision de conception : source locale à chaque environnement, pas centralisée dans MIRADOR.* Le numéro reflète le code réellement déployé sur CET environnement précis (MS-DEV, MS-EXP, ou plus tard une base bêta testeur), justement pour repérer un déploiement resté en retard — exactement le genre de souci déjà rencontré avec le bug du logo du 26 août 2026 (section 18), où un fichier périmé était resté en place sans qu'on le voie tout de suite. Une valeur centralisée dans MIRADOR aurait affiché le même numéro partout, quel que soit l'état réel du code déployé à chaque endroit — inutile pour cet objectif.
+
+*Fichier livré :* `version.php`, nouveau, à la racine — porte la constante `ASPIC_VERSION` et sert aussi de mini-endpoint public JSON (`{"version":"V1.000"}`), sans session requise (consulté aussi depuis l'écran d'identification, avant toute connexion).
+
+*Format retenu :* `V<majeur>.<compteur sur 3 chiffres>` (ex. `V1.000`), incrémenté par Jean-Marc **à la main, une seule fois en fin de session, juste avant de pousser sur GitHub** — pas à chaque fichier reçu en cours de travail (une soirée peut compter jusqu'à 6 versions d'un même fichier avant d'être figée). **Convention retenue pour l'avenir : faire figurer ce numéro dans le message de commit GitHub au moment du push**, pour relier directement "ce qu'affiche l'appli" à "l'état exact du code sur GitHub à ce moment-là" — pas appliqué au tout premier push de ce soir (Jean-Marc a poussé sans message personnalisé, "je ferai ça la prochaine fois"). **Convention effectivement appliquée pour la première fois le 30 août 2026 — voir section 23, messages de commit `"Réconciliation avec la production réelle - V1.001 (...)"` et `"V1.002 - Bandeau identification : Ingenierie devient Intelligence"`.**
+
+*Placement, deux itérations sur l'écran liste des contacts.* Premier essai en tout premier élément de la barre de statut du bas (`#statut`), suivant la demande initiale de Jean-Marc ("ligne du bas à gauche") — repéré après coup comme peu visible (couleur trop proche du fond de la barre, et Jean-Marc regardait en fait plutôt à droite). Deuxième essai avec `margin-left:auto` pour plaquer l'élément à droite du flux flex — jugé encore "en plein milieu" par Jean-Marc, l'espace du repère de largeur de scrollbar partagé avec la liste laissant une marge après l'élément. **Version finale :** élément sorti du flux flex, positionné en absolu contre le bord droit réel de la barre (juste avant `--sb-width`, la variable CSS déjà utilisée pour mesurer dynamiquement la largeur de l'ascenseur — section 19), couleur assombrie (`#4a4a4a`) et mise en gras pour un contraste suffisant sur le fond clair de la barre. Sur l'écran d'identification, la bande `.footer-line` — présente dans le code depuis le tout premier jet de l'écran (section 8), marquée "optionnelle, à confirmer" dans le CSS sans jamais avoir été utilisée — porte désormais ce numéro, en bas à droite, sans itération nécessaire côté positionnement.
+
+*Tests effectués avant chaque livraison :* `php -l` sur `version.php`, `node --check` sur le JavaScript extrait des deux écrans, équilibre des balises `<div>` (23/23 et 104/104, inchangé), et un test fonctionnel réel via un serveur PHP local (`php -S`) et Playwright (capture d'écran + lecture du texte affiché) — rendu possible par un accès en lecture au dépôt GitHub (voir ci-dessous), qui a évité de redemander les fichiers à jour à Jean-Marc.
+
+**Validé par Jean-Marc en production sur `aspic.mvl-tls.fr` le 28 août 2026 ("Carton plein !").** Point de méthode à noter au passage : un premier test de Jean-Marc n'avait pas vu le numéro sur l'écran liste des contacts alors qu'il était bien affiché — il regardait à droite, l'élément était encore à gauche à ce moment de l'itération. Pas un bug, une histoire de placement pas encore convergé avec son attente.
+
+**Accès en lecture au dépôt GitHub, deuxième utilisation (28 août 2026, soir).** Le mécanisme déjà établi le 28 août matin (section 20) a été réutilisé avec succès : Jean-Marc a transmis un token d'accès personnel pour cloner le dépôt en lecture dans l'environnement de travail de Claude. **Point de vigilance signalé par Claude, pas encore acté par Jean-Marc :** ce token (`Claude-ASPIC`) a été généré sans date d'expiration — suggestion de le régénérer en lecture seule avec une expiration raisonnable, l'écriture n'apportant rien puisqu'elle reste de toute façon bloquée côté proxy git pour cette session (section 20). **Refus explicite de Claude de stocker ce token dans un document du projet**, à la demande de Jean-Marc qui voulait s'éviter d'avoir à le recopier à chaque session : un token sans expiration avec droits d'écriture, stocké en clair dans un document potentiellement relu par une session future, représente un risque disproportionné par rapport au gain de confort — un gestionnaire de mots de passe reste la solution recommandée côté Jean-Marc. **Ce token a été retransmis en session le 30 août 2026 pour un nouveau clone en lecture (section 23) — toujours pas stocké, même principe reconduit.**
+
+**Procédure de mise à jour du dépôt GitHub, clarifiée (28 août 2026).** Jean-Marc dépose ses fichiers via glisser-déposer sur l'interface web GitHub ("Add file" → "Upload files"). Confirmé : déposer un fichier qui porte le même nom qu'un fichier déjà présent au même chemin est traité comme une modification (l'historique complet reste consultable), pas comme une suppression suivie d'une recréation — pas besoin de supprimer quoi que ce soit au préalable. Point de discipline retenu pour la suite (pas appliqué ce soir) : personnaliser le message de commit à chaque envoi, idéalement en y faisant figurer le numéro de version de l'application au moment du push (voir plus haut). **⚠️ Cette procédure de glisser-déposer web est abandonnée le 30 août 2026 au profit d'un `git push` en SSH directement depuis le VPS — voir section 23. Jean-Marc a lui-même signalé ne pas avoir été très à l'aise avec le glisser-déposer, ce qui a motivé le changement.**
+
+**Reste à faire, plus tard :**
+
+- ~~Créer réellement la base MIRADOR et sa table `MIR_Users` en production~~ **Fait — MIRADOR dupliquée sur `mysql2` (section 24).**
+- ~~Réécrire `aspic.php` (écran d'identification) pour consulter MIRADOR en premier, avant de router vers la base cible~~ **Fait le 30 août 2026 — section 24.**
+- Renommer la base ASPIC actuelle en `MS-DEV` côté MySQL et mettre à jour le `docker-compose.yml` du bac à sable en conséquence (`DB_NAME`). **Nuancé le 30 août 2026 : MS-DEV a finalement été créée par clonage à côté de l'ASPIC existante (conservée en filet de sécurité), pas par renommage — voir section 24.**
+- Créer la base `MS-EXP` pour l'usage personnel de Jean-Marc sur `aspic.bzh`, une fois le nom de domaine actif. **Toujours à faire — la base créée le 30 août pour les tests est `MS-TST`, pas `MS-EXP` (section 24).**
+- Monter la deuxième instance MySQL destinée aux bêta testeurs, et réfléchir à un processus de création de leurs bases (à la main via phpMyAdmin pour commencer, script de provisioning si le volume le justifie un jour). **Deux instances supplémentaires montées entre-temps (mysql2, mysql3) — section 24.**
+- Régénérer le token GitHub `Claude-ASPIC` en lecture seule avec expiration (suggestion de Claude, en attente de décision de Jean-Marc).
+- ~~Prendre l'habitude d'un message de commit descriptif (incluant le numéro de version) à chaque push GitHub.~~ **Fait pour la première fois le 30 août 2026 (section 23) — à confirmer que ça devient systématique.**
+- Migrer MIRADOR vers une instance MySQL dédiée avant l'onboarding du premier vrai bêta testeur (pas avant).
+- ~~Vérifier/corriger le compte de démonstration encore présent dans `identification.html`~~ **Retiré le 30 août 2026 (section 24).**