edubox/SESSION_NOTES.md

# Notes de session EduBox - 17 juin 2026

## ✅ Ce qui fonctionne

- Agent EduBox v0.2.7 déployé avec binaires Linux/Mac/Windows.
- Connexion WordPress via URL publique fonctionne (wp-admin inclus).
- Proxy Next.js gère correctement les POST (duplex: half), les cookies, les headers X-Forwarded.
- Certificats TLS on-demand Caddy fonctionnent pour les sous-domaines d'instances.
- Reset d'instance corrige : le serveur envoie maintenant le `ComposeConfig` complet.
- `PUBLIC_DOMAIN` inclut le sous-domaine de l'instance (`<id>.<domain>`).

## ⚠️ Problème en cours : PrestaShop

L'installation automatique de PrestaShop 8.1 se termine avec succès, mais l'accès via l'URL publique ou localhost provoque des redirections incorrectes :

- `curl -I http://localhost:8080` retourne `302 Location: http://cmqiiso9g0001mfap4wv7a690.alfrednobel.edudeploy.com/`
- `curl -I https://cmqiiso9g0001mfap4wv7a690.alfrednobel.edudeploy.com/` retourne `302` vers la même URL (boucle infinie).
- `curl -I https://cmqiiso9g0001mfap4wv7a690.alfrednobel.edudeploy.com/index.php` retourne `200 OK`.

### Hypothèses / pistes

1. PrestaShop stocke le domaine shop en base (`ps_configuration` : `PS_SHOP_DOMAIN`, `PS_SHOP_DOMAIN_SSL`).
   - Avec `PS_ENABLE_SSL=1`, il est configuré avec l'URL publique en HTTPS.
   - Quand on accède via `localhost`, il redirige vers l'URL publique.
2. L'accès à `/` redirige vers l'URL canonique, ce qui crée une boucle via le proxy.
3. Il faudrait un équivalent PrestaShop du mu-plugin WordPress pour forcer le domaine à la volée selon `HTTP_HOST`.

### Template PrestaShop actuel (seed.ts)

```yaml
DB_SERVER: db
DB_PORT: 3306
DB_NAME: prestashop
DB_USER: prestashop
DB_PASSWD: prestashop
DB_PREFIX: ps_
PS_DOMAIN: {PUBLIC_DOMAIN}
PS_SHOP_NAME: PrestaShop 8.1 vierge
PS_INSTALL_AUTO: "1"
PS_INSTALL_DB: "0"
PS_ENABLE_SSL: "1"
PS_LANGUAGE: fr
PS_COUNTRY: fr
ADMIN_MAIL: admin@edubox.local
ADMIN_PASSWD: EduboxPrestashop2024!
PS_FOLDER_ADMIN: admin
PS_FOLDER_INSTALL: install
PS_DEV_MODE: "1"
```

## 🚀 Prochaines étapes suggérées

1. **Option rapide** : accepter que l'accès étudiant se fasse via l'URL publique. Vérifier que `https://<id>.alfrednobel.edudeploy.com/index.php` fonctionne et que la boutique est utilisable.
2. **Option propre** : développer un module/override PrestaShop qui :
   - Détecte `HTTP_HOST` / `X-Forwarded-Host`.
   - Met à jour `PS_SHOP_DOMAIN` et `PS_SHOP_DOMAIN_SSL` dynamiquement.
   - Permet l'accès via localhost ET via l'URL publique.
