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)

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 :

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) :

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 :

   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 :

   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 :

podman exec cmqjtdige0001gtw95e7cyr3p-app-1 php -r "require '/var/www/html/config/config.inc.php'; PrestaShop\Autoload\PrestashopAutoload::getInstance()->generateIndex();"

Puis vérifier :

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 :

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 :

   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 :

  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.