Files
j.foucher d845edb90f v1.0.11 — /manifest : opt-in multiChannel pour ne plus dédupliquer par version
Bug rapporté après v1.0.10 : client sur license channel=full avec les deux
entries v1.5.4.32 dans le backoffice (Entry #1 tagged firefighter+full,
Entry #2 tagged full), le launcher n'affichait toujours qu'une seule ligne.

Root cause côté serveur, PAS côté client cette fois. Manifest.php faisait
un « group by version + pick most specific » dans filterVersions() —
comportement historique introduit pour ne pas faire crasher les vieux
clients qui déduisaient par ToDictionary(v.Version). Résultat : Entry #2
était filtrée avant même d'atteindre le launcher.

Ce filtrage était nécessaire à l'époque (vieux clients) mais bloque tous
les fixes multi-channels client (v1.0.8-1.0.10) qui avaient rendu le
client capable d'afficher plusieurs entries au même numéro.

Fix : opt-in via query param sur /manifest?multiChannel=1

Server (Manifest.php) :
  • filterVersions() prend un `bool $multiChannel = false`.
  • Si true → skip group-by, retourne toutes les entries visibles.
  • Si false (défaut, vieux clients) → comportement historique préservé.
  • Query param `multiChannel` lu depuis $_GET, transmis à filterVersions.

Client (ManifestService.FetchFromOvhAsync) :
  • Ajoute `?multiChannel=1` inconditionnellement. Un serveur ancien
    ignore silencieusement le param (pas de header d'échec).
  • Combiné avec &channel=X quand la license a un channel.

Rétro-compat :
  • Vieux client (v1.0.9-) + serveur nouveau : n'envoie pas multiChannel=1,
    serveur dédupe comme avant, launcher ne crash pas.
  • Client nouveau (v1.0.11+) + serveur ancien : le param est ignoré,
    même comportement qu'avant (dédup côté serveur, une seule row visible).
  • Client nouveau + serveur nouveau (config voulue) : les deux entries
    remontent, le row-key-par-Id de v1.0.10 fait le reste.

Bump : 1.0.10 → 1.0.11 (fix ciblé serveur+client).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-07-07 17:16:58 +02:00
..

PS_Launcher — Côté serveur

Contenu de ce dossier à uploader sous www/PS_Launcher/ sur le mutualisé OVH.

Arborescence finale après upload

www/
└── PS_Launcher/
    ├── .htaccess
    ├── api/                     ← API consommée par le launcher
    │   ├── config.php           ← À CRÉER (copie de config.example.php)
    │   ├── index.php
    │   ├── lib/{Response,Db,Crypto}.php
    │   └── routes/{Manifest,Releasenotes,ValidateLicense}.php
    ├── admin/                   ← Backoffice web (auth par mot de passe)
    │   ├── .htaccess
    │   ├── index.php            (dashboard)
    │   ├── login.php / logout.php
    │   ├── licenses.php / versions.php / audit.php
    │   ├── lib/{Auth,Layout}.php
    │   └── assets/style.css
    ├── manifest/versions.json
    ├── releasenotes/1.4.X.md
    ├── builds/                  ← ZIPs uploadés en SFTP
    ├── migrations/001_init.sql  ← Schéma MySQL initial
    └── tools/
        ├── generate-keypair.php
        ├── issue-license.php
        └── sign-manifest.php

Setup initial (à faire une fois)

1. Crée la base MySQL

Manager OVH → Hébergements → Bases de données → Créer. Note le DSN, user, password.

2. Joue le schéma

PhpMyAdmin (manager OVH) ou en SSH :

mysql -h <host> -u <user> -p <db> < www/PS_Launcher/migrations/001_init.sql

3. Configure le serveur

  • Copie api/config.example.phpapi/config.php
  • Remplis la section db, base_url
  • Génère les clés Ed25519 :
    cd ~/www/PS_Launcher
    php tools/generate-keypair.php
    
    Recopie private_key_hex et public_key_hex dans api/config.php section ed25519. Recopie aussi public_key_hex dans src/PSLauncher.Core/Resources/server-pubkey.txt côté projet C# et recompile le launcher.

4. Configure le mot de passe admin

php -r "echo password_hash('TonMotDePasseFort', PASSWORD_DEFAULT);"

Recopie le hash dans api/config.phpadmin_password_hash.

5. Test la chaîne

https://tondomaine.com/PS_Launcher/api/health         → JSON status: ok
https://tondomaine.com/PS_Launcher/admin/login.php    → page de connexion admin

Workflow de release (via le backoffice)

  1. Connecte-toi sur https://tondomaine.com/PS_Launcher/admin/.
  2. Onglet Versions → formulaire « Ajouter une version » : numéro, date min de license, release notes Markdown.
  3. Upload le ZIP correspondant via SFTP dans www/PS_Launcher/builds/proserve-{version}.zip.
  4. Bouton 🔁 Sync (sign-manifest) : calcule SHA-256, met à jour latest, signe le manifest avec Ed25519.
  5. Au prochain « Vérifier les MAJ » côté launcher, la nouvelle version apparaît.

Workflow de release (alternative manuelle SSH)

# 1. Édite manifest/versions.json (ou utilise le backoffice)
# 2. Upload le ZIP en SFTP dans builds/
# 3. Resigne :
cd ~/www/PS_Launcher
php tools/sign-manifest.php

Émettre une license

Via le backoffice (recommandé) : onglet Licenses → formulaire « Émettre ». La clé apparaît une seule fois — copie-la pour le client.

Via SSH :

php tools/issue-license.php "ACME Corp" 2027-12-31 1

Convention du contenu du ZIP

Le client extrait le ZIP dans installRoot/Proserve v{version}/. Le ZIP peut soit contenir un dossier racine Proserve v{version}/, soit le contenu directement — le launcher détecte automatiquement le préfixe commun et le strippe.

Test API depuis ton poste

curl.exe https://tondomaine.com/PS_Launcher/api/health
curl.exe https://tondomaine.com/PS_Launcher/api/manifest
curl.exe https://tondomaine.com/PS_Launcher/api/releasenotes/1.4.6

Sécurité

  • api/config.php est gitignored. Ne jamais le commit.
  • Toutes les URLs /api/* forcent HTTPS via .htaccess.
  • Les routes /api/* renvoient toujours du JSON (pas de page Apache 500 HTML).
  • L'admin est protégé par session + CSRF + mot de passe bcrypt.
  • Les licenses sont stockées via UNIQUE en clair (pour la lookup constant-time côté serveur), mais ne sont jamais loguées en clair côté audit.
  • Côté client : la clé license est chiffrée DPAPI scope CurrentUser dans %LocalAppData%.
  • Les réponses serveur (manifest, validation license) sont signées Ed25519 — le launcher embarque la clé publique et refuse toute réponse mal signée.