3. **Alternative** : installer PrestaShop avec `PS_DOMAIN=localhost:8080` et laisser le proxy réécrire les URLs (mais c'est complexe).

## 📁 Instance de test actuelle

- ID : `cmqiiso9g0001mfap4wv7a690`
- Type : PrestaShop 8.1 vierge
- Port : 8080
- Nœud : OMEGA-GAMER (PC étudiant de Yacine)

## 📝 Commits récents

- `5c4c9f3` fix(server/api): envoi du ComposeConfig lors d'un reset d'instance
- `2d57857` fix(server/api): PUBLIC_DOMAIN inclut le sous-domaine de l'instance
- `2b31ec7` fix(seed): PrestaShop installé avec SSL et sans dynamic domain

## 🔧 Commandes utiles pour reprendre

Sur le serveur :
```bash
cd /opt/edubox
docker logs edubox-server --tail 50
docker exec edubox-server sh -c "cd /app && npx prisma db seed"
```

Sur le PC étudiant (PowerShell) :
```powershell
podman ps --format "table {{.Names}}`t{{.Status}}`t{{.Ports}}"
podman logs -f cmqiiso9g0001mfap4wv7a690-app-1
```

---

## 🔧 Correctif PrestaShop - 18 juin 2026

### Principe
Un override `Configuration.php` est monté dans `/var/www/html/override/classes/Configuration.php`.
Il surcharge `Configuration::get()` pour retourner dynamiquement :
- `PS_SHOP_DOMAIN` / `PS_SHOP_DOMAIN_SSL` = host de la requête (localhost:8080 ou sous-domaine public)
- `PS_SSL_ENABLED` = 0 quand la requête n'est pas HTTPS, pour éviter les redirections infinies en local

L'override truste aussi les headers `X-Forwarded-Proto`, `X-Forwarded-Host` et `X-Forwarded-Port` envoyés par le proxy Next.js.

### Fichiers modifiés
- `agent/psplugins/Configuration.php` (nouveau)
- `agent/prestashop.go` (nouveau : écriture de l'override)
- `agent/docker.go` (substitution du placeholder `{PS_OVERRIDES_DIR}`)
- `agent/build.sh` (version 0.2.8)
- `server/prisma/seed.ts` (montage du volume pour les templates PrestaShop)
- `server/app/dashboard/download/page.tsx` (version Windows 0.2.8)

### Déploiement effectué
- Image serveur rebuildée et redémarrée (`docker compose up -d --build server`)
- Seed relancé : `docker exec edubox-server sh -c "cd /app && npx prisma db seed"`
- Binaire agent Windows v0.2.8 généré : `agent/edubox-agent-v0.2.8.exe` et copié dans `server/public/`

### Prochaines actions manuelles
Sur le PC étudiant (OMEYA-GAMER) :
1. Arrêter l'agent v0.2.7 en cours.
2. Télécharger le nouvel agent v0.2.8 (dashboard → Téléchargements ou URL `/edubox-agent-v0.2.8.exe`).
3. Lancer le nouvel agent.
4. Depuis le dashboard, **réinitialiser** l'instance `cmqiiso9g0001mfap4wv7a690` (le reset recrée les volumes et applique l'override dès l'installation).
5. Tester :
   - `curl -I http://localhost:8080` → `200 OK`
   - `curl -I https://cmqiiso9g0001mfap4wv7a690.alfrednobel.edudeploy.com/` → `200 OK`

### Problème découvert lors du test
La nouvelle instance PrestaShop (`cmqjtdige0001gtw95e7cyr3p`) s'ouvrait bien en **URL publique**, mais `localhost:8089` redirigeait toujours vers le domaine public.

Cause : l'image PrestaShop embarque un `class_index.php` pré-généré qui ne connaît pas notre override `override/classes/Configuration.php`. L'autoloader utilise donc la classe `Configuration` originale, et `Configuration::get('PS_SHOP_DOMAIN_SSL')` retourne la valeur figée en base.

Solution : vider les caches `app/cache/*` et `var/cache/*` après le démarrage du conteneur.

### Fichiers ajoutés/modifiés (suite)
- `agent/prestashop.go` : ajout de `clearPrestaShopCache()` pour effacer les caches après chaque `start`/`reset` d'une instance PrestaShop
- `agent/websocket.go` : appel de `clearPrestaShopCache()` quand `msg.Type == "prestashop"`
- Rebuild du binaire Windows v0.2.8 avec ce fix

### Action requise maintenant
Sur le PC étudiant :
1. Télécharger **à nouveau** l'agent v0.2.8 (le fichier a été regénéré avec le nettoyage de cache).
2. Lancer le nouvel agent.
3. Supprimer/réinitialiser l'instance PrestaShop en cours pour forcer une installation fraîche avec l'agent corrigé.
4. Tester :
   ```powershell
   curl -I http://localhost:<PORT>
   curl -I https://<id>.alfrednobel.edudeploy.com/
   ```
   Les deux doivent retourner `200 OK`.

### Problème suivant : l'override n'est toujours pas chargé
Même après suppression des caches, `Configuration::get('PS_SHOP_DOMAIN_SSL')` retourne le domaine public. L'override `override/classes/Configuration.php` est bien présent, mais PrestaShop 8 utilise l'autoloader namespacé `PrestaShop\Autoload\PrestashopAutoload`. L'appel à l'ancien `PrestaShopAutoload::generateIndex()` ne met pas à jour l'index actif.

Solution : appeler `PrestaShop\Autoload\PrestashopAutoload::getInstance()->generateIndex()` depuis l'agent après le démarrage d'une instance PrestaShop.

### Fichiers ajoutés/modifiés (suite)
- `agent/prestashop.go` : `clearPrestaShopCache()` supprime les caches et régénère l'index via l'autoloader namespacé
- `agent/websocket.go` : appel de `clearPrestaShopCache()` pour les instances PrestaShop
- Rebuild du binaire Windows v0.2.8

### Action requise maintenant
Sur le PC étudiant :
1. **Télécharger à nouveau** l'agent v0.2.8 (regénéré avec le fix d'index).
2. Lancer le nouvel agent.
3. Supprimer/réinitialiser l'instance PrestaShop pour qu'elle soit recréée avec l'agent corrigé.
4. Tester :
   ```powershell
   curl -I http://localhost:<PORT>
   curl -I https://<id>.alfrednobel.edudeploy.com/
   ```

### Test immédiat sur l'instance actuelle
Sans réinstaller, on peut forcer la régénération de l'index dans le conteneur :
```powershell
podman exec cmqjtdige0001gtw95e7cyr3p-app-1 php -r "require '/var/www/html/config/config.inc.php'; PrestaShop\Autoload\PrestashopAutoload::getInstance()->generateIndex();"
```
Puis vérifier :
```powershell
podman exec cmqjtdige0001gtw95e7cyr3p-app-1 php -r "require '/var/www/html/config/config.inc.php'; echo Configuration::get('PS_SHOP_DOMAIN_SSL').PHP_EOL;"
```
Le résultat doit être `localhost:8089` au lieu du domaine public.

### Commits à faire
- `feat(agent): override PrestaShop dynamique pour HTTP_HOST`
- `fix(agent): régénère l'index PrestaShop pour charger l'override`
- `fix(server/seed): monte l'override PrestaShop dans les templates`
- `chore(agent): bump v0.2.8`

---

## ✅ Fix final - 18 juin 2026

### Problème réel identifié
`curl -I https://<id>.alfrednobel.edudeploy.com/` retournait `200` (HEAD n'est pas redirigé), mais un GET dans le navigateur provoquait une boucle `ERR_TOO_MANY_REDIRECTS`.

Cause : PrestaShop reçoit les requêtes publiques en HTTP via le proxy Next.js (`upstream = http://<tailscale-ip>:<port>`). Il ne truste pas le header `X-Forwarded-Proto: https`, donc `Tools::usingSecureMode()` retourne `false`. La redirection canonique/compare la requête `http://domaine/` avec l'URL canonique `https://domaine/`, ce qui crée une boucle HTTPS ↔ HTTP.

### Solution retenue
Monter une configuration Apache dans le conteneur PrestaShop qui définit `HTTPS=on` quand `X-Forwarded-Proto` vaut `https` :
```apache
SetEnvIf X-Forwarded-Proto https HTTPS=on
SetEnvIf X-Forwarded-Proto https SERVER_PORT=443
```

### Fichiers modifiés
- `agent/apache/proxy.conf` (nouveau)
- `agent/prestashop.go` (nouveau : écrit la config Apache dans le dossier données de l'agent)
- `agent/docker.go` : substitution du placeholder `{PS_APACHE_CONF_DIR}`
- `server/prisma/seed.ts` : les templates PrestaShop montent `proxy.conf` dans `/etc/apache2/conf-enabled/edubox-proxy.conf`
- `agent/build.sh` : version 0.2.8
- `server/app/dashboard/download/page.tsx` : version Windows 0.2.8

### Déploiement effectué
- Image serveur rebuildée et redémarrée
- Seed relancé
- Binaire agent Windows v0.2.8 regénéré et copié dans `server/public/`

### Action requise sur le PC étudiant
1. Télécharger l'agent v0.2.8 propre :
   ```powershell
   Invoke-WebRequest -Uri "https://alfrednobel.edudeploy.com/edubox-agent-v0.2.8.exe" -OutFile "edubox-agent.exe"
   ```
2. Arrêter l'agent précédent et lancer celui-ci.
3. Supprimer ou réinitialiser l'instance PrestaShop depuis le dashboard pour qu'elle soit recréée avec la config Apache montée.
4. Tester dans le navigateur :
   - `https://<id>.alfrednobel.edudeploy.com/` doit s'ouvrir sans `ERR_TOO_MANY_REDIRECTS`

### État final
- Accès étudiant/professeur via l'URL publique.
- `localhost:<PORT>` redirige toujours vers l'URL publique (comportement PrestaShop normal), mais ce n'est pas bloquant.
- Linux/Mac seront ajoutés plus tard quand Windows sera stable.

### Commits à faire
- `fix(agent): ajoute la conf Apache PrestaShop pour trust X-Forwarded-Proto`
- `fix(server/seed): monte la conf Apache dans les templates PrestaShop`
- `chore(agent): bump v0.2.8`

---

## ✅ Fix final - 18 juin 2026 (v2)

### Analyse
- J'ai lu le code source de PrestaShop 8.1 directement dans l'image Docker (`/var/www/html/classes/Tools.php`).
- `Tools::usingSecureMode()` truste bien `HTTP_X_FORWARDED_PROTO: https`.
- J'ai testé localement avec notre config Apache montée : PHP reçoit bien `X-Forwarded-Proto` et `HTTPS=on`.
- **Conclusion** : la boucle ne vient pas d'un défaut de PrestaShop sur la détection HTTPS en lui-même. Elle vient du fait que, dans la vraie chaîne proxy, PrestaShop est installé avec `PS_ENABLE_SSL=1`, ce qui fige le protocole canonique en `https://`. La moindre incohérence entre ce qui est reçu (HTTP interne) et ce qui est attendu (HTTPS canonique) déclenche une redirection canonique, et le navigateur retombe sur la même URL → boucle infinie.
- PrestaShop 9 (branche `develop`) a exactement la même logique `usingSecureMode()`, donc le même problème se produirait avec le même setup.

### Solution retenue
Ne plus se battre avec les headers : on installe PrestaShop avec `PS_ENABLE_SSL: "0"`. Le conteneur vit en HTTP interne, le proxy public reste en HTTPS, et le proxy Next.js réécrit les liens `http://<public-domain>` en `https://<public-domain>`.

C'est le même principe que WordPress (HTTP interne + réécriture publique), sans avoir besoin d'override/module PrestaShop.

### Fichiers modifiés
- `server/prisma/seed.ts` :
  - `PS_ENABLE_SSL: "0"` pour les templates PrestaShop.
  - Suppression du montage inutile `{PS_APACHE_CONF_DIR}/proxy.conf`.
- `server/app/api/proxy/[[...path]]/route.ts` :
  - Ajout de `http://${cleanHost}` dans la réécriture des headers.
  - Ajout de `http://${cleanHost}` et `//${cleanHost}` dans la réécriture du body.

### Déploiement effectué
- Image serveur rebuildée et redémarrée.
- Seed relancé (`npx prisma db seed`).

### Action requise sur le PC étudiant
1. L'agent v0.2.8 actuel peut être conservé (aucune modification agent nécessaire).
2. Depuis le dashboard, **supprimer ou réinitialiser** l'instance PrestaShop en cours. Cela force une réinstallation fraîche avec `PS_ENABLE_SSL=0` et sans le montage Apache.
3. Tester dans le navigateur :
   - `https://<id>.alfrednobel.edudeploy.com/` doit s'ouvrir sans `ERR_TOO_MANY_REDIRECTS`.
   - L'accès `localhost:<PORT>` redirigera probablement vers l'URL publique (comportement PrestaShop normal quand `PS_DOMAIN` est le domaine public), mais ce n'est pas bloquant.

### Commits à faire
- `fix(server/seed): installe PrestaShop avec SSL désactivé`
- `fix(server/proxy): réécrit les liens http://<public-domain> en https`
- `chore(notes): documente le fix final PrestaShop`

---

## ❌ Fix final - 18 juin 2026 (v2) : échec

### Test utilisateur
Après déploiement du serveur et réinitialisation de l'instance PrestaShop, l'URL publique retourne toujours `ERR_TOO_MANY_REDIRECTS`.

L'utilisateur (Yacine) demande d'arrêter de tâtonner et de consigner l'échec proprement.

### Hypothèses sur la cause persistante
Le fix `PS_ENABLE_SSL=0` + réécriture proxy aurait dû fonctionner si PrestaShop générait des liens `http://<public-domain>` et que le proxy les réécrivait. Le fait que la boucle persiste suggère l'une de ces causes :

1. **Cache navigateur** : le client a conservé une redirection 301/302 en cache, donnant l'impression que la boucle continue alors que le serveur a corrigé.
2. **PrestaShop génère quand même des redirections** :
   - Même avec `PS_ENABLE_SSL=0`, PrestaShop peut rediriger `/` vers l'URL canonique (ex. `index.php` ↔ `/`).
   - Le `.htaccess` généré par PrestaShop contient des règles de rewrite vers `index.php` qui peuvent interagir avec le proxy.
3. **Le proxy ne réécrit pas le header `Location`** : le header `Location` peut contenir une URL que le pattern `http://${cleanHost}` ne capture pas (port explicite `:80`, encodage, ou `//<domain>`).
4. **La réinstallation n'a pas réellement pris le nouveau `ComposeConfig`** : l'instance existante a peut-être conservé des données/volumes, ou l'agent n'a pas reçu le nouveau template.
5. **Caddy redirige HTTP → HTTPS** en amont : si PrestaShop renvoie un `Location: http://<public-domain>/`, Caddy le re-rewrites en `https://`, mais PrestaShop continue d'émettre la redirection `http://` → boucle.

### Ce qu'il faudrait vérifier calmement (plus tard)
- Vider le cache navigateur / tester en navigation privée.
- Vérifier dans le conteneur que `PS_ENABLE_SSL` vaut bien `0` en base :
  ```powershell
  podman exec <id>-app-1 mysql -h db -u root -prootpassword prestashop -e "SELECT name, value FROM ps_configuration WHERE name LIKE 'PS_SSL%';"
  ```
- Vérifier le contenu du `.htaccess` généré et chercher une règle `RewriteRule ... [R]`.
- Faire un `curl -v -L --max-redirs 5 https://<id>.alfrednobel.edudeploy.com/` pour voir la chaîne exacte des `Location`.

### Décision
On met PrestaShop de côté pour l'instant. WordPress fonctionne. On reprendra PrestaShop avec une investigation plus approfondie et méthodique quand l'utilisateur sera disponible.

### Commits à faire (quand on reprendra)
- À déterminer après investigation.