Skip to main content

Transfert des commande des boutiques en ligne vers le serveur 4D

📦 Documentation Flux Commandes WooCommerce → NAS Synology

1️⃣ Vue d’ensemble du flux

  1. Un client passe une commande sur le site e-commerce (WordPress + WooCommerce).
  2. WooCommerce exporte automatiquement la commande au format XML via une tâche d’export (HTTP POST).
  3. L’appel est envoyé vers une URL publique HTTPS exposée par Nginx Proxy Manager (NPM).
  4. NPM termine le TLS (HTTPS) et reverse-proxy la requête vers Apache en HTTP.
  5. Le script PHP web_order.php :
    • valide la requête,
    • valide le XML,
    • enregistre le fichier localement,
    • journalise l’opération,
    • déclenche le script Python.
  6. Le script Python transfère le fichier vers le NAS Synology, puis archive le fichier localement.
  7. Les logs sont conservés localement et exploités dans Grafana.

✅ Le flux est entièrement fonctionnel, traçable, et découplé (proxy / PHP / Python / NAS).

2️⃣ Configuration côté WooCommerce

  • Menu : WooCommerce > Exporter Commandes
  • Section : Tâches de changement d’état
  • Type de destination : HTTP POST
  • Format : XML

Paramètres utilisés

Paramètre Valeur
Nom de la tâche export vers 4D V2
Format d’export XML
Destination HTTP POST
URL cible https://order.tarbouriech.tech/web_order.php

➡️ À chaque changement d’état de commande, WooCommerce envoie le XML par POST vers l’endpoint.

3️⃣ Reverse Proxy – Nginx Proxy Manager

Rôle

  • Exposer une URL HTTPS publique
  • Terminer le TLS
  • Forwarder les requêtes vers Apache en HTTP interne

Configuration effective

  • Domaine : order.tarbouriech.tech
  • Scheme : http
  • Forward Host : 192.168.1.17
  • Forward Port : 80
  • Forward Path : (vide)
  • Force SSL : activé
  • Certificat TLS : géré par NPM

⚠️ Apache n’est PAS configuré en HTTPS.
⚠️ Toute la gestion HTTPS est volontairement centralisée dans NPM.

4️⃣ Serveur Apache (Debian)

Point fondamental

Sur Debian, Apache utilise par défaut :

/var/www/html/

➡️ Tous les chemins doivent impérativement être alignés sur cette racine.

VirtualHost utilisé

<VirtualHost *:80>
    ServerName order.tarbouriech.tech

    DocumentRoot /var/www/html/web_orders/public

    <Directory /var/www/html/web_orders/public>
        Options -Indexes
        AllowOverride None
        Require all denied
        
        # on fait correspondre uniquement les scripts nommés : web_order_*.php (web_order.php et web_order_O.php)
        <FilesMatch "^web_order_.*\.php$">
            Require all granted
        </FilesMatch>
    </Directory>
# token

# SetEnv ORDER_WEBHOOK_SECRET "529805d6c4e1f6aa13de859784835883f9981db3a75b15045f3ccd921258c84a"
    # PHP strict
    php_admin_flag engine On
    php_admin_value disable_functions "shell_exec,system,passthru"

    # Logs dédiés
    ErrorLog ${APACHE_LOG_DIR}/order_error.log
    CustomLog ${APACHE_LOG_DIR}/order_access.log combined
</VirtualHost>

❌ Aucun wildcard (ServerAlias *.tarbouriech.tech)
❌ Aucune redirection HTTPS côté Apache

5️⃣ Script PHP – web_order.php

📂 Chemin

/var/www/html/web_orders/public/web_order.php

📌 Rôle

  • Endpoint HTTP POST pour WooCommerce

Fonctionnement détaillé

  1. Vérifie la méthode HTTP (POST uniquement)
  2. Récupère le payload brut
  3. Vérifie la présence et la validité du XML
  4. Génère un nom unique :
    • order_YYYYMMDD_HHMMSS_HASH.xml
  5. Enregistre le fichier dans : 
    /var/www/html/web_orders/private/orders/
  6. Écrit un log dans web_order.log
  7. Lance le script Python via exec()
  8. Retourne HTTP 200 à WooCommerce

⚠️ Les contrôles HMAC / User-Agent sont temporairement désactivés.

6️⃣ Script Python – send_folder_to_synology.py

📂 Chemin

/var/www/html/web_orders/private/send_folder_to_synology.py

📌 Rôle

  • Transfert sécurisé vers le NAS
  • Archivage local

Fonctionnement

  1. Vérifie la présence de la clé SSH
  2. Se connecte au NAS via SSH (clé privée)
  3. Parcourt les fichiers XML du dossier orders/
  4. Pour chaque fichier :
    • Transfert SCP vers le NAS
    • Renommage order_ → commande_
    • Déplacement vers orders/archive/
  5. Log de chaque étape

7️⃣ NAS Synology

📂 Dossier cible

/volume1/DATAS/4DDocuments/WebOrders/FTP/

📄 Nom des fichiers

commande_YYYYMMDD_HHMMSS_HASH.xml

8️⃣ Logs et supervision

Logs locaux

/var/www/html/web_orders/private/orders/web_order.log

Contient :

  • réception des commandes
  • erreurs de validation
  • transferts SCP
  • archivage

Grafana

  • Les logs sont collectés pour :
    • supervision
    • alerting
    • audit

9️⃣ Gestion multi-boutiques

Pour un second site WooCommerce :

Élément Suffixe
PHP web_order_O.php
Python send_folder_to_synology_O.py
Dossier orders_O/
Log web_order_O.log

➡️ Les flux sont totalement isolés.

🔄 Schéma du flux

WooCommerce
    |
    | HTTP POST (XML)
    v
Nginx Proxy Manager (HTTPS)
    |
    | HTTP interne
    v
Apache (Debian)
    |
    | web_order.php
    v
Stockage local + logs
    |
    v
send_folder_to_synology.py
    |
    v
NAS Synology

🧪 Tests de validation

curl -X POST -H "Content-Type: application/xml"      --data '<test>ok</test>'      https://order.tarbouriech.tech/web_order.php

➡️ Réponse attendue : HTTP 200

📝 TODO (sécurité & robustesse)

  • Réactiver la signature HMAC (token partagé)
  • Ajouter un mécanisme anti-replay (timestamp + nonce)
  • Désactiver les sessions PHP pour cet endpoint
  • Validation XML par XSD
  • Lock / file d’attente côté Python (anti double exécution)
  • Rotation de la clé SSH
  • Alerting Grafana sur erreurs critiques

🚀 Améliorations possibles

  • Remplacer SCP par SFTP ou API Synology
  • Introduire une queue (RabbitMQ / Redis) pour lisser la charge
  • Chiffrement applicatif du XML avant transfert
  • Retour d’accusé de réception signé vers WooCommerce

✅ Conclusion

  • Le flux est opérationnel et stable
  • L’architecture est clairement séparée
  • Les erreurs sont tracées
  • La solution est scalable et duplicable

Ce document sert de référence officielle pour la maintenance, l’audit et les évolutions futures.

No comments to display

Back to top