38 lines
1.8 KiB
Markdown
38 lines
1.8 KiB
Markdown
# 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.
|
||
|