# Installation de la version de test sur OVH Performance

Le dossier est prêt à être configuré pour **PHP 8.3 + MySQL**, sans dépendance Composer et sans processus Python permanent. Le déploiement sur OVH n’a pas été effectué : il manque les paramètres MySQL, l’accès SFTP/SSH et la configuration du sous-domaine de test. Ce document concerne une installation privée de test, pas l’activation des commandes réelles.

## Comptes prévus

| Responsable | Identifiant | Droits |
|---|---|---|
| Alex | catering@rugbybwest.be | Créer, modifier et publier les menus |
| Céline | events@rugbybwest.be | Consulter les commandes, exporter, suivre les demandes, modifier le code club |

Ces adresses servent uniquement d’identifiants de connexion. Aucun message n’est envoyé. Les mots de passe sont générés lors de l’installation, affichés une seule fois dans votre terminal privé puis enregistrés sous forme d’empreintes bcrypt avec préhash SHA-256. Il n’y a aucun mot de passe universel dans l’archive. Ne réutilisez pas les mots de passe de la démonstration Python.

## 1. Préparer OVH

Dans OVH Manager, retrouver l’hébergement Performance et vérifier :

- Version PHP **8.3**, extension PDO MySQL et version MySQL/MariaDB disponible.
- Une base MySQL **vide et dédiée au test**, et les paramètres serveur, nom de base, utilisateur et mot de passe. Ne pas utiliser la base des sites existants.
- Un accès SFTP et SSH au dossier de cet hébergement. Performance est une offre mutualisée : ne pas appliquer les instructions d’un VPS.

La compatibilité PHP/MySQL est documentée par OVH :

- [Configurer l’environnement et PHP](https://docs.ovhcloud.com/fr/guides/web-cloud/web-hosting/configure-your-web-hosting)
- [Hébergement MySQL](https://www.ovhcloud.com/fr/web-hosting/mysql-hosting/)

L’exécution PHP 8.3 a été testée localement. La connexion, les droits SQL, Apache et les sessions sur **votre** hébergement doivent être vérifiés après installation. Cette validation ne peut pas être remplacée par les tests locaux.

## 2. Déposer les fichiers

Décompresser `repas-ovh-test.zip` et transférer le dossier `ovh` vers un nouveau dossier de votre compte d’hébergement, par exemple **repas-test**. Ne pas remplacer le dossier d’un site existant.

Structure attendue :

```text
repas-test/
  .htaccess               refuse l’accès au dossier parent
  config.php              configuration privée, à créer
  app/                    logique PHP et page HTML privées
  bin/                    scripts CLI privés
  sql/                    structure de la base
  tests/                  tests, hors accès public
  var/sessions/           sessions privées, créé par l’installation
  public/                 SEUL dossier à exposer comme racine multisite
    .htaccess
    index.php
    app.js
    style.css
```

Dans la configuration **Multisite** d’OVH, le dossier racine du sous-domaine de test doit être **repas-test/public**, jamais `repas-test` ni `app`. Le `.htaccess` parent est une protection supplémentaire ; il ne remplace pas ce choix de racine.

Le fichier `.ovhconfig.example` est un exemple à contrôler dans OVH Manager. **Ne le copiez pas aveuglément à la racine de tout l’hébergement** : un `.ovhconfig` global peut modifier la version PHP des autres sites. OVH limite son emplacement à la racine ou au premier niveau ; le dossier `repas-test/public` est plus profond. Faire vérifier la portée effective de PHP pour ce multisite avant toute modification globale.

## 3. Configurer l’accès privé et MySQL

Dans votre session SSH, placer le terminal dans le dossier `repas-test`. Vérifier d’abord `php -v` : le PHP en ligne de commande peut différer du PHP web. Si nécessaire, demander à OVH le chemin de l’exécutable PHP 8.3 pour votre offre.

```sh
php bin/hash.php
```

Le script affiche un mot de passe aléatoire pour l’accès privé à la version de test et son empreinte. Conserver le mot de passe dans votre gestionnaire de mots de passe. Copier **uniquement l’empreinte** dans la configuration.

Copier `config.example.php` en **config.php**, dans `repas-test/`, hors de `public/`, puis renseigner :

- `db.dsn` : hôte et nom exacts de la base MySQL OVH.
- `db.user` et `db.password` : accès de cette base dédiée.
- `base_url` : URL HTTPS exacte du sous-domaine de test, sans slash final.
- `preview_password_hash` : empreinte générée par le script.
- `preview_user` : par défaut `bwest-test`.

Conserver `https_only=true`. Restreindre les permissions de `config.php` aux permissions minimales permettant à PHP de le lire (0600 si PHP s’exécute avec votre utilisateur, sinon 0640 et groupe adéquat). Le PHP web et le PHP CLI doivent pouvoir lire la configuration et écrire dans `var/sessions/`.

Les adresses d’Alex et de Céline sont déjà préremplies. `test_email` reste **cedric.gilet@rugbybwest.be** ; `contact_email` est **events@rugbybwest.be**.

Deux modes sont possibles :

| Mode | Comportement |
|---|---|
| `demo` | Menus fictifs, commandes de test et résultats de paiement explicitement simulés |
| `preproduction` | Menus et administration visibles derrière l’accès privé ; nouvelles commandes et simulation bloquées |

**Le mode production est refusé par le serveur**, même si quelqu’un l’ajoute au fichier de configuration. Aucun raccordement PSP ni transport e-mail n’est présent. Les simulations sont autorisées uniquement avec `mode=demo` et une session qui possède la commande.

## 4. Initialiser la base de test

Toujours dans `repas-test` :

```sh
php bin/install.php --demo
php bin/check.php
```

L’installateur refuse une base qui contient déjà des tables. Il crée les tables InnoDB, trois menus fictifs et les deux comptes indiqués ci-dessus, puis affiche un code club de test et les deux mots de passe personnels. Conserver ces valeurs séparément. Aucun e-mail ne part.

Si l’installation échoue après la création de tables, ne la relancez pas à l’aveugle et ne supprimez aucune base existante. Examiner l’erreur avec votre administrateur et utiliser une autre base dédiée vide si nécessaire. Le compte SQL d’installation doit avoir les droits de création ; le compte d’exécution peut ensuite être restreint à SELECT/INSERT/UPDATE/DELETE sur cette base.

Réinitialisation locale d’un compte, en cas de perte :

```sh
php bin/reset-password.php catering@rugbybwest.be
php bin/reset-password.php events@rugbybwest.be
```

Le script génère un nouveau mot de passe et invalide les sessions administrateur antérieures, sans envoi par e-mail.

## 5. Ouvrir le sous-domaine de test

Créer le sous-domaine de test dans le multisite, par exemple **test-repas.rugbybwest.be**, et activer son certificat HTTPS. Utiliser les valeurs DNS exactes fournies par votre hébergement OVH ; aucune adresse IP n’est inventée dans ce dossier.

Quand le DNS et le certificat sont prêts :

1. Ouvrir l’URL HTTPS. Le navigateur demande l’identifiant `bwest-test` et le mot de passe privé généré par `bin/hash.php`.
2. Tester les menus et une commande fictive avec le code généré par l’installation.
3. Tester `/admin` avec le compte d’Alex puis celui de Céline.
4. Contrôler que l’accès à `/config.php`, `/app/`, `/sql/`, `/bin/` et aux exports sans connexion est refusé.
5. Contrôler les badges et vérifier qu’en mode `preproduction`, aucune nouvelle commande ni simulation ne passe, même par appel direct à l’API.

Le serveur web doit transmettre les paramètres `HTTPS=on` et `REMOTE_ADDR` correctement. Le backend ne se fie pas aux en-têtes `X-Forwarded-For` fournis par un visiteur. La protection contre les abus utilise l’adresse transmise par le serveur. Si OVH met tous les visiteurs derrière une seule IP, vérifier avec son support le paramétrage fiable de l’IP avant ouverture réelle.

## 6. Maintenance et vérifications

Configurer une tâche planifiée OVH, avec l’exécutable PHP adapté à l’offre, pour exécuter `bin/maintenance.php` toutes les cinq minutes si cette fréquence est autorisée par votre plan. Sinon choisir la fréquence minimale disponible. Il expire les commandes en attente et nettoie les tentatives et fichiers de session anciens. Les expirations sont également appliquées à chaque requête et avant toute simulation. **Aucune commande n’est supprimée, aucun message n’est envoyé.**

Sauvegarder la base dédiée et le fichier de configuration dans un emplacement privé. Ne pas mettre de sauvegardes SQL/ZIP ou fichiers de configuration dans `public/`. Les sessions PHP utilisent le dossier privé `var/sessions/` avec verrouillage standard ; vérifier sa persistance entre requêtes et entre les workers de votre compte OVH. Pour une architecture sur plusieurs hébergements indépendants, un stockage de session partagé supplémentaire serait nécessaire.

La fermeture se fait après **23 h 59 min 59 s du lundi précédent**, Europe/Brussels. Les commandes en attente expirent après 15 minutes au maximum, sans dépasser cette clôture. Un paiement simulé expiré ne peut pas valider la commande. Les montants, dates et intitulés déjà enregistrés sont conservés après modification d’un menu.

## Validation déjà faite et restant à faire

- Syntaxe des fichiers PHP et JavaScript vérifiée.
- 23 tests fonctionnels et 10 contrôles HTTP exécutés avec PHP **8.3.32** dans un runtime WebAssembly isolé, et une base SQLite **temporaire utilisée uniquement par les tests**.
- Les tests couvrent droits d’Alex et Céline, code, CSRF, abus, prix, doublons, expiration, sauvegarde des montants, CSV, confirmations et interdiction des paiements réels.
- **MySQL/InnoDB sur OVH non testé à ce stade** : il faudra valider l’import du schéma, les verrous de ligne, les accès concurrents, la connexion PHP-FPM, HTTPS, la protection du dossier privé, les sessions, les sauvegardes et le cron.

Les tests sont livrés : `php tests/test.php` nécessite PDO SQLite et ne se connecte jamais à la base OVH. Si PDO SQLite n’est pas disponible sur le serveur, les lancer sur un poste ou dans un environnement de développement qui le fournit. `php bin/check.php` contrôle la connexion et la structure réelles après installation ; il n’envoie aucun message et ne modifie pas les commandes.

## Étape ultérieure : Axepta et e-mails

Le nom Fortis Axepta est confirmé ; le produit et l’API exacts restent à déterminer à partir du portail/contrat du club. Plus tard, fournir la documentation correspondante et les accès sandbox via un canal de secrets adapté, puis implémenter et tester : création de session hébergée, notification signée, rapprochement montant/devise/référence, déduplication, gestion des notifications tardives et alertes.

L’API `/api/payments/webhook` répond actuellement **503**. Le navigateur ne peut jamais confirmer un paiement réel. Les confirmations simulées sont stockées une seule fois dans l’outbox ; le corps contient les informations demandées, mais il n’existe aucun appel `mail()` ni client SMTP dans ce dossier.

Configurer ultérieurement le fournisseur d’e-mail et SPF/DKIM/DMARC. En test, toutes les confirmations doivent rester dirigées vers **cedric.gilet@rugbybwest.be**. En production, l’adresse d’envoi et de réponse sera **events@rugbybwest.be**. Une activation réelle demandera votre validation explicite, une nouvelle version permettant la production et le remplacement des données fictives.