Rendre le déploiement Docker correct, et la RLS réellement active

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
2026-08-09 08:39:54 +00:00
1 parent ba6482d4ff
commit ef2868b980
@@ -3,7 +3,7 @@ import { cookies } from 'next/headers';

 import type { Actor, Scope } from '@/domain/access/authorize';
 import { generateToken, hashToken } from '@/server/crypto';
-import { unscoped } from '@/server/tenant';
+import { unscoped, withTenant, withUser } from '@/server/tenant';

 /**
 * Sessions serveur — PLAN.md §2 (écart assumé) et matrice n° 23.
@@ -247,22 +247,11 @@ export async function resolveSession(
 ): Promise<SessionContext | null> {
  const db = unscoped();

+  // `Session` et `User` ne portent pas de compte : ce sont les seules tables
+  // lisibles avant de savoir de quel compte il s'agit.
  const session = await db.session.findUnique({
    where: { tokenHash: hashToken(token) },
-    include: {
-      user: {
-        include: {
-          memberships: {
-            where: { status: 'ACTIVE', archivedAt: null },
-            include: {
-              account: { select: { name: true } },
-              role: { include: { permissions: { include: { permission: true } } } },
-              scopes: true,
-            },
-          },
-        },
-      },
-    },
+    include: { user: true },
  });

  // Une session en attente du second facteur ne résout aucun acteur : elle ne
@@ -277,45 +266,70 @@ export async function resolveSession(
    return null;
  }

-  const membership = session.user.memberships[0];
-  if (!membership) return null;
+  // Amorçage : trouver le compte suppose de lire le rattachement, lequel est
+  // filtré par compte. La porte est étroite — seules les lignes dont cet
+  // utilisateur est titulaire — et ne sert qu'ici.
+  const membershipId = await withUser(session.userId, async (tx) => {
+    const own = await tx.membership.findFirst({
+      where: { userId: session.userId, status: 'ACTIVE', archivedAt: null },
+      select: { id: true, accountId: true },
+    });
+    return own;
+  });

-  const scope: Scope = {
-    allLocations: membership.scopes.some((entry) => entry.allLocations),
-    locationIds: membership.scopes
-      .map((entry) => entry.locationId)
-      .filter((id): id is string => id !== null),
-    teamIds: membership.scopes
-      .map((entry) => entry.teamId)
-      .filter((id): id is string => id !== null),
-  };
+  if (!membershipId) return null;

-  const actor: Actor = {
-    membershipId: membership.id,
-    accountId: membership.accountId,
-    userId: session.user.id,
-    roleKey: membership.role.key,
-    permissions: new Set(
-      membership.role.permissions.map((entry) => entry.permission.code),
-    ),
-    scope,
-  };
+  // Tout le reste passe par le périmètre du compte, comme n'importe quelle
+  // lecture métier.
+  return withTenant(membershipId.accountId, async (tx) => {
+    const membership = await tx.membership.findUnique({
+      where: { id: membershipId.id },
+      include: {
+        account: { select: { name: true } },
+        role: { include: { permissions: { include: { permission: true } } } },
+        scopes: true,
+      },
+    });

-  const { firstName, lastName, email } = session.user;
+    if (!membership) return null;

-  return {
-    actor,
-    sessionId: session.id,
-    user: {
-      firstName,
-      lastName,
-      email,
-      initials: `${firstName.charAt(0)}${lastName.charAt(0)}`.toUpperCase(),
-      mfaEnrolled: session.user.mfaEnrolledAt !== null,
-    },
-    accountName: membership.account.name,
-    roleName: membership.role.name,
-  };
+    const scope: Scope = {
+      allLocations: membership.scopes.some((entry) => entry.allLocations),
+      locationIds: membership.scopes
+        .map((entry) => entry.locationId)
+        .filter((id): id is string => id !== null),
+      teamIds: membership.scopes
+        .map((entry) => entry.teamId)
+        .filter((id): id is string => id !== null),
+    };
+
+    const actor: Actor = {
+      membershipId: membership.id,
+      accountId: membership.accountId,
+      userId: session.userId,
+      roleKey: membership.role.key,
+      permissions: new Set(
+        membership.role.permissions.map((entry) => entry.permission.code),
+      ),
+      scope,
+    };
+
+    const { firstName, lastName, email } = session.user;
+
+    return {
+      actor,
+      sessionId: session.id,
+      user: {
+        firstName,
+        lastName,
+        email,
+        initials: `${firstName.charAt(0)}${lastName.charAt(0)}`.toUpperCase(),
+        mfaEnrolled: session.user.mfaEnrolledAt !== null,
+      },
+      accountName: membership.account.name,
+      roleName: membership.role.name,
+    };
+  });
 }

 /** Session courante depuis le cookie, ou `null`. */
@@ -131,10 +131,36 @@ export async function withTenant<T>(
  });
 }

+/**
+ * Exécute `fn` au nom d'un utilisateur, **avant** que son compte soit connu.
+ *
+ * Sert au seul amorçage de session : trouver à quel compte un utilisateur
+ * appartient suppose de lire son rattachement, et le rattachement est
+ * lui-même filtré par compte. Sans cette porte étroite, la seule issue serait
+ * de connecter l'application avec un rôle qui contourne la RLS — c'est-à-dire
+ * de la désactiver partout pour résoudre un cas d'amorçage.
+ *
+ * La politique associée n'ouvre que les lignes dont l'utilisateur est le
+ * titulaire (voir la migration `membership_self_read`).
+ */
+export async function withUser<T>(
+  userId: string,
+  fn: (db: ScopedClient) => Promise<T>,
+): Promise<T> {
+  return prisma.$transaction(async (tx) => {
+    await tx.$executeRaw`SELECT set_config('app.user_id', ${userId}, true)`;
+    return fn(tx as unknown as ScopedClient) as Promise<T>;
+  });
+}
+
 /**
 * Accès sans portée de compte, pour les opérations qui précèdent l'identité :
 * authentification par e-mail, acceptation d'invitation, migrations.
 *
+ * Ne donne accès qu'aux tables **sans** colonne `accountId` — sessions,
+ * utilisateurs, codes de secours. Les autres restent filtrées par la RLS, qui
+ * ne laisse rien passer hors d'une transaction scopée.
+ *
 * Volontairement nommé pour se voir en revue de code.
 */
 export function unscoped(): PrismaClient {