From 91ed42e87923f749a54ceb8ebb39cfea325edc5c Mon Sep 17 00:00:00 2001 From: Debian Dev4 Date: Thu, 25 Sep 2025 15:25:00 +0000 Subject: [PATCH] auto_clea --- README.md | 3 + docs/ARCHITECTURE.md | 21 -- docs/CORRECTIONS_APPLIQUEES.md | 38 ---- docs/DEPLOIEMENT.md | 20 -- docs/DEPLOYMENT_FIXES_2025-09-24.md | 81 ------- docs/ENV-RESUME.md | 30 --- docs/FLUX.md | 6 - docs/FONCTIONNEL.md | 15 -- docs/HMR_IDNOT_STATE.md | 43 ---- docs/INSTALLATION.md | 26 --- docs/PORTS.md | 27 --- docs/QUALITE.md | 6 - docs/RESUME-ANALYSE.md | 159 ------------- docs/SECURITE.md | 6 - docs/TECHNIQUE.md | 19 -- docs/TODO.md | 6 - docs/VARIABLES-ENVIRONNEMENT.md | 336 ---------------------------- docs/ci.md | 115 ---------- docs/ext.md | 58 ----- 19 files changed, 3 insertions(+), 1012 deletions(-) delete mode 100644 docs/ARCHITECTURE.md delete mode 100644 docs/CORRECTIONS_APPLIQUEES.md delete mode 100644 docs/DEPLOIEMENT.md delete mode 100644 docs/DEPLOYMENT_FIXES_2025-09-24.md delete mode 100644 docs/ENV-RESUME.md delete mode 100644 docs/FLUX.md delete mode 100644 docs/FONCTIONNEL.md delete mode 100644 docs/HMR_IDNOT_STATE.md delete mode 100644 docs/INSTALLATION.md delete mode 100644 docs/PORTS.md delete mode 100644 docs/QUALITE.md delete mode 100644 docs/RESUME-ANALYSE.md delete mode 100644 docs/SECURITE.md delete mode 100644 docs/TECHNIQUE.md delete mode 100644 docs/TODO.md delete mode 100644 docs/VARIABLES-ENVIRONNEMENT.md delete mode 100644 docs/ci.md delete mode 100644 docs/ext.md diff --git a/README.md b/README.md index 965a1228..3c52f42d 100644 --- a/README.md +++ b/README.md @@ -36,3 +36,6 @@ You can check out [the Next.js GitHub repository](https://github.com/vercel/next The easiest way to deploy your Next.js app is to use the [Vercel Platform](https://vercel.com/new?utm_medium=default-template&filter=next.js&utm_source=create-next-app&utm_campaign=create-next-app-readme) from the creators of Next.js. Check out our [Next.js deployment documentation](https://nextjs.org/docs/deployment) for more details. + +### Documentation centralisée +- Les documents de ce projet sont centralisés dans: `/home/debian/4NK_env/docs/lecoffre-front/` diff --git a/docs/ARCHITECTURE.md b/docs/ARCHITECTURE.md deleted file mode 100644 index 0e6483fe..00000000 --- a/docs/ARCHITECTURE.md +++ /dev/null @@ -1,21 +0,0 @@ -# Architecture - LeCoffre Front - -## Composants -- Next.js (branche `ext`). -- Intègre `ihm_client` via iframe. - -## Dépendances -- Redirections IdNot (dev3.4nkweb.com). - -## Réseau et ports -- Servi via Nginx: `https://dev4.4nkweb.com/lecoffre/`. - -## Variables d’environnement (centralisées) -- `NEXT_PUBLIC_*` depuis `lecoffre_node/.env.master`. - -## Monitoring -- Logs Promtail → Loki. -- Dashboard Grafana: Frontend Services. - -## Notes -- Pas de `.env` local, utilisation variables runtime. diff --git a/docs/CORRECTIONS_APPLIQUEES.md b/docs/CORRECTIONS_APPLIQUEES.md deleted file mode 100644 index c57d5089..00000000 --- a/docs/CORRECTIONS_APPLIQUEES.md +++ /dev/null @@ -1,38 +0,0 @@ -# Corrections Appliquées - LeCoffre Front - -## Date: 20 Septembre 2025 - -### 🔧 Corrections Majeures - -#### 1. Problème de Healthcheck -**Problème:** Le healthcheck échouait car `curl` n'était pas installé et Next.js écoutait sur l'IP du conteneur. - -**Solution:** -- Changement du healthcheck pour vérifier le processus `next-server` -- Healthcheck: `ps aux | grep -v grep | grep next-server` -- Correction de l'entrypoint pour `npm start` - -**Fichiers modifiés:** -- `docker-compose.yml` - Healthcheck corrigé -- Configuration - Entrypoint optimisé - -#### 2. Installation des Outils -**Ajouté dans le Dockerfile:** -- `curl`, `git`, `wget`, `jq`, `telnet`, `npm`, `wscat` -- Outils de diagnostic et de connectivité - -#### 3. Configuration Next.js -- Port: 3000 (mappé sur 3004) -- Processus: `next-server` -- Healthcheck: Vérification du processus - -### 📊 État Actuel -- **Statut:** ✅ Healthy -- **Processus:** next-server en cours d'exécution -- **Port:** 3000 accessible sur 172.20.0.11 -- **URL:** https://dev4.4nkweb.com/lecoffre - -### 🔄 Prochaines Étapes -- Tests de connectivité frontend -- Monitoring des performances -- Optimisations supplémentaires diff --git a/docs/DEPLOIEMENT.md b/docs/DEPLOIEMENT.md deleted file mode 100644 index 8e831d12..00000000 --- a/docs/DEPLOIEMENT.md +++ /dev/null @@ -1,20 +0,0 @@ -# Déploiement - LeCoffre Front - -## Préparation -- Branche `ext`. -- `NEXT_PUBLIC_*` dans `lecoffre_node/.env.master`. - -## Déploiement (orchestrateur) -```bash -cd /home/debian/4NK_env/lecoffre_node -./scripts/start.sh | cat -./scripts/validate-deployment.sh | cat -``` - -## Vérifications -- `https://dev4.4nkweb.com/lecoffre/` s'affiche. -- Iframe `ihm_client` s'ouvre. - -## Règles -- Pas de compose direct. -- Push `ext` sans CI pour docs. diff --git a/docs/DEPLOYMENT_FIXES_2025-09-24.md b/docs/DEPLOYMENT_FIXES_2025-09-24.md deleted file mode 100644 index 0d2e9d1d..00000000 --- a/docs/DEPLOYMENT_FIXES_2025-09-24.md +++ /dev/null @@ -1,81 +0,0 @@ -# Corrections de déploiement - 24 septembre 2025 - -## Problèmes résolus - -### 1. Configuration Next.js conditionnelle -- **Problème**: `output: 'export'` et `basePath` appliqués en dev bloquaient HMR -- **Solution**: Configuration conditionnelle dans `next.config.js` - ```js - const isProd = process.env.NODE_ENV === 'production'; - const nextConfig = { - ...(isProd ? { - output: 'export', - basePath: '/lecoffre', - assetPrefix: '/lecoffre', - trailingSlash: true, - images: { unoptimized: true } - } : {}) - }; - ``` - -### 2. Nginx - Redirection et proxy -- **Problème**: `/lecoffre/` retournait 404 car l'image CI ne respectait pas `basePath` -- **Solution**: Rewrite Nginx dans `location ^~ /lecoffre/` - ```nginx - rewrite ^/lecoffre/(.*)$ /$1 break; - proxy_pass http://localhost:3004; - ``` - -### 3. Assets Next.js manquants -- **Problème**: `/_next/static/` retournait 404 (assets non servis) -- **Solution**: Route Nginx dédiée - ```nginx - location ^~ /_next/ { - proxy_pass http://localhost:3004/_next/; - add_header Cache-Control "public, max-age=31536000, immutable"; - } - ``` - -### 4. HMR en développement -- **Problème**: Besoin d'HMR sans impacter la prod -- **Solution**: Route dédiée `/lecoffre-hmr/` avec WebSocket support - ```nginx - location ^~ /lecoffre-hmr/ { - proxy_http_version 1.1; - proxy_set_header Upgrade $http_upgrade; - proxy_set_header Connection "upgrade"; - rewrite ^/lecoffre-hmr/(.*)$ /$1 break; - proxy_pass http://localhost:3000; - } - ``` - -## Architecture finale - -### Production -- `https://dev4.4nkweb.com/` → ihm_client (iframe) -- `https://dev4.4nkweb.com/lecoffre/` → lecoffre-front (app principale) -- `https://dev4.4nkweb.com/_next/` → assets Next.js - -### Développement (HMR) -- `https://dev4.4nkweb.com/lecoffre-hmr/` → Next.js dev server (port 3000) - -### Flux IdNot -- CORS dev3 configuré pour `https://dev4.4nkweb.com` -- State management via `/api/v1/idnot/state` sur dev3 -- Callback vers `/authorized-client` (prod ou HMR) - -## Variables d'environnement -- `NEXT_PUBLIC_*` cohérentes entre build CI et runtime -- `NODE_ENV=production` pour activer basePath/export -- CORS dynamique pour dev4.4nkweb.com - -## Tests validés -- ✅ Redirection 301: `/lecoffre` → `/lecoffre/` -- ✅ Page d'accueil: `/lecoffre/` → 200 -- ✅ Assets: `/_next/static/` → 200 -- ✅ HMR: `/lecoffre-hmr/` → 200 -- ✅ CORS dev3: OPTIONS 204 + POST state 200 -- ✅ ihm_client: `/` → 200 - - - diff --git a/docs/ENV-RESUME.md b/docs/ENV-RESUME.md deleted file mode 100644 index 477c21c6..00000000 --- a/docs/ENV-RESUME.md +++ /dev/null @@ -1,30 +0,0 @@ -## Résumé des environnements (front) - -### Contexte - -- **Hôte iframe**: `https://dev4.4nkweb.com` -- **Site principal**: `https://dev4.4nkweb.com/lecoffre` (Next.js `basePath: '/lecoffre'`) -- **Signer utilisé**: `https://dev3.4nkweb.com` - -### Variables `NEXT_PUBLIC_*` à aligner - -- `NEXT_PUBLIC_4NK_URL=https://dev4.4nkweb.com` -- `NEXT_PUBLIC_4NK_IFRAME_URL=https://dev4.4nkweb.com` -- `NEXT_PUBLIC_API_URL` → URL publique de l’API back (chemin stable, CORS OK) -- `NEXT_PUBLIC_BACK_API_PROTOCOL=https` -- `NEXT_PUBLIC_BACK_API_HOST=dev4.4nkweb.com` -- `NEXT_PUBLIC_BACK_API_PORT` (vide en prod 443) -- `NEXT_PUBLIC_BACK_API_ROOT_URL` et `NEXT_PUBLIC_BACK_API_VERSION` si composées côté front -- `NEXT_PUBLIC_IDNOT_*`, `NEXT_PUBLIC_DOCAPOSTE_API_URL` selon intégrations -- `NEXT_PUBLIC_DEFAULT_VALIDATOR_ID`, `NEXT_PUBLIC_DEFAULT_STORAGE_URLS` selon besoins - -### Points d’attention - -- Vérifier que toutes les URLs tiennent compte du `basePath` `/lecoffre`. -- Le service de signature est externalisé sur `dev3.4nkweb.com`. - - - - - - diff --git a/docs/FLUX.md b/docs/FLUX.md deleted file mode 100644 index 570e9e52..00000000 --- a/docs/FLUX.md +++ /dev/null @@ -1,6 +0,0 @@ -# Description des Flux - LeCoffre Front - -## Flux principaux -1. Auth notaire: Front → IdNot → Front (callback). -2. Intégration IHM: Front → iframe → IHM. -3. API: Front → Back (REST). diff --git a/docs/FONCTIONNEL.md b/docs/FONCTIONNEL.md deleted file mode 100644 index dc862722..00000000 --- a/docs/FONCTIONNEL.md +++ /dev/null @@ -1,15 +0,0 @@ -# Description Fonctionnelle - LeCoffre Front - -## Objectif -Fournir l’interface principale (Next.js) orchestrant l’UX, incluant l’iframe IHM Client. - -## Parcours clés -- Authentification notaire (redirections IdNot). -- Navigation dossiers et intégration iframe IHM. -- Appels API backend, feedback utilisateur et gestion d’erreurs. - -## Rôles -- Notaire, utilisateur interne. - -## Résultats attendus -- UX fluide, chargements différés (code splitting), gestion session robuste. diff --git a/docs/HMR_IDNOT_STATE.md b/docs/HMR_IDNOT_STATE.md deleted file mode 100644 index 4ae647d1..00000000 --- a/docs/HMR_IDNOT_STATE.md +++ /dev/null @@ -1,43 +0,0 @@ -HMR + IdNot + dev3 via state (mise à jour: 2025-09-24) - -Vue d’ensemble - -- HMR (Hot Module Replacement) - - En local, Next.js sert le HMR (ex: port 3000) et recharge les modules sans redémarrage. - - Les appels API sont effectués en same-origin via le proxy Nginx/compose: le front cible `/api/...`, Nginx route vers dev3. Pas de CORS ni reconfig lors des reloads. - - En dev4/prod, pas de HMR: `next start` sert l’app buildée sous `/lecoffre/`. - -- Émission du state (dev3) - - Front → `POST /api/v1/idnot/state` (same-origin `/api`). Nginx (dev4) relaie vers `https://dev3.4nkweb.com/api/v1/idnot/state`. - - Body: `{ "next_url": "https://dev4.4nkweb.com/lecoffre/authorized-client" }`. - - Réponse: `{ "state": "" }`. CORS dynamique côté Nginx (dev3) autorise l’origine dev4. - -- Redirection IdNot avec state - - URL d’autorisation: - - base = `NEXT_PUBLIC_IDNOT_BASE_URL + NEXT_PUBLIC_IDNOT_AUTHORIZE_ENDPOINT` - - `client_id = NEXT_PUBLIC_IDNOT_CLIENT_ID` - - `redirect_uri = NEXT_PUBLIC_IDNOT_REDIRECT_URI_FIXED` (stable) - - `scope = openid,profile`, `response_type = code` - - `state = ` (depuis l’API state dev3) - - IdNot renvoie `code` (et le `state` validé côté backend) vers dev3, qui enchaîne selon `next_url`. - -- Pourquoi ça marche bien avec HMR - - Le front n’appelle pas dev3 directement depuis le navigateur: toujours `/api` (reverse-proxy Nginx). - - Nginx masque les headers CORS upstream et réinjecte des headers valides dynamiquement (Origin dev4/local). - - Le `state` est demandé via `/api`, donc indépendant du HMR. - - Les `NEXT_PUBLIC_*` pilotent IdNot et `next_url`; endpoints de debug: `/api/env` et `/env`. - -- Canonicalisation URL - - Canonical sous-sous-chemin: `/lecoffre/`. - - Next: `basePath: '/lecoffre'`, `assetPrefix: '/lecoffre'`, `trailingSlash: true`. - - Nginx (dev4): rediriger `/lecoffre` → `/lecoffre/`; proxy `^~ /lecoffre/` vers `http://localhost:3004`. - -- Validation (script `scripts/deploy_front_ext.sh`) - - Vérifie: variables `NEXT_PUBLIC_*` (conteneur vs `.env.master`). - - CORS dev3: OPTIONS 204 + en-têtes (A-C-A-Origin = dev4). - - `POST /api/v1/idnot/state`: 200 + `state` présent. - - Checks publics: `/lecoffre` = 301 → `/lecoffre/`, `/lecoffre/` = 200. - - - - diff --git a/docs/INSTALLATION.md b/docs/INSTALLATION.md deleted file mode 100644 index 8f999a33..00000000 --- a/docs/INSTALLATION.md +++ /dev/null @@ -1,26 +0,0 @@ -# Installation - LeCoffre Front - -## Prérequis -- Dépôts sous `/home/debian/4NK_env` (branche `ext`). -- Docker/Compose. -- Variables `NEXT_PUBLIC_*` dans `lecoffre_node/.env.master`. - -## Configuration -- Pas de `.env` local. -- Vérifier URLs backend et iframe IHM. - -## Démarrage (orchestrateur) -```bash -cd /home/debian/4NK_env/lecoffre_node -./scripts/start.sh | cat -``` - -## Accès -- `https://dev4.4nkweb.com/lecoffre/` - -## Vérifications -- Ouverture iframe IHM. -- Appels API vers `/api/` OK. - -## Notes -- CI via tag `ext`. diff --git a/docs/PORTS.md b/docs/PORTS.md deleted file mode 100644 index c551f51f..00000000 --- a/docs/PORTS.md +++ /dev/null @@ -1,27 +0,0 @@ -Ports et usages (mise à jour: 2025-09-24) - -Contexte: déploiement sur dev4 avec Nginx en frontal, lecoffre-front en Docker. - -- 80 (TCP) — Nginx HTTP (host) -- 443 (TCP) — Nginx HTTPS (host) - -- 3004 (TCP) — docker-proxy → lecoffre-front:8080 (port public du front via Docker) - - Interne conteneur: 8080 (Next.js `next start`) - -- 3005 (TCP) — docker-proxy → Grafana:3000 -- 3006 (TCP) — docker-proxy → status-api:3006 -- 3100 (TCP) — docker-proxy → Loki:3100 -- 8000 (TCP) — docker-proxy → blindbit-oracle:8000 -- 8081 (TCP) — docker-proxy → sdk_storage:8080 - -Ports désactivés/libérés - -- 3000 (TCP) — vhost local Nginx `local.4nkweb.com-3000` désactivé -- 7777/7778 (TCP) — anciens processus Node arrêtés -- 8080 (TCP host) — ancien Node local arrêté (ne pas confondre avec 8080 interne du conteneur front) - -Notes - -- Canonical front sous sous-chemin: `/lecoffre/` -- Next.js: `basePath: '/lecoffre'`, `assetPrefix: '/lecoffre'`, `trailingSlash: true` -- Nginx: rediriger `/lecoffre` → `/lecoffre/`, et proxy sur `^~ /lecoffre/` vers `http://localhost:3004` diff --git a/docs/QUALITE.md b/docs/QUALITE.md deleted file mode 100644 index 055769dc..00000000 --- a/docs/QUALITE.md +++ /dev/null @@ -1,6 +0,0 @@ -# Qualité Logicielle - LeCoffre Front - -- Lint/format: respecter règles Next/TS. -- Tests: E2E parcours IdNot et iframe IHM. -- Performance: audit Lighthouse, lazy loading. -- Observabilité: logs client minimaux, erreurs capturées. diff --git a/docs/RESUME-ANALYSE.md b/docs/RESUME-ANALYSE.md deleted file mode 100644 index 337556a2..00000000 --- a/docs/RESUME-ANALYSE.md +++ /dev/null @@ -1,159 +0,0 @@ -# Résumé de l'Analyse - lecoffre-front - -## Vue d'ensemble - -L'analyse complète du repository **lecoffre-front** a été effectuée le $(date). Ce document présente un résumé des principales découvertes et recommandations. - -## Structure du projet - -### Type d'application -- **Framework**: Next.js 14.2.3 avec TypeScript 4.9.5 -- **Architecture**: Application frontend SPA avec intégrations multiples -- **Déploiement**: Docker multi-stage + Kubernetes -- **Version actuelle**: v0.1.6 (package.json) / v2.5.1 (frontend) - -### Architecture technique -``` -Frontend (Next.js) → API Backend → Services externes - ↓ ↓ ↓ - Material-UI Base de données 4NK/IDNot/Docaposte -``` - -## Variables d'environnement - -### Configuration identifiée -- **21 variables d'environnement** configurées -- **4 environnements** supportés (dev/staging/preprod/production) -- **Gestion centralisée** via Next.js config et FrontendVariables - -### Variables critiques -```bash -# API Backend -NEXT_PUBLIC_BACK_API_PROTOCOL=https:// -NEXT_PUBLIC_BACK_API_HOST=api.example.com -NEXT_PUBLIC_BACK_API_PORT=443 - -# Intégrations -NEXT_PUBLIC_4NK_URL=https://dev4.4nkweb.com -NEXT_PUBLIC_IDNOT_BASE_URL=https://idnot.example.com -NEXT_PUBLIC_DOCAPOSTE_API_URL=https://api.docaposte.com -``` - -## Déploiement et infrastructure - -### Docker -- **Multi-stage build** avec 4 cibles (deps/development/builder/ext) -- **Sécurité**: Utilisateur non-root, support SSH agent -- **Optimisation**: Cache npm, build standalone Next.js - -### Kubernetes -- **Namespace**: lecoffre -- **Ressources**: 1Gi RAM (request) / 2Gi RAM (limit) -- **Sécurité**: Vault Agent pour injection des secrets -- **Ingress**: TLS avec cert-manager - -### CI/CD -- **Registre**: git.4nkweb.com (Docker registry) -- **Tagging**: Contrôlé par message de commit -- **Secrets**: Gestion via Vault + External Secrets - -## Dépendances - -### État général -- **46 dépendances** principales -- **5 dépendances** de développement -- **Statut**: Majoritairement à jour et sécurisées - -### Recommandations -- ✅ **Maintenir**: Next.js 14.2.3, React 18.2.0, MUI 5.11.13 -- ⚠️ **Mettre à jour**: TypeScript 4.9.5 → 5.x -- ✅ **Sécurisé**: Toutes les autres dépendances - -## Points forts identifiés - -### Architecture -- ✅ Structure modulaire bien organisée -- ✅ Séparation claire des responsabilités -- ✅ Configuration multi-environnement -- ✅ Intégration Docker/Kubernetes robuste - -### Sécurité -- ✅ Variables d'environnement externalisées -- ✅ Gestion des secrets via Vault -- ✅ Utilisateur non-root dans Docker -- ✅ Support SSH agent pour dépendances privées - -### Développement -- ✅ TypeScript pour le typage statique -- ✅ ESLint + Prettier pour la qualité du code -- ✅ Tests organisés dans le dossier tests/ -- ✅ Documentation complète - -## Points d'attention - -### Améliorations recommandées - -1. **TypeScript** - - Mettre à jour vers la version 5.x - - Bénéficier des dernières fonctionnalités - -2. **Monitoring** - - Ajouter des métriques de performance - - Monitoring des erreurs en production - -3. **Tests** - - Étendre la couverture de tests - - Tests d'intégration avec les services externes - -4. **Documentation** - - Maintenir la documentation des variables d'environnement - - Documenter les processus de déploiement - -### Risques identifiés - -1. **Dépendances privées** - - Dépendance à git.4nkweb.com pour le-coffre-resources - - Nécessite un accès SSH configuré - -2. **Variables d'environnement** - - Variables NEXT_PUBLIC_* exposées côté client - - Nécessite une validation stricte des valeurs - -3. **Intégrations externes** - - Dépendance à plusieurs services externes - - Nécessite une gestion des pannes - -## Recommandations prioritaires - -### Court terme (1-2 semaines) -1. Mettre à jour TypeScript vers la version 5.x -2. Effectuer un audit de sécurité complet (`npm audit`) -3. Vérifier la configuration des variables d'environnement - -### Moyen terme (1-2 mois) -1. Étendre la couverture de tests -2. Ajouter des métriques de monitoring -3. Documenter les processus de déploiement - -### Long terme (3-6 mois) -1. Évaluer l'optimisation des performances -2. Considérer l'ajout de tests d'intégration -3. Planifier les mises à jour des dépendances - -## Conclusion - -Le projet **lecoffre-front** présente une architecture solide et bien structurée. Les technologies utilisées sont modernes et appropriées pour le contexte. La configuration Docker/Kubernetes est robuste et sécurisée. - -Les principales améliorations concernent la mise à jour de TypeScript et l'extension des tests. Le projet est globalement en bon état et prêt pour la production. - -## Documentation créée - -1. **ANALYSE-REPOSITORY.md**: Analyse complète du repository -2. **VARIABLES-ENVIRONNEMENT.md**: Documentation détaillée des variables d'environnement -3. **ANALYSE-DEPENDANCES.md**: Analyse des dépendances et recommandations -4. **RESUME-ANALYSE.md**: Ce résumé exécutif - ---- - -*Analyse effectuée le $(date) - Repository lecoffre-front* -*Analyste: Assistant IA Claude* diff --git a/docs/SECURITE.md b/docs/SECURITE.md deleted file mode 100644 index 5b126d95..00000000 --- a/docs/SECURITE.md +++ /dev/null @@ -1,6 +0,0 @@ -# Sécurité - LeCoffre Front - -- Aucune donnée sensible côté client. -- Variables exposées en `NEXT_PUBLIC_*` contrôlées. -- CSP/headers via Nginx. -- Sanitation des entrées utilisateur. diff --git a/docs/TECHNIQUE.md b/docs/TECHNIQUE.md deleted file mode 100644 index 7733923e..00000000 --- a/docs/TECHNIQUE.md +++ /dev/null @@ -1,19 +0,0 @@ -# Description Technique - LeCoffre Front - -## Tech stack -- Next.js, Node.js 19. - -## Configuration -- Variables `NEXT_PUBLIC_*` via `lecoffre_node/.env.master`. - -## Interfaces -- Iframe vers `ihm_client`. -- REST vers `/api/`. - -## Sécurité -- Aucun secret côté client. -- Headers via Nginx. - -## Observabilité -- Logs Promtail → Loki. -- Dashboards Grafana. diff --git a/docs/TODO.md b/docs/TODO.md deleted file mode 100644 index 5fae7fcf..00000000 --- a/docs/TODO.md +++ /dev/null @@ -1,6 +0,0 @@ -# TODO - LeCoffre Front - -- Vérifier URLs backend et iframe IHM. -- Tester parcours IdNot. -- Valider variables `NEXT_PUBLIC_*`. -- Vérifier dashboards Grafana Frontend. diff --git a/docs/VARIABLES-ENVIRONNEMENT.md b/docs/VARIABLES-ENVIRONNEMENT.md deleted file mode 100644 index 74e8e1e7..00000000 --- a/docs/VARIABLES-ENVIRONNEMENT.md +++ /dev/null @@ -1,336 +0,0 @@ -# Variables d'Environnement - lecoffre-front - -## Vue d'ensemble - -Ce document détaille toutes les variables d'environnement utilisées dans l'application lecoffre-front, leur utilisation et leur configuration. - -## Variables d'environnement supportées - -### 1. Configuration API Backend - -#### `NEXT_PUBLIC_BACK_API_PROTOCOL` -- **Description**: Protocole utilisé pour communiquer avec l'API backend -- **Valeurs possibles**: `https://`, `http://` -- **Exemple**: `https://` -- **Utilisation**: Construction des URLs d'API - -#### `NEXT_PUBLIC_BACK_API_HOST` -- **Description**: Nom d'hôte de l'API backend -- **Exemple**: `api.lecoffre.com`, `dev4.4nkweb.com` -- **Utilisation**: Construction des URLs d'API - -#### `NEXT_PUBLIC_BACK_API_PORT` -- **Description**: Port de l'API backend -- **Exemple**: `443`, `8080`, `3001` -- **Utilisation**: Construction des URLs d'API -- **Note**: Peut être vide pour les ports par défaut (80/443) - -#### `NEXT_PUBLIC_BACK_API_ROOT_URL` -- **Description**: Chemin racine de l'API -- **Exemple**: `/api`, `/` -- **Utilisation**: Construction des URLs d'API - -#### `NEXT_PUBLIC_BACK_API_VERSION` -- **Description**: Version de l'API -- **Exemple**: `v1`, `v2` -- **Utilisation**: Construction des URLs d'API - -### 2. Configuration Frontend - -#### `NEXT_PUBLIC_FRONT_APP_HOST` -- **Description**: URL de base de l'application frontend -- **Exemple**: `https://app.lecoffre.com` -- **Utilisation**: Redirections et liens internes - -#### `NEXT_PUBLIC_FRONT_APP_PORT` -- **Description**: Port de l'application frontend -- **Exemple**: `443`, `3000` -- **Utilisation**: Construction des URLs frontend - -### 3. Intégration IDNot (Authentification) - -#### `NEXT_PUBLIC_IDNOT_AUTHORIZE_ENDPOINT` -- **Description**: Point d'entrée pour l'autorisation OAuth -- **Exemple**: `/oauth/authorize` -- **Utilisation**: Flux d'authentification - -#### `NEXT_PUBLIC_IDNOT_CLIENT_ID` -- **Description**: Identifiant client OAuth -- **Exemple**: `lecoffre-client-id` -- **Utilisation**: Authentification OAuth - -#### `NEXT_PUBLIC_IDNOT_BASE_URL` -- **Description**: URL de base du service IDNot -- **Exemple**: `https://idnot.lecoffre.com` -- **Utilisation**: Authentification OAuth - -#### `NEXT_PUBLIC_IDNOT_REDIRECT_URI` -- **Description**: URI de redirection après authentification -- **Exemple**: `https://app.lecoffre.com/callback` -- **Utilisation**: Flux d'authentification - -### 4. Intégration Docaposte - -#### `NEXT_PUBLIC_DOCAPOSTE_API_URL` -- **Description**: URL de l'API Docaposte -- **Exemple**: `https://api.docaposte.com` -- **Utilisation**: Services postaux - -### 5. Intégration 4NK (Blockchain) - -#### `NEXT_PUBLIC_4NK_URL` -- **Description**: URL de base des services 4NK -- **Exemple**: `https://dev4.4nkweb.com` -- **Utilisation**: Services blockchain et signature - -#### `NEXT_PUBLIC_4NK_IFRAME_URL` -- **Description**: URL spécifique pour l'iframe 4NK -- **Exemple**: `https://dev4.4nkweb.com` -- **Utilisation**: Communication iframe -- **Note**: Peut être différente de `NEXT_PUBLIC_4NK_URL` - -### 6. Analytics et Monitoring - -#### `NEXT_PUBLIC_HOTJAR_SITE_ID` -- **Description**: Identifiant du site Hotjar -- **Exemple**: `123456` -- **Utilisation**: Analytics et heatmaps - -#### `NEXT_PUBLIC_HOTJAR_VERSION` -- **Description**: Version de Hotjar -- **Exemple**: `6` -- **Utilisation**: Analytics et heatmaps - -### 7. Configuration système - -#### `NEXT_PUBLIC_API_URL` -- **Description**: URL générique de l'API -- **Exemple**: `https://api.lecoffre.com` -- **Utilisation**: Appels API génériques - -#### `NEXT_PUBLIC_DEFAULT_VALIDATOR_ID` -- **Description**: Identifiant du validateur par défaut -- **Exemple**: `862406317a35064537ac959cb5d8bbdf4f849283b63db3ffa9904de2b3427c43:0` -- **Utilisation**: Validation des entités système -- **Valeur par défaut**: Définie dans `AppConstants.ts` - -#### `NEXT_PUBLIC_DEFAULT_STORAGE_URLS` -- **Description**: URLs de stockage par défaut (séparées par des virgules) -- **Exemple**: `https://dev3.4nkweb.com/storage,https://backup.4nkweb.com/storage` -- **Utilisation**: Stockage des données -- **Valeur par défaut**: `https://dev3.4nkweb.com/storage` - -### 8. Variables d'environnement système - -#### `NEXTJS_APP_ENV_NAME` -- **Description**: Nom de l'environnement -- **Valeurs possibles**: `development`, `staging`, `preprod`, `production` -- **Utilisation**: Sélection de la configuration par environnement -- **Valeur par défaut**: `development` - -#### `NODE_ENV` -- **Description**: Environnement Node.js -- **Valeurs possibles**: `development`, `production` -- **Utilisation**: Configuration Next.js - -## Configuration par environnement - -### Développement -```bash -NEXTJS_APP_ENV_NAME=development -NODE_ENV=development -NEXT_PUBLIC_BACK_API_PROTOCOL=http:// -NEXT_PUBLIC_BACK_API_HOST=localhost -NEXT_PUBLIC_BACK_API_PORT=3001 -NEXT_PUBLIC_4NK_URL=https://dev4.4nkweb.com -``` - -### Staging -```bash -NEXTJS_APP_ENV_NAME=staging -NODE_ENV=production -NEXT_PUBLIC_BACK_API_PROTOCOL=https:// -NEXT_PUBLIC_BACK_API_HOST=stg-api.lecoffre.com -NEXT_PUBLIC_BACK_API_PORT=443 -NEXT_PUBLIC_4NK_URL=https://dev4.4nkweb.com -``` - -### Production -```bash -NEXTJS_APP_ENV_NAME=production -NODE_ENV=production -NEXT_PUBLIC_BACK_API_PROTOCOL=https:// -NEXT_PUBLIC_BACK_API_HOST=api.lecoffre.com -NEXT_PUBLIC_BACK_API_PORT=443 -NEXT_PUBLIC_4NK_URL=https://4nk.lecoffre.com -``` - -## Utilisation dans le code - -### Configuration Next.js - -Les variables sont configurées dans `next.config.js`: - -```javascript -const nextConfig = { - publicRuntimeConfig: { - NEXT_PUBLIC_BACK_API_PROTOCOL: process.env.NEXT_PUBLIC_BACK_API_PROTOCOL, - // ... autres variables - }, - serverRuntimeConfig: { - // Même configuration pour le serveur - }, - env: { - // Configuration pour le build - } -}; -``` - -### Initialisation dans l'application - -Les variables sont initialisées dans `_app.tsx`: - -```typescript -const { publicRuntimeConfig } = getConfig(); - -MyApp.getInitialProps = async () => { - return { - backApiProtocol: publicRuntimeConfig.NEXT_PUBLIC_BACK_API_PROTOCOL, - // ... autres variables - }; -}; -``` - -### Utilisation dans les services - -```typescript -// DatabaseService.ts -private static buildBaseUrl(): string { - return `${publicRuntimeConfig.NEXT_PUBLIC_BACK_API_PROTOCOL}${publicRuntimeConfig.NEXT_PUBLIC_BACK_API_HOST}:${publicRuntimeConfig.NEXT_PUBLIC_BACK_API_PORT}${publicRuntimeConfig.NEXT_PUBLIC_BACK_API_ROOT_URL}${publicRuntimeConfig.NEXT_PUBLIC_BACK_API_VERSION}`; -} -``` - -## Déploiement Docker - -### Variables de build - -```dockerfile -ARG NEXT_PUBLIC_BACK_API_PROTOCOL -ARG NEXT_PUBLIC_BACK_API_HOST -# ... autres variables -``` - -### Variables d'environnement runtime - -```dockerfile -ENV NEXT_PUBLIC_BACK_API_PROTOCOL=${NEXT_PUBLIC_BACK_API_PROTOCOL} \ - NEXT_PUBLIC_BACK_API_HOST=${NEXT_PUBLIC_BACK_API_HOST} \ - # ... autres variables -``` - -### Exécution - -```bash -docker run -e NEXT_PUBLIC_BACK_API_PROTOCOL=https:// \ - -e NEXT_PUBLIC_BACK_API_HOST=api.example.com \ - lecoffre/front:latest -``` - -## Déploiement Kubernetes - -### Via Vault (recommandé) - -```yaml -annotations: - vault.hashicorp.com/agent-inject: "true" - vault.hashicorp.com/agent-inject-secret-envs: secret/data/lecoffre-front-stg/config/envs - vault.hashicorp.com/agent-inject-template-envs: | - {{ with secret "secret/data/lecoffre-front-stg/config/envs" }} - {{ range $k, $v := .Data.data }} - export {{ $k }}="{{ $v }}" - {{ end }} - {{ end }} -``` - -### Via ConfigMap - -```yaml -apiVersion: v1 -kind: ConfigMap -metadata: - name: lecoffre-front-config -data: - NEXT_PUBLIC_BACK_API_PROTOCOL: "https://" - NEXT_PUBLIC_BACK_API_HOST: "api.example.com" - # ... autres variables -``` - -## Validation et tests - -### Vérification des variables requises - -```typescript -const requiredVars = [ - 'NEXT_PUBLIC_BACK_API_PROTOCOL', - 'NEXT_PUBLIC_BACK_API_HOST', - 'NEXT_PUBLIC_BACK_API_PORT', - 'NEXT_PUBLIC_BACK_API_ROOT_URL', - 'NEXT_PUBLIC_BACK_API_VERSION' -]; - -for (const varName of requiredVars) { - if (!publicRuntimeConfig[varName]) { - throw new Error(`${varName} is not defined in environment variables`); - } -} -``` - -### Tests d'environnement - -```bash -# Vérifier les variables définies -env | grep NEXT_PUBLIC_ - -# Tester la construction d'URL -curl -I $(echo $NEXT_PUBLIC_BACK_API_PROTOCOL$NEXT_PUBLIC_BACK_API_HOST:$NEXT_PUBLIC_BACK_API_PORT$NEXT_PUBLIC_BACK_API_ROOT_URL$NEXT_PUBLIC_BACK_API_VERSION/health) -``` - -## Bonnes pratiques - -1. **Sécurité**: Ne jamais exposer de secrets dans les variables `NEXT_PUBLIC_*` -2. **Validation**: Toujours valider la présence des variables requises -3. **Documentation**: Maintenir la documentation des variables -4. **Tests**: Tester avec différentes configurations d'environnement -5. **Fallbacks**: Prévoir des valeurs par défaut quand possible - -## Dépannage - -### Variables non définies - -```bash -# Vérifier les variables d'environnement -docker exec -it env | grep NEXT_PUBLIC_ - -# Vérifier la configuration Vault -vault kv get secret/data/lecoffre-front-stg/config/envs -``` - -### URLs malformées - -```bash -# Tester la construction d'URL -node -e " -const config = { - protocol: process.env.NEXT_PUBLIC_BACK_API_PROTOCOL, - host: process.env.NEXT_PUBLIC_BACK_API_HOST, - port: process.env.NEXT_PUBLIC_BACK_API_PORT, - root: process.env.NEXT_PUBLIC_BACK_API_ROOT_URL, - version: process.env.NEXT_PUBLIC_BACK_API_VERSION -}; -console.log(\`\${config.protocol}\${config.host}:\${config.port}\${config.root}\${config.version}\`); -" -``` - ---- - -*Documentation mise à jour le $(date) - Variables d'environnement lecoffre-front* diff --git a/docs/ci.md b/docs/ci.md deleted file mode 100644 index 6f1eb644..00000000 --- a/docs/ci.md +++ /dev/null @@ -1,115 +0,0 @@ -### CI/CD — Fonctionnement observé et architecture de déploiement - -Cette documentation décrit le pipeline CI/CD tel qu’il peut être déduit des artefacts présents dans le dépôt : `Dockerfile`, `package.json`, et les manifestes Kubernetes rendus dans `temp.yaml`. Aucune configuration de pipeline explicite n’est présente dans le dépôt (pas de `.gitea/`, `.github/workflows/`, `.gitlab-ci.yml`, `.drone.yml`). Le flux ci-dessous s’appuie donc sur ces éléments pour décrire le fonctionnement attendu. - -### Portée - -- **Build applicatif**: Next.js (Node 19-alpine) avec dépendance privée `le-coffre-resources` via SSH. -- **Image Docker**: construction multi-étapes, publication vers le registre Docker hébergé sur `git.4nkweb.com` (accès via clés SSH). -- **Déploiement Kubernetes**: namespace `lecoffre`, intégration Vault Agent pour l’injection d’ENV, `ExternalSecret` pour le secret de pull Docker, `Ingress` TLS via cert-manager, ressources de `Deployment`/`Service`. - - **Variables front ajoutées**: `NEXT_PUBLIC_4NK_IFRAME_URL` pour distinguer l’URL complète de l’iframe de son origin (`NEXT_PUBLIC_4NK_URL`). - -### Chaîne de build - -- **Dépendances** - - `package.json` indique Next.js 14, TypeScript 4.9, ESLint 8.36, etc. - - La dépendance privée `le-coffre-resources` est récupérée depuis `git.4nkweb.com` via SSH (`git+ssh`). - -- **Dockerfile** (multi-étapes, Node 19-alpine) - - Étape `deps`: installation des dépendances avec `npm install` en utilisant BuildKit et le forward d’agent SSH pour accéder au dépôt privé. - - Étape `development`: copie du code, exécution sous un utilisateur non-root, commande par défaut `npm run dev` (pour le développement local). Pour la prod, l’image utilisée en cluster exécute `npm run start` (cf. manifeste). - -- **Build Next.js** - - Script `build`: `NEXT_TELEMETRY_DISABLED=1 next build --no-lint` - - Script `start`: `next start` - - Le lint n’est pas bloquant au build (flag `--no-lint`). - -### Image, registre et version - -- **Registre**: Docker registry interne sur `git.4nkweb.com`. -- **Tagging**: contrôlé par la CI via le message de commit (préfixe `ci: docker_tag=`), sinon fallback `dev-test`. La branche peut être utilisée comme tag par défaut selon la CI. Recommandation: utiliser un tag non versionné `ext`. - -### Déploiement Kubernetes (extrait de `temp.yaml`) - -- **Namespace**: `lecoffre` -- **ServiceAccount**: `lecoffre-front-sa` avec `Secret` token associé. -- **ExternalSecret**: création de `imagePullSecret` à partir de Vault via `external-secrets.io` en lisant `secret/data/lecoffre-front-stg/config/dockerpullsecret` (clé `.dockerconfigjson`). -- **Deployment**: `apps/v1` nommé `lecoffre-front` avec: - - `image`: `rg.fr-par.scw.cloud/lecoffre/front:v0.1.9` - - `imagePullPolicy`: `Always` - - `resources`: `requests` (cpu 200m, ram 1Gi), `limits` (ram 2Gi) - - **Vault Agent Injector**: annotations pour injecter des variables d’environnement depuis `secret/data/lecoffre-front-stg/config/envs` en exportant chaque paire `clé=valeur` dans `/vault/secrets/envs`. - - **Commande de démarrage**: `['sh','-c', '. /vault/secrets/envs && npm run start']` - -- **Service**: type ClusterIP exposant le port 80 vers le `targetPort` 3000 du conteneur Next.js. - -- **Ingress**: classe `nginx` avec TLS géré par `cert-manager` (ClusterIssuer `letsencrypt-prod`) pour `app.stg.lecoffre.smart-chain.fr`. - -### Flux CI/CD attendu (déduit) - -1. **Checkout + préparation** - - Récupération du code et configuration de l’agent SSH (accès à `git.4nkweb.com`). - -2. **Installation des dépendances** - - `npm install` avec BuildKit (`--mount=type=ssh`) pour la dépendance privée. - -3. **Build applicatif** - - `npm run build` (désactive la télémétrie et le lint bloquant). - -4. **Construction de l’image** - - Réalisée par la CI (BuildKit + forward d’agent SSH) après un `git push` sur `git.4nkweb.com`. - - Taggage déterminé par le message de commit et/ou la branche. - -5. **Push au registre** - - Réalisé par la CI vers le registre `git.4nkweb.com`. - -6. **Déploiement Kubernetes** - - Application des manifestes (ou rendu Helm) dans le namespace `lecoffre`. - - Les secrets de pull sont fournis via `ExternalSecret` connecté à Vault. - - Au runtime, Vault Agent injecte les variables d’environnement nécessaires avant `npm run start`. - -### Sécurité et secrets - -- **Build**: le forward d’agent SSH évite d’écrire la clé privée dans l’image. -- **Runtime**: aucune variable sensible n’est stockée dans l’image; elles sont injectées à l’exécution par Vault. -- **Pull de l’image**: la config Docker (`.dockerconfigjson`) est fournie par `ExternalSecret` à partir de Vault. - -### Secrets CI requis - -- **USER**: identifiant du compte CI sur `git.4nkweb.com` disposant des droits requis (lecture repo, push d’image vers le registry). -- **TOKEN**: jeton d’accès (API/registry) associé à `USER`. Utilisé par la CI pour: - - Authentifier les actions git/HTTP vers `git.4nkweb.com` (si nécessaire) - - Authentifier le `docker login` vers le registry Gitea si la CI ne repose pas sur des credentials intégrés. - -Notes: -- Préférer des tokens à portée restreinte, régénérés périodiquement. -- Stocker `USER` et `TOKEN` dans le gestionnaire de secrets CI et ne jamais les committer. - -### Points à confirmer - -- Outil CI utilisé (Gitea Actions, Woodpecker/Drone, GitLab CI, autre) et fichiers de pipeline hébergés ailleurs. -- Règles de nommage des tags d’image et gouvernance de version (`vX.Y.Z`, tags d’environnement). -- Stratégie de déploiement (Helm chart source exact, commandes d’apply, gestion multi-env: dev/stg/prod). -- Politique de lint/test avant build (actuellement `--no-lint` au build Next.js). - - Passage des variables `NEXT_PUBLIC_4NK_URL` et `NEXT_PUBLIC_4NK_IFRAME_URL` à l’étape de build Docker (ARG/ENV) dans la CI. - -### Bonnes pratiques recommandées - -- Activer un job de lint et tests unitaires avant build d’image. -- Signer les images (Cosign) et activer des scans SCA/Container. -- Gérer explicitement les tags et le changelog en CI. -- Déployer via Helm chart versionné, avec valeurs par environnement (`values.{env}.yaml`). - -### Validation de l'image Docker « ext » (intégration des variables) - -- Objectif: vérifier que les variables `NEXT_PUBLIC_*` sont bien injectées dans l'image construite par la CI. -- Commande: - -``` -docker pull git.4nkweb.com/4nk/lecoffre-front:ext -docker run --rm git.4nkweb.com/4nk/lecoffre-front:ext sh -lc "env | grep '^NEXT_PUBLIC_' | sort" -``` - -- Attendus clés: - - `NEXT_PUBLIC_4NK_URL` et `NEXT_PUBLIC_4NK_IFRAME_URL` doivent être définies. - - Les URLs API (`NEXT_PUBLIC_API_URL`, `NEXT_PUBLIC_BACK_API_*`) doivent refléter l'environnement. diff --git a/docs/ext.md b/docs/ext.md deleted file mode 100644 index 806c26ef..00000000 --- a/docs/ext.md +++ /dev/null @@ -1,58 +0,0 @@ -### Image Docker "ext" (Next.js) – variables d'environnement et publication - -Cette image exécute l'app Next.js en mode production via `next start` et lit la configuration via les variables d'environnement exposées (préfixe `NEXT_PUBLIC_`). L'objectif est d'éviter toute dépendance à `localhost` dans les appels API : les URLs sont construites dynamiquement côté front à partir de ces variables. - -#### Variables d'environnement supportées - -- **NEXT_PUBLIC_BACK_API_PROTOCOL**: protocole de l'API (ex: `https://`) -- **NEXT_PUBLIC_BACK_API_HOST**: hôte de l'API (ex: `api.example.com`) -- **NEXT_PUBLIC_BACK_API_PORT**: port de l'API (ex: `443`) -- **NEXT_PUBLIC_BACK_API_ROOT_URL**: racine (ex: `/` ou `/api`) -- **NEXT_PUBLIC_BACK_API_VERSION**: version (ex: `v1`) -- **NEXT_PUBLIC_FRONT_APP_HOST**: base publique du front (ex: `https://app.example.com`) -- **NEXT_PUBLIC_FRONT_APP_PORT**: port front si nécessaire (ex: `443`) -- **NEXT_PUBLIC_IDNOT_AUTHORIZE_ENDPOINT** -- **NEXT_PUBLIC_IDNOT_CLIENT_ID** -- **NEXT_PUBLIC_IDNOT_BASE_URL** -- **NEXT_PUBLIC_DOCAPOSTE_API_URL** -- **NEXT_PUBLIC_HOTJAR_SITE_ID** -- **NEXT_PUBLIC_HOTJAR_VERSION** -- **NEXT_PUBLIC_4NK_URL** -- **NEXT_PUBLIC_API_URL** -- **NEXT_PUBLIC_DEFAULT_VALIDATOR_ID** -- **NEXT_PUBLIC_DEFAULT_STORAGE_URLS** (liste séparée par des virgules) - -Notes: - -- Le front initialise ses variables via `next.config.js` et `_app.tsx`, ce qui alimente `FrontendVariables`. Les appels API utilisent ces valeurs et n'emploient pas `localhost`. -- Les valeurs doivent être passées au conteneur au runtime (`docker run -e ...` ou manifest K8s via `env:`/`secretRef`). - -#### Construction de l'image (cible "ext") - -Prérequis: Docker BuildKit activé et agent SSH opérationnel pour cloner `le-coffre-resources` depuis `git.4nkweb.com`. - -1. `cd /home/debian/lecoffre-front` -2. `export DOCKER_BUILDKIT=1` -3. `docker build --target ext --ssh default -t lecoffre/front:ext -f /home/debian/lecoffre-front/Dockerfile /home/debian/lecoffre-front` - -#### Exécution locale (validation) - -Exemple minimal (adapter les valeurs): - -```bash -docker run --rm -p 3000:3000 \ - -e NEXT_PUBLIC_BACK_API_PROTOCOL=https:// \ - -e NEXT_PUBLIC_BACK_API_HOST=api.example.com \ - -e NEXT_PUBLIC_BACK_API_PORT=443 \ - -e NEXT_PUBLIC_BACK_API_ROOT_URL=/ \ - -e NEXT_PUBLIC_BACK_API_VERSION=v1 \ - -e NEXT_PUBLIC_FRONT_APP_HOST=https://app.example.com \ - -e NEXT_PUBLIC_4NK_URL=https://app.example.com \ - lecoffre/front:ext -``` - -#### Publication via CI (git.4nkweb.com) - -- Le push d'image est effectué par la CI de `git.4nkweb.com` suite à un `git push`. -- Définir le tag Docker dans le message de commit: `ci: docker_tag=ext` (fallback CI: `dev-test`). -- La branche peut être utilisée par la CI comme tag en l’absence d’override.