Claude
ef2868b980
Trois problèmes, dont un grave, trouvés en corrigeant un échec de déploiement. **Le compose connectait l'application en superutilisateur PostgreSQL.** Un superutilisateur contourne toute politique de sécurité au niveau ligne, y compris déclarée en FORCE : la seconde couche d'isolation était présente en base et absente des faits. Le README l'interdisait déjà noir sur blanc ; le chemin de déploiement que nous livrons faisait exactement l'inverse. Un script d'initialisation crée désormais un rôle `planflow_app` NOSUPERUSER NOBYPASSRLS, propriétaire de la base — il lui faut ce droit pour migrer, et les politiques sont en FORCE précisément pour s'appliquer aussi au propriétaire. Mesuré : en superutilisateur, deux lignes visibles sans compte courant ; avec le rôle dédié, zéro. Basculer la base de développement sur ce même rôle a révélé le défaut que le superutilisateur masquait : `resolveSession` lisait `Membership`, table filtrée par compte, sans périmètre. Avec la RLS active, plus personne ne pouvait se connecter. La résolution passe maintenant par une porte étroite — une politique qui n'ouvre que les lignes dont l'utilisateur est titulaire, sous `app.user_id` — le temps de trouver le compte, puis repasse par le périmètre ordinaire. La suite de tests traverse enfin la RLS au lieu de la contourner. **Les pièces du dossier salarié n'avaient aucun volume.** Elles étaient écrites dans la couche du conteneur et disparaissaient au premier redéploiement. Une pièce d'identité perdue ne se reconstitue pas. Le reste répond à la demande : Postgres préconfiguré — la base n'étant ni publiée ni attachée au réseau du proxy, ce mot de passe protège d'un conteneur voisin, pas d'Internet — réseau `nginx_default` déclaré externe avec l'application seule dessus, et port publié peu courant. ENCRYPTION_KEY reste la seule variable sans valeur par défaut, et n'en aura pas : elle chiffre le NIR, l'IBAN et les arrêts de travail. Une clé livrée avec l'image serait connue de quiconque lit ce dépôt. Au démarrage, l'application contrôle ses propres privilèges : elle refuse de se lancer si la base porte plus d'un compte, et se contente d'un avertissement s'il n'y en a qu'un — bloquer une installation mono-compte fermerait l'accès de l'entreprise à ses données pour une fuite entre clients qui ne peut pas se produire. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Cr9dkEHwbDgkWPnyGj1Rjv
28 lines
1.0 KiB
TypeScript
28 lines
1.0 KiB
TypeScript
import { PrismaPg } from '@prisma/adapter-pg';
|
|
import { PrismaClient } from '@prisma/client';
|
|
|
|
/**
|
|
* Connexion administrative, pour la mise en place des tests d'intégration.
|
|
*
|
|
* L'application se connecte avec un rôle **soumis à la row-level security** :
|
|
* il ne voit rien hors du compte courant, et ne peut pas créer de compte de
|
|
* toutes pièces. C'est exactement ce qu'on attend de lui.
|
|
*
|
|
* Ces tests fabriquent pourtant des comptes entiers pour éprouver l'isolation
|
|
* entre eux. Ils passent donc par la connexion d'amorçage, comme le ferait un
|
|
* exploitant depuis le serveur — jamais par celle de l'application, dont la
|
|
* limitation est le sujet même de plusieurs de ces tests.
|
|
*/
|
|
export function adminDatabaseUrl(): string {
|
|
return process.env.ADMIN_DATABASE_URL ?? process.env.DATABASE_URL ?? '';
|
|
}
|
|
|
|
let client: PrismaClient | null = null;
|
|
|
|
export function adminPrisma(): PrismaClient {
|
|
client ??= new PrismaClient({
|
|
adapter: new PrismaPg({ connectionString: adminDatabaseUrl() }),
|
|
});
|
|
return client;
|
|
}
|