@eqs/auth : creerAuth n'expose pas cookiePrefix — deux satellites sur *.equilibre-structures.fr se volent leur cookie de session #153

Open
opened 2026-10-14 14:27:37 +00:00 by nicolas-fryder · 0 comments

Constat (production ATLAS, 2026-10-14, premier jour après le rétrofit)

Une autre application better-auth du domaine (HQ, better-auth 1.6) pose __Secure-better-auth.session_token sur le domaine parent .equilibre-structures.fr. Le navigateur l'envoie donc à atlas.equilibre-structures.fr sous le même nom que le cookie de session d'Atlas.

Effets observés :

  • le proxy de l'atlas (src/proxy.ts, qui ne fait que constater la présence du cookie, comme le profil next-fullstack le recommande) ouvrait l'interface ;
  • chaque route gardée rendait 401 (Authentification requise), puisque ce jeton n'est pas une session d'Atlas ;
  • une vraie connexion se faisait masquer par le cookie de l'autre application (deux cookies homonymes, le navigateur envoie celui du domaine parent).

Mesuré : select count(*) from session where "createdAt" > now() - interval '30 minutes' → 0, alors que le navigateur portait un …session_token. En navigation privée (sans le cookie de HQ), la connexion fonctionnait.

Cause dans le socle

creerAuth (dist/better-auth.js, bloc advanced) ne transmet pas advanced.cookiePrefix à better-auth : tous les satellites s'appellent better-auth.*. Et better-auth calcule authCookies / createAuthCookie avant le init des greffons (context/create-context.mjs l. 96 et 205, runPluginInit l. 229 ne les recalcule pas) : un satellite ne peut pas corriger en passant l'option par un greffon seul.

Contournement côté ATLAS (commit 6aa5de3)

Greffon cookiesAtlas (src/lib/cookiesAtlas.ts), en tête des greffons : pose cookiePrefix: 'atlas' ET rend dans context authCookies: getCookies(options) et createAuthCookie: createCookieGetter(options) recalculés. Le proxy cherche atlas.session_token / __Secure-atlas.session_token. Porte src/lib/cookiesAtlas.test.ts.

Attendu

  • creerAuth({ env: { …, AUTH_COOKIE_PREFIX } }) (ou une option cookiePrefix), avec un défaut par satellite (le SERVICE_NAME ?) plutôt que better-auth : deux applications du socle sur un même domaine parent ne doivent pas pouvoir se marcher dessus par défaut.
  • Que le profil next-fullstack (creerProxy, et la doc du proxy) dérive le nom du cookie de la même source, au lieu d'un better-auth.session_token en dur.
  • Une règle de conformité ? (auth.cookie-prefixe : le cookie de session ne s'appelle pas better-auth.*).

Note : tout satellite déjà en production qui change de préfixe déconnecte ses sessions une fois (vécu chez ATLAS, acceptable).

## Constat (production ATLAS, 2026-10-14, premier jour après le rétrofit) Une autre application better-auth du domaine (HQ, better-auth 1.6) pose `__Secure-better-auth.session_token` sur le domaine **parent** `.equilibre-structures.fr`. Le navigateur l'envoie donc à `atlas.equilibre-structures.fr` **sous le même nom** que le cookie de session d'Atlas. Effets observés : - le proxy de l'atlas (`src/proxy.ts`, qui ne fait que constater la présence du cookie, comme le profil next-fullstack le recommande) ouvrait l'interface ; - chaque route gardée rendait 401 (`Authentification requise`), puisque ce jeton n'est pas une session d'Atlas ; - une vraie connexion se faisait masquer par le cookie de l'autre application (deux cookies homonymes, le navigateur envoie celui du domaine parent). Mesuré : `select count(*) from session where "createdAt" > now() - interval '30 minutes'` → 0, alors que le navigateur portait un `…session_token`. En navigation privée (sans le cookie de HQ), la connexion fonctionnait. ## Cause dans le socle `creerAuth` (`dist/better-auth.js`, bloc `advanced`) ne transmet pas `advanced.cookiePrefix` à better-auth : tous les satellites s'appellent `better-auth.*`. Et better-auth calcule `authCookies` / `createAuthCookie` **avant** le `init` des greffons (`context/create-context.mjs` l. 96 et 205, `runPluginInit` l. 229 ne les recalcule pas) : un satellite ne peut pas corriger en passant l'option par un greffon seul. ## Contournement côté ATLAS (commit 6aa5de3) Greffon `cookiesAtlas` (`src/lib/cookiesAtlas.ts`), en tête des greffons : pose `cookiePrefix: 'atlas'` ET rend dans `context` `authCookies: getCookies(options)` et `createAuthCookie: createCookieGetter(options)` recalculés. Le proxy cherche `atlas.session_token` / `__Secure-atlas.session_token`. Porte `src/lib/cookiesAtlas.test.ts`. ## Attendu - `creerAuth({ env: { …, AUTH_COOKIE_PREFIX } })` (ou une option `cookiePrefix`), avec un **défaut par satellite** (le `SERVICE_NAME` ?) plutôt que `better-auth` : deux applications du socle sur un même domaine parent ne doivent pas pouvoir se marcher dessus par défaut. - Que le profil `next-fullstack` (`creerProxy`, et la doc du proxy) dérive le nom du cookie de la même source, au lieu d'un `better-auth.session_token` en dur. - Une règle de conformité ? (`auth.cookie-prefixe` : le cookie de session ne s'appelle pas `better-auth.*`). Note : tout satellite déjà en production qui change de préfixe déconnecte ses sessions une fois (vécu chez ATLAS, acceptable).
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Infrastructure/eqs-platform#153
No description provided.