lecoffre-back-mini/docs/hmr-idnot-dev3-state-2025-09-24.md

Flux HMR avec idnot via dev3 et state (24/09/2025)

Objectif

• Maintenir le HMR côté front (Next.js) sans casser le parcours d’auth idnot en s’appuyant sur un state serveur.

Acteurs / Ports

• Front (Next.js, HMR): :3000
• Backend mini: :8080
• Nginx dev3: dev3.4nkweb.com (443/80), reverse vers 8080/300x/8090
• Callback idnot: https://dev3.4nkweb.com/idnot/callback

Création du state (front → back)

• Route: POST /api/v1/idnot/state (via src/routes/index.ts → StateHandlers.createState).
• Le back génère un state persisté côté serveur (via SessionManager) et le retourne au front.
• CORS dynamique (src/config/index.ts) autorise https://*.4nkweb.com et l’APP_HOST.

Redirection idnot

• Le front redirige l’utilisateur vers idnot avec le state fourni.
• idnot renvoie ensuite vers https://dev3.4nkweb.com/idnot/callback?code=...&state=....

Callback via Nginx dev3 → backend

• confs/nginx/dev3.4nkweb.com.conf: location = /idnot/callback → proxy_pass backend :8080.
• Le back (route GET /idnot/callback) lit state, vérifie côté SessionManager, consomme code, finalise login/attachement.

Pourquoi le HMR ne casse pas le flow

• Le couplage se fait via le state stocké à chaud côté serveur, pas via l’état volatile du front.
• Même si le front change de bundle (HMR), le state reste valide jusqu’au callback.
• CORS permet au front HMR d’appeler le back sans friction.

Rôle de dev3

• Point d’entrée HTTPS stable pour le callback.
• Reverse proxy vers 8080 (back), 300x (front), 8090 (relay), avec 80 → 301 → HTTPS.
• Gère les réécritures nécessaires (ex: /storage).

Résultat

• HMR actif, parcours idnot fiable: le state maintenu côté back assure la continuité entre redirection et callback.