yacine/edubox
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

clean: suppression complète PrestaShop

Browse Source
This commit is contained in:
EduBox Dev
2026-06-20 13:57:37 +00:00
parent 20baf3878f
commit dd49993157
25 changed files with 496 additions and 249 deletions
Download Patch File Download Diff File Expand all files Collapse all files
SESSION_NOTES.md
+221
View File
@@ -84,3 +84,224 @@ 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 :
```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.