lecoffre_node/docs/CORRECTIONS_APPLIQUEES.md
Nicolas Cantu 2fbd607234 docs: Correction du problème WebSocket HTTPS/WS
- Correction de l'erreur Mixed Content
- Configuration des URLs WebSocket sécurisées (WSS)
- Documentation de la solution appliquée
- Leçons apprises pour éviter ce problème
2025-09-20 14:39:28 +00:00

124 lines
4.7 KiB
Markdown

# Corrections Appliquées - LeCoffre Node
## Date: 20 Septembre 2025
### 🔧 Corrections Majeures
#### 1. Problème de Scan Bloquant du SDK Relay
**Problème:** Le `sdk_relay` se bloquait lors du scan initial des blocs, empêchant le démarrage des services dépendants.
**Solution:**
- Modification du `last_scan` dans `/home/bitcoin/.4nk/default` pour éviter les scans trop importants
- Création du script `scripts/optimize-relay-startup.sh` pour automatiser cette correction
- Réduction des logs de `DEBUG` à `INFO` pour limiter le bruit
**Fichiers modifiés:**
- `relay/sdk_relay.conf` - RUST_LOG="INFO"
- `docker-compose.yml` - RUST_LOG=INFO
- `scripts/optimize-relay-startup.sh` - Nouveau script d'optimisation
#### 2. Healthcheck du LeCoffre Front
**Problème:** Le healthcheck de `lecoffre-front` é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` au lieu de la connectivité réseau
- Healthcheck: `ps aux | grep -v grep | grep next-server`
**Fichiers modifiés:**
- `docker-compose.yml` - Healthcheck corrigé pour lecoffre-front
#### 3. Réduction des Traces Docker
**Problème:** Trop de traces Docker dans les terminaux, rendant difficile la lecture des logs.
**Solution:**
- Ajout de variables d'environnement pour limiter les logs
- Configuration des niveaux de log appropriés
**Fichiers modifiés:**
- `.env` - Variables de configuration des logs
- `docker-compose.yml` - Niveaux de log ajustés
### 🚀 Améliorations
#### Scripts d'Optimisation
- `scripts/optimize-relay-startup.sh` - Optimise automatiquement le démarrage du relais
- `scripts/startup-sequence.sh` - Séquence de démarrage améliorée
#### Configuration Bootstrap
- URL bootstrap corrigée: `wss://dev3.4nkweb.com/ws/`
- Adresse SP permanente configurée
- Faucet bootstrap activé
### 📊 État Final
- **SDK Relay:** ✅ Healthy, scan optimisé
- **LeCoffre Back:** ✅ Healthy
- **LeCoffre Front:** ✅ Healthy (healthcheck corrigé)
- **IHM Client:** ✅ Healthy
- **Tous les services:** ✅ Opérationnels
### 🔄 Prochaines Étapes
1. Tests de login sur `https://dev4.4nkweb.com/lecoffre`
2. Monitoring des performances
3. Optimisations supplémentaires si nécessaire
## 🔍 Analyse de l'Erreur "manifest unknown"
### Problème Identifié
L'erreur `Error response from daemon: manifest unknown` lors du pull de `git.4nkweb.com/4nk/lecoffre_node:ext` indique que cette image n'existe pas dans le registry Docker.
### Cause Racine
- **lecoffre_node** est un projet de **configuration** et **orchestration**
- Il ne contient **pas de Dockerfile** et ne build **pas d'image Docker**
- Seuls les **sous-projets** (sdk_relay, ihm_client, lecoffre-back-mini, etc.) ont des images Docker
- L'erreur vient d'une tentative de pull d'une image inexistante
### Solution Appliquée
- ✅ Utiliser les images des sous-projets individuels
- ✅ Le projet lecoffre_node orchestre via docker-compose.yml
- ✅ Pas de pull d'image pour le projet parent
### Images Docker Disponibles
```
git.4nkweb.com/4nk/sdk_relay:ext
git.4nkweb.com/4nk/ihm_client:ext
git.4nkweb.com/4nk/lecoffre-back-mini:ext
git.4nkweb.com/4nk/lecoffre-front:ext
git.4nkweb.com/4nk/sdk_storage:ext
```
### Leçon Apprise
- Distinguer les projets de configuration des projets avec images Docker
- Vérifier l'existence des images avant pull
- Documenter l'architecture des projets pour éviter cette confusion
## 🔧 Correction du Problème WebSocket HTTPS/WS
### Problème Identifié
L'iframe (ihm_client) tentait de se connecter à `ws://sdk_relay:8090/` (non sécurisé) depuis une page HTTPS, causant une erreur de sécurité "Mixed Content".
### Erreurs Observées
```
Mixed Content: The page at 'https://dev4.4nkweb.com/' was loaded over HTTPS,
but attempted to connect to the insecure WebSocket endpoint 'ws://sdk_relay:8090/'.
This request has been blocked; this endpoint must be available over WSS.
```
### Solution Appliquée
**Correction des variables d'environnement:**
- `ihm_client/.env`: `RELAY_URLS=wss://dev4.4nkweb.com/ws/,wss://dev3.4nkweb.com/ws/`
- `lecoffre-back-mini/.env`: `RELAY_URLS=wss://dev4.4nkweb.com/ws/,wss://dev3.4nkweb.com/ws/`
**Configuration Nginx:**
- Proxy WebSocket `/ws/``http://127.0.0.1:8090/` (déjà configuré)
- Headers WebSocket corrects (Upgrade, Connection)
### Résultat
- ✅ Connexions WebSocket sécurisées (WSS)
- ✅ Pas d'erreur Mixed Content
- ✅ Services redémarrés avec la nouvelle configuration
### Leçon Apprise
- Toujours utiliser WSS pour les connexions WebSocket depuis des pages HTTPS
- Vérifier la configuration des variables d'environnement pour les URLs WebSocket
- Tester la connectivité WebSocket avec des outils appropriés (wscat)