JWT_SECRET retombait sur "data-sentinel-secret-change-in-prod", une valeur
lisible par quiconque a accès au code : un oubli de configuration suffisait
à permettre de forger un jeton d'administrateur.
Sans JWT_SECRET, une clé aléatoire est désormais tirée au démarrage, avec un
avertissement explicite. Le démarrage n'est volontairement pas bloqué : un
oubli de variable d'environnement ne doit pas transformer une configuration
incomplète en indisponibilité totale du service. Contrepartie assumée et
documentée : les sessions ne survivent pas à un redémarrage tant que la
variable n'est pas définie.
Vérifié : la production signe déjà avec un secret propre, ce correctif ne
change donc rien à son fonctionnement.
Ajoute par ailleurs APP_BUILD, injecté par la CI depuis le SHA du commit et
exposé par GET /health (et /version.json côté front). Jusqu'ici, rien ne
permettait de savoir quelle version tournait réellement : un déploiement
non appliqué était indiscernable d'un déploiement réussi.
Le repli de développement pointait en dur sur LaptopCA\SQLEXPRESS,
ce qui rendait l'API inutilisable sur toute autre machine sans éditer
le code. Le serveur vient désormais de DB_SERVER (défaut localhost),
et DB_TRUSTED_CONNECTION permet de forcer l'authentification Windows.
DB_PORT peut rester vide : une instance nommée (MonPoste\SQLEXPRESS)
se joint sans port explicite.
Antho
neckfire