smart_ide/services/docv/enso-docs/INSTALLATION_ENVIRONNEMENT.md

Installation de l'environnement — enso (docv / enso)

Ce document décrit l’installation de l’environnement du projet sans Docker : prérequis, clone, build, et déploiement sur les machines test, pprod et prod. La configuration du proxy et des certificats sur la machine proxy est prévue ultérieurement.

Références : README.md, ARCHITECTURE_DOCV_ENSO.md, docv/IMPLEMENTATION.md.

---

1. Vue d’ensemble

Élément	Description
Pas de Docker	Les applications sont installées et exécutées directement sur l’OS (binaires Rust, build Next.js, processus Node).
Machines cibles	test (192.168.1.101), pprod (192.168.1.102), prod (192.168.1.103). Chaque environnement est déployé sur sa machine dédiée.
Domaines DNS	enso : test.enso.4nkweb.com, pprod.enso.4nkweb.com, prod.enso.4nkweb.com. docv : test.docv.4nkweb.com, pprod.docv.4nkweb.com, prod.docv.4nkweb.com (configurés).
Proxy	La machine proxy (192.168.1.100) assure le reverse proxy et les certificats SSL. La configuration détaillée pour enso et docv est à faire plus tard (voir deploy/nginx/).
Ports	Mêmes ports en développement, test, pprod et prod ; aucun port déjà utilisé par d’autres services. Détail : PORTS_ENSO.md.
Accès	Accès SSH aux machines via le proxy (ProxyJump). Utilisateur : ncantu.
smart_ide	Dépôt outillage (smart_ide) : socle dev orienté IA (Ollama, AnythingLLM, etc.). Accès SSH sur le LAN : 192.168.1.164 (même mode d’accès que les autres hôtes internes : bastion / proxy selon votre ~/.ssh/config).

---

2. Prérequis

À installer sur chaque machine cible (test, pprod, prod) et sur la machine de développement.

Logiciel	Version minimale	Usage
Node.js	18+	Build des fronts (Next.js), scripts npm.
npm	9+	Workspaces, install, build.
Rust (cargo, rustc)	1.78+ (lock Cargo.lock version 4), toolchain épinglée 1.88.0 (fichier rust-toolchain.toml à la racine du dépôt)	Compilation des backends docv-back et enso-back ; rustup obligatoire — éviter le seul paquet cargo/rustc du système si votre PATH pointe encore vers /usr/bin/cargo (souvent trop ancien).
PostgreSQL	14+	BDD par environnement (une instance par machine ou une BDD par projet selon choix).
Git	2+	Clone du dépôt et du sous-module ai.

Sous Debian/Ubuntu (à adapter selon l’OS) :

# Node.js (via NodeSource ou nvm selon politique)
sudo apt-get update
sudo apt-get install -y build-essential pkg-config libssl-dev
# Rust (rustup — après install, ~/.cargo/bin doit précéder /usr/bin dans PATH)
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y --default-toolchain 1.88.0
source "$HOME/.cargo/env"
# Depuis la racine du dépôt cloné : prise en compte de rust-toolchain.toml (ex. 1.88.0)
#   rustup show && cargo --version
# PostgreSQL client et serveur
sudo apt-get install -y postgresql postgresql-client
# Git
sudo apt-get install -y git

---

3. Clone du dépôt et sous-modules

3.1 Dépôt canonique et fork (4nk/enso vs nicolas.cantu/enso)

Rôle	URL typique
Canonique (organisation)	https://git.4nkweb.com/4nk/enso.git — SSH : git@git.4nkweb.com:4nk/enso.git
Fork / miroir personnel	https://git.4nkweb.com/nicolas.cantu/enso.git (exemple)

Les deux peuvent coexister : un poste de développement peut avoir origin sur le fork tandis que les serveurs (test, pprod, prod) clonent le dépôt que le compte de déploiement peut lire — en pratique souvent 4nk/enso (variable ENSO_GIT_CLONE_URL dans .secrets/<env>/enso-deploy.env, voir deploy/enso-deploy.env.example). L’historique Git attendu reste aligné entre fork et canonique.

3.2 Clone

Sur la machine de développement ou sur chaque machine cible (si build sur la cible) :

git clone https://git.4nkweb.com/4nk/enso.git
cd enso
git submodule update --init --recursive

Le sous-module ai (API IA) est référencé dans .gitmodules. Si le dépôt ai est vide ou indisponible, le clone du sous-module peut échouer ; dans ce cas, poursuivre sans ai ou initialiser le sous-module lorsque le dépôt est prêt.

3.3 Branche test (et équivalent) sur le dépôt distant

Le script deploy/scripts_v2/deploy.sh fait un git pull origin <env> sur la cible (ex. test). Il faut que la branche distante existe (ex. git push origin master:test depuis la branche contenant le code à déployer) ou que la phase distante retombe sur master tant que origin/test n’existe pas (message d’avertissement dans les logs).

Sur Gitea, si le message « Push to create is not enabled for users » apparaît, la création de branche à la volée est désactivée : un administrateur peut activer l’option correspondante ou créer la branche test sur le dépôt, puis vous pousser dessus avec les droits habituels.

---

4. Variables d’environnement

Chaque environnement (test, pprod, prod) utilise ses propres variables. Aucun secret ne doit être commité : utiliser .env (ignoré par Git) ou un mécanisme de déploiement (fichiers dans .secrets/<env>/ copiés à la main ou par script).

4.1 Backends

enso-back (Rust) : binaire enso-back, variables HOST, PORT (3040 derrière le proxy — voir PORTS_ENSO.md), enso/enso-back/.env.example. Build : cargo build --release --manifest-path enso/enso-back/Cargo.toml ; exécution : enso/enso-back/target/release/enso-back. Déploiement sur 192.168.1.164 : section 7.5 (adapter le chemin si besoin).

docv-back (Rust) — variables attendues (documentées dans le code et dans docs/docv/IMPLEMENTATION.md §5.4) :

Variable	Description	Exemple
DATABASE_URL	URL de connexion PostgreSQL	postgres://user:password@localhost:5432/docv_test
JWT_SECRET	Secret pour la signature des JWT	Chaîne longue et aléatoire
OAUTH_CLIENT_ID	Identifiant(s) client OAuth2 publics (virgule = plusieurs applis)	enso-web ou enso-web,autre-id
OAUTH_CLIENT_SECRET	Secret confidentiel pour /oauth/token	Aligné avec le front / enso-back
OAUTH_REDIRECT_URIS	URIs de callback autorisées (séparées par des virgules)	https://test.enso.4nkweb.com/auth/docv-callback
OAUTH_BROWSER_PATH_PREFIX	Préfixe public devant /oauth/… (reverse proxy, ex. /docv-api)	/docv-api ; vide seulement si OAuth est à la racine du site
DOCV_USERS_PK_COLUMN	Colonne PK sur users pour le login OAuth : id (défaut) ou uid (schéma existant type IMPL)	uid si la table utilise uid au lieu de id
DOCV_OAUTH_ACCESS_TOKEN_TTL_SEC	Durée unique (secondes) pour : jeton Bearer (JWT exp, expires_in), JWT dans le cookie docv_oauth_session et Max-Age du cookie après POST /oauth/sign-in.	Défaut 900 (15 min) ; plage 60–86400. Détail : docv/AUTH_SESSION.md.
DOCV_DEMO_MEMBER_EMAILS	(optionnel) Contournement test / BDD incomplete : emails séparés par des virgules ; au démarrage de docv-back, chaque utilisateur listé sans ligne office_members reçoit un lien sur le plus ancien office en rôle client (champ technique). Ne remplace pas le rattachement métier cabinet / client ni le choix d’espace au login (docv).	Ex. client@example.com
DOCV_LINK_ORPHAN_USERS_TO_FIRST_OFFICE	(optionnel) 1 / true / yes / on : au démarrage, tout utilisateur sans office_members est lié au plus ancien office uniquement. Test : avec plusieurs offices démo, un compte « orphelin » ne verra qu’une société ; memberships explicites requis pour le périmètre réel. Déconseillé en prod. Voir AUTH_SESSION.md § modèle produit.	1 sur test par défaut via deploy (surcharge possible)
OAUTH_TENANTS_JSON	(optionnel) JSON de branding par client_id	Voir docv/docv-back/tenants.default.json
OAUTH_TENANTS_PATH	(optionnel) chemin fichier JSON de branding	/chemin/vers/tenants.json
HOST	Adresse d’écoute du serveur HTTP	0.0.0.0
PORT	Port d’écoute	3038 (docv-back), 3040 (enso-back). Fronts : 3032 (enso-front), 3005 (docv-front prévu). Voir PORTS_ENSO.md.
ANCHORING_URL	URL de l’API d’ancrage (serveur services)	À définir selon l’infra
IA_API_URL	URL de l’API IA (sous-module ai)	Nominal : http://192.168.1.164:3022 (API IA sur le serveur smart_ide / LAN). Poste client : utiliser cette URL si l’API ne tourne pas localement ; sinon http://localhost:3022. test, pprod, prod : http://192.168.1.164:3022. Voir PORTS_ENSO.md.
DOCV_FILE_STORAGE_DIR	(optionnel) Répertoire des octets pour POST .../documents/binary	Ex. /var/lib/docv/uploads ; sans cette variable, pas de téléchargement binaire (503).
DOCV_UPLOAD_MAX_BYTES	(optionnel) Taille max du corps d’upload binaire	Défaut 10485760.
DOCV_DP_GIT_SYNC	(optionnel) 1 / true : après miroir sous data/dossiers-permanents/, enchaîne git add / commit / push	Nécessite un clone « writable » avec remote configuré ; voir features/DOSSIERS_PERMANENTS_DATA_GIT.md.
DOCV_DP_GIT_REPO_ROOT	Racine du dépôt Git (monorepo enso ou copie miroir)	Ex. /srv/4NK/enso-test/repo
DOCV_DP_GIT_DATA_SUBPATH	Sous-chemin des DP versionnés depuis la racine	Défaut data/dossiers-permanents
DOCV_DP_GIT_REMOTE	Nom du remote pour git push	Défaut origin
DOCV_DP_GIT_BRANCH	Branche distante ciblée (git push HEAD:refs/heads/…)	Ex. test ; si vide, git push sans refspec explicite

Note JWT_SECRET : le changer sur docv-back invalide les access tokens déjà émis. Les utilisateurs connectés doivent se reconnecter. Côté enso-front, une réponse 401 sur les appels docv (docvFetch, upload binaire, etc.) déclenche la même séquence que la déconnexion menu : effacement jeton / état OAuth dans le sessionStorage, puis GET /oauth/sign-out docv avec return_url = /?signed_out=1 (accueil ; enchaînement vers /login?signed_out=1 — voir invalidateLocalSessionAndGoHome, ensoSignedOutHomeReturnUrl).

Fichier d’exemple (à copier et renseigner, ne pas commiter les valeurs réelles) :

# .env.example (à copier en .env)
DATABASE_URL=postgres://user:password@localhost:5432/docv_test
JWT_SECRET=your-jwt-secret
HOST=0.0.0.0
PORT=3038
ANCHORING_URL=
IA_API_URL=

4.2 Fronts (enso-front)

enso-front (Next.js) : copier enso/enso-front/.env.example vers .env.local (dev) ou .env.production.local (serveur, non versionné). Le script deploy/scripts_v2/remote/bootstrap-enso-remote.sh écrit un fichier enso/enso-front/.env.production.local aligné sur ENSO_PUBLIC_ORIGIN (mêmes clés que l’exemple, secret OAuth docv partagé avec la valeur générée pour docv-back).

Variable	Portée	Description
NEXT_PUBLIC_ENSO_PUBLIC_ORIGIN	client	Origine publique du site enso (ex. https://test.enso.4nkweb.com).
NEXT_PUBLIC_DOCV_OAUTH_CLIENT_ID	client	Identifiant client OAuth (ex. enso-web, aligné sur docv-back).
NEXT_PUBLIC_DOCV_OAUTH_AUTHORIZE_BASE	client	URL de base du endpoint authorize docv (ex. …/docv-api/oauth/authorize).
NEXT_PUBLIC_DOCV_API_BASE	client	Optionnel : base URL des appels API métier avec Bearer (/api/v1/…). Défaut navigateur : origine du site + /docv-api. Écrit par deploy/scripts_v2/remote/bootstrap-enso-remote.sh sur les déploiements bootstrap.
DOCV_OAUTH_TOKEN_URL	serveur Next	URL du endpoint token docv (sur la machine : en général http://127.0.0.1:3038/oauth/token).
DOCV_OAUTH_CLIENT_ID	serveur Next	Même id que côté public.
DOCV_OAUTH_CLIENT_SECRET	serveur Next	Secret partagé avec docv-back (OAUTH_CLIENT_SECRET).

Si la route /api/auth/docv-token renvoie Configuration serveur incomplète (secret OAuth), DOCV_OAUTH_CLIENT_SECRET est absent ou vide dans .env.production.local côté Next : il doit être identique à OAUTH_CLIENT_SECRET dans docv/docv-back/.env. Le script bootstrap-enso-remote.sh synchronise ce secret vers enso-front et enso-back même lorsqu’il ne réécrit pas docv-back/.env (fichier déjà présent). L’unité deploy/systemd/enso-enso-front.service charge ce fichier via EnvironmentFile (comme enso-back avec .env) : après modification des secrets, systemctl --user daemon-reload puis systemctl --user restart enso-enso-front, ou relancer deploy/systemd/install-user-units.sh si le modèle d’unité a changé.

Chaque déploiement distant (deploy/scripts_v2/remote/enso-remote-phase.sh) exécute sync-docv-oauth-secret-to-enso.sh : copie OAUTH_CLIENT_SECRET depuis docv/docv-back/.env vers DOCV_OAUTH_CLIENT_SECRET dans enso-front/.env.production.local et enso/enso-back/.env, afin d’éviter un front déployé sans secret alors que docv en dispose déjà.

HTTP 500 sur cette route avec un corps JSON : en pratique, le cas le plus fréquent est le secret manquant ci‑dessus (Next ne voit pas DOCV_OAUTH_CLIENT_SECRET). Après correction des fichiers, systemctl --user restart enso-enso-front (ou un nouveau déploiement) recharge l’EnvironmentFile. Sinon, lire le corps de la réponse dans les outils réseau du navigateur : une clé detail (renvoyée par docv) indique le rejet côté /oauth/token (code invalide, redirect_uri, etc.). Vérifier aussi que nginx envoie location /api/ vers enso-front (3032) et non vers enso-back (3040) (voir docs/operations/NGINX_ENSO_API_ROUTING.md).

En développement : npm run dev (port 3032). Sur les machines test/pprod/prod : npm run start après next build (unit systemd : deploy/systemd/enso-enso-front.service).

Les anciennes variables Vite VITE_DOCV_* ne sont plus utilisées ; tout l’OAuth / callback passe par les clés ci-dessus et la route handler /api/auth/docv-token.

Le tableau de bord et la barre latérale appellent docv-back en HTTPS sur {origine publique}/docv-api/api/v1/… avec l’en-tête Authorization: Bearer (token d’accès OAuth). Nginx route le préfixe /docv-api/ vers docv-back (port 3038 sur l’infra de référence). Liste des routes HTTP et câblage front : features/DOCV_API_ENSO_FRONT_MAP.md §1 ; socle, migrations et narrative : docv/IMPLEMENTATION.md §3.1. Le front agrège les requêtes stubs (notifications, pending-documents, conversations) dans DocvStubListsProvider via Promise.all.

4.3 Par environnement

• test : BDD dédiée (ex. docv_test, enso_test), secrets de test, URLs pointant vers les domaines de test.
• pprod : BDD et secrets de préproduction ; URLs de préproduction.
• prod : BDD et secrets de production ; URLs de production.

Les fichiers .secrets/<env>/ (ex. .secrets/test/, .secrets/pprod/, .secrets/prod/) peuvent contenir les .env ou fichiers équivalents par projet ; à déployer manuellement ou via script (hors dépôt).

---

5. Build

5.1 Fronts

Depuis la racine du monorepo :

npm install
npm run build

Cela build les workspaces configurés (enso/enso-front). enso-front produit le build Next.js (.next/, next start) sur le port 3032 ; le reverse proxy doit router /api/ vers enso-front (3032) pour les Route Handlers Next (ex. /api/auth/docv-token), pas vers enso-back (3040).

Pour un seul front enso :

cd enso/enso-front
npm install
npm run build

5.2 Backends (Rust)

Depuis la racine :

# docv (workspace : docv-shared + docv-back)
cargo build --release --manifest-path docv/Cargo.toml --workspace


# enso-back
cargo build --release --manifest-path enso/enso-back/Cargo.toml

Binaires produits (à déployer sur la machine cible) :

• docv/target/release/docv-back
• enso/enso-back/target/release/enso-back

enso-back : enso/enso-back/target/release/enso-back après cargo build --release --manifest-path enso/enso-back/Cargo.toml, avec .env (PORT=3040 typiquement).

---

6. Base de données PostgreSQL

Sur chaque machine (test, pprod, prod), créer les bases et utilisateurs nécessaires. Exemple pour l’environnement test :

sudo -u postgres psql -c "CREATE USER enso_test WITH PASSWORD '...';"
sudo -u postgres psql -c "CREATE DATABASE docv_test OWNER enso_test;"
sudo -u postgres psql -c "CREATE DATABASE enso_test OWNER enso_test;"

Exécuter les migrations (SQL ou outil utilisé par le projet — SQLx migrate, Diesel, etc.) avant le premier démarrage des backends. Les migrations sont dans le dépôt (ex. docv/docv-back/migrations/ ou équivalent) et doivent être appliquées avec les bons droits.

---

7. Déploiement sur chaque machine

7.1 Répertoire cible

Convention courante sur l’infra 4NK : /srv/4NK/<domaine ou projet>/. Pour enso, exemples possibles :

• test : /srv/4NK/enso-test/ (ou un répertoire par produit : docv-test, enso-test).
• pprod : /srv/4NK/enso-pprod/
• prod : /srv/4NK/enso-prod/

À aligner avec la convention réelle des autres projets sur les machines.

7.15 Chaîne deploy/scripts_v2 et outillage partagé (dev_ai / ai_dev)

Le dépôt inclut deploy/scripts_v2/deploy.sh : synchronisation Git optionnelle en local, puis SSH vers la cible (ProxyJump via deploy/lib/ssh.sh dans l'outillage partagé, résolu par AI_DEV_ROOT, DEV_AI_ROOT, IA_DEV_ROOT, ou chemins ~/code/dev_ai, ~/code/ai_dev, repli ~/code/ia_dev) pour git pull, builds Rust/npm et restart des unités systemd --user enso-* si installées.

• Documentation opérationnelle : deploy/README.md ; intégration détaillée : AI_DEV_INTEGRATION.md.
• Fichier enso-deploy.env : de préférence <outil>/.secrets/enso/<env>/enso-deploy.env ; repli .secrets/<env>/enso-deploy.env dans le monorepo (voir deploy/enso-deploy.env.example). Synchronisation : deploy/scripts_v2/sync-secrets-to-ai_dev.sh.
• Depuis le monorepo : ./deploy/deploy.sh <test|pprod|prod> [options] (wrapper vers deploy/deploy.sh enso de l'outil) ou ~/code/dev_ai/deploy/deploy.sh enso <env> [options] selon l'emplacement du clone (voir configuration projet côté tooling, ex. deploy.repository_root vers le clone enso).

7.2 Contenu à déployer

Pour chaque machine et chaque environnement :

1. Backends : copier les binaires release docv-back et enso/enso-back/target/release/enso-back (avec .env, PORT=3040 selon PORTS_ENSO.md).
2. Fronts : pour enso-front, déployer le build (.next/ ou dist/ selon la stack) et exécuter le serveur de prod sur 3032 ; proxy /api vers enso-back côté nginx si nécessaire.
3. Config : copier le fichier .env (ou équivalent) pour chaque processus, avec les variables correspondant à l’environnement (test, pprod, prod).
4. Migrations : déjà appliquées (voir section 6).

7.3 Démarrage des services

Sans Docker, les processus peuvent être gérés par systemd (recommandé) ou par un gestionnaire de processus (supervisor, etc.). Exemple de unit systemd pour un backend :

[Unit]
Description=docv-back (enso test)
After=network.target postgresql.service

[Service]
Type=simple
User=ncantu
WorkingDirectory=/srv/4NK/enso-test
EnvironmentFile=/srv/4NK/enso-test/docv-back.env
ExecStart=/srv/4NK/enso-test/bin/docv-back
Restart=on-failure

[Install]
WantedBy=multi-user.target

Adapter pour enso-back (3040) et enso-front sur 3032. Les ports sont fixés dans PORTS_ENSO.md et doivent correspondre à la configuration du proxy (voir section 8).

7.4 Résumé par machine

Machine	Rôle	Déploiement
test (192.168.1.101)	Environnement de test	docv-back, enso-back, enso-front ; BDD test ; config test.
pprod (192.168.1.102)	Préproduction	Idem avec BDD et config pprod.
prod (192.168.1.103)	Production	Idem avec BDD et config prod.

7.5 Machine LAN 192.168.1.164 (smart_ide) — enso-back dans ~/code/enso

Pour déployer uniquement enso-back (Node) sur l’hôte 192.168.1.164, avec le code sous ~/code/enso/enso-back (créé si absent) :

1. Cloner ou disposer du dépôt enso sur la machine d’où vous lancez le script (poste de dev ou autre).
2. Depuis la racine du clone (répertoire qui contient enso/), exécuter :

bash enso/scripts/deploy-enso-back-remote.sh

Variables optionnelles : TARGET_HOST (défaut 192.168.1.164), DEPLOY_USER (défaut ncantu), REMOTE_PROJECT (défaut enso → chemin ~/code/enso/enso-back), SSH_OPTS (ex. '-J ncantu@4nk.myftp.biz' si accès via bastion), SKIP_INSTALL=1 pour ne pas lancer npm install sur la cible.

Le script : SSH + rsync (--delete, exclusion de node_modules/ et data/ pour ne pas effacer la persistance distante), mkdir -p …/data/uploads, chmod 750 sur data/ et data/uploads/, puis npm install --omit=dev dans enso-back.

Démarrage sur la cible (exemple) : cd ~/code/enso/enso-back && HOST=0.0.0.0 PORT=3040 ./target/release/enso-back (ou cargo run --manifest-path enso/enso-back/Cargo.toml). Chiffrement au repos, sauvegardes dédiées, antivirus sur uploads/, quotas et réplication ne sont pas couverts par ce script.

---

8. Proxy et certificats

La machine proxy (192.168.1.100) assure :

• Le reverse proxy HTTP/HTTPS (Nginx ou équivalent) vers les backends et fronts déployés sur test, pprod, prod.
• La terminaison SSL (certificats Let’s Encrypt ou existants).
• enso : test.enso.4nkweb.com → 192.168.1.101 ; pprod.enso.4nkweb.com → 192.168.1.102 ; prod.enso.4nkweb.com → 192.168.1.103 (nginx : / → 3032, /api/ → 3040, /docv-api/ → 3038).
• docv : test.docv.4nkweb.com → 101 ; pprod.docv.4nkweb.com → 102 ; prod.docv.4nkweb.com → 103 — API docv-back 3038 (3038 / 3040 enso sont réservés au produit enso) ; docv-front prévu sur 3005 (voir PORTS_ENSO.md).
• Snippets nginx de référence : deploy/nginx/*.locations.snippet (*.enso.* et *.docv.*). Chaque snippet docv rappelle l’inclusion dans un bloc server { listen 443 ssl; server_name … } avec chemins ssl_certificate / ssl_certificate_key (ou équivalent).

8.1 Certificats TLS des vhosts docv

Exigences :

• SNI / SAN : le certificat présenté sur le 443 du proxy pour chaque FQDN doit inclure ce nom en Subject Alternative Name (un certificat par vhost ou SAN multi-noms selon politique infra).
• Chaîne : confiance publique (ex. Let’s Encrypt) ou certificat d’entreprise explicitement approuvé ; pas de certificat auto-signé en production (règles projet).

Contrôle depuis un poste ayant accès au 443 public des FQDN (remplacer le nom de domaine) :

openssl s_client -connect test.docv.4nkweb.com:443 -servername test.docv.4nkweb.com </dev/null 2>&1 \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Répéter pour pprod.docv.4nkweb.com et prod.docv.4nkweb.com. Points à valider sur la sortie : subject / SAN = FQDN attendu, issuer cohérent (ex. Let’s Encrypt), notAfter dans le futur.

La configuration détaillée du proxy (fichiers nginx complets, renouvellement certbot, alignement avec l’infra 4NK) reste à consolider côté exploitation. Référence : documentation infrastructure Cloud 4NK (règles utilisateur).

---

8.2 Front enso : message Vite « This host is not allowed » derrière le proxy

Symptôme (navigateur) : Blocked request. This host ("…") is not allowed. To allow this host, add "…" to preview.allowedHosts in vite.config.

Cause : l'instance sert le build avec vite preview (recommandation actuelle du dépôt : next build puis npm run start sans Vite). À partir de Vite 5, le serveur de preview restreint l'en-tête Host sauf configuration explicite.

Correctif si l'hôte utilise encore Vite : dans enso/enso-front/vite.config.ts (ou .js), ajouter les FQDN attendus derrière le proxy. Section preview (mode vite preview) et, en développement (vite), section server, même tableau allowedHosts :

const allowedHosts = [
  "test.enso.4nkweb.com",
  "pprod.enso.4nkweb.com",
  "prod.enso.4nkweb.com",
  "test.docv.4nkweb.com",
  "pprod.docv.4nkweb.com",
  "prod.docv.4nkweb.com",
] as const;

// server: { … allowedHosts, … }
// preview: { … allowedHosts, … }

Si un docv-front distinct (ex. port 3005) utilise Vite, lister les mêmes noms (ou équivalent) dans son vite.config.

Puis redémarrer le service (ex. systemctl --user restart enso-enso-front).

Pérenne : aligner l'arbre sur le front Next.js du dépôt et l'unité systemd deploy/systemd/enso-enso-front.service (npm run start après next build).

---

9. Checklist d’installation (par environnement)

• Prérequis installés (Node, Rust, PostgreSQL, Git).
• Dépôt cloné et sous-modules initialisés.
• Variables d’environnement définies (.env ou .secrets/<env>/).
• BDD créées et migrations appliquées.
• Build des fronts et des backends effectué.
• Fichiers déployés sur la machine cible (binaires, build Next.js, config).
• Services configurés (systemd ou équivalent) et démarrés.
• Proxy : vhosts HTTPS et certificats (contrôle §8.1 pour docv ; idem enso selon mêmes principes).

---

10. Références

• README.md — index de la documentation.
• ARCHITECTURE_DOCV_ENSO.md — découpage des projets et infra.
• docv/IMPLEMENTATION.md — stack, config back (DATABASE_URL, JWT_SECRET, etc.).
• PLAN_DEVELOPPEMENT.md — jalons et scripts deploy.
• PORTS_ENSO.md — cartographie des ports (déjà utilisés, ports attribués enso, identiques en dev/test/pprod/prod).
• Infrastructure Cloud 4NK — adresses des machines (proxy, test, pprod, prod), accès SSH, conventions de déploiement.