Le déploiement restait bloqué sur ENCRYPTION_KEY. J'ai tenu trop longtemps la position « pas de valeur par défaut », en confondant deux choses : refuser une clé livrée avec l'image — ce qui reste juste, une clé publiée dans un dépôt ne protège rien — et exiger qu'un humain en fabrique une avant tout démarrage. Une variable d'environnement n'est d'ailleurs pas un bon coffre : elle s'affiche dans `docker inspect` et dans l'interface de gestion. Un fichier produit au démarrage, dans un volume distinct de la base et des documents, n'est pas moins protégé — et une sauvegarde de l'un n'emporte plus la clé de l'autre. Le point d'entrée la produit donc si elle manque, l'écrit en 0600, et l'affiche une fois dans les journaux avec ce qu'il faut en faire. Une clé fournie explicitement l'emporte toujours : un déploiement qui gère ses secrets ailleurs ne doit pas être contrarié. La pile démarre désormais sans aucune variable. Éprouvé sur le script lui-même : première exécution, clé de 32 octets produite et annoncée ; deuxième, reprise en silence depuis le fichier ; avec une clé fournie, le fichier reste intact. Corrigé au passage, révélé par un échec transitoire du test : une écriture disque impossible — volume plein, droits, montage absent — remontait en exception non traitée. L'écran restait muet, la pièce n'était pas déposée et rien ne le disait. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Cr9dkEHwbDgkWPnyGj1Rjv
51 lines
2.3 KiB
Bash
51 lines
2.3 KiB
Bash
# Copier vers .env et renseigner. Ne jamais committer .env.
|
|
|
|
# --- Base de données --------------------------------------------------------
|
|
POSTGRES_USER=planflow
|
|
# Une valeur par défaut existe dans docker-compose.yml : la base n'étant jamais
|
|
# publiée ni attachée au réseau du reverse-proxy, ce mot de passe protège d'un
|
|
# conteneur voisin, pas d'Internet. Le changer reste recommandé.
|
|
POSTGRES_PASSWORD=change-me
|
|
POSTGRES_DB=planflow
|
|
|
|
# Compte de connexion de l'application. Distinct du superutilisateur
|
|
# d'amorçage : un superutilisateur contourne la row-level security, y compris
|
|
# déclarée en FORCE, et l'isolation ne reposerait plus que sur la couche
|
|
# applicative. Créé au premier démarrage par docker/init-app-role.sh.
|
|
APP_DB_USER=planflow_app
|
|
APP_DB_PASSWORD=change-me-aussi
|
|
|
|
# Connexion administrative, utilisée uniquement par le harnais de tests de bout
|
|
# en bout. Inutile en production.
|
|
# ADMIN_DATABASE_URL=postgresql://planflow@localhost:5432/planflow
|
|
|
|
# Utilisée par l'application et par Prisma.
|
|
# En docker-compose l'hôte est `db` ; en développement local, `localhost`.
|
|
DATABASE_URL=postgresql://planflow:change-me@localhost:5432/planflow
|
|
|
|
# --- Chiffrement ------------------------------------------------------------
|
|
# Chiffre au repos les colonnes sensibles exigées par PLAN.md §3.6 :
|
|
# NIR, IBAN, BIC. 32 octets en base64.
|
|
#
|
|
# openssl rand -base64 32
|
|
#
|
|
# En docker-compose, la laisser vide suffit : elle est produite au premier
|
|
# démarrage et conservée dans le volume `secrets`.
|
|
#
|
|
# Cette clé vit hors de la base : une sauvegarde volée ne doit pas suffire à
|
|
# lire ces colonnes. La perdre rend les données chiffrées irrécupérables —
|
|
# la sauvegarder séparément et documenter sa rotation.
|
|
ENCRYPTION_KEY=
|
|
|
|
# --- Application ------------------------------------------------------------
|
|
APP_URL=http://localhost:9317
|
|
# Port publié sur l'hôte. Peu courant à dessein : le service passe normalement
|
|
# par le reverse-proxy, qui joint le conteneur sur son port 3000.
|
|
APP_PORT=9317
|
|
|
|
# --- Pièces du dossier salarié ----------------------------------------------
|
|
# Répertoire de stockage, chiffré au repos avec ENCRYPTION_KEY.
|
|
# En docker-compose il vaut /data/documents, sur un volume nommé — ne pas le
|
|
# changer sans déplacer le volume, les pièces déjà déposées y resteraient.
|
|
DOCUMENT_STORE=./storage/documents
|