Files
PS_Launcher/server
j.foucher 500f7d12e6 v0.29.10 — Admin UI refonte (modals + onglets), emails de release, 4-digit versions
Admin backoffice — UI redesign :
 - Pages versions.php + licenses.php : remplace les <details> inline qui
   débordaient horizontalement par UN bouton « ✎ Modifier » par row qui
   ouvre une modal <dialog> avec onglets. 5 tabs versions (Méta, Notes,
   BÊTA, Channels, Avancé) + 6 tabs licenses (Prolonger, Slots, Channel,
   BÊTA, Lock, Contacts, Machines). Délégation JS unique pour les onglets.
 - Bouton 📋 Copier la clé license dans chaque row (Clipboard API + feedback
   visuel ✓ vert 1.5s). Évite le détour par phpMyAdmin pour transmettre la
   clé aux clients.
 - Overlay « hashing en cours » plein écran sur tous les boutons de hash
   (3-5 min sur OVH pour 13 Go ZIP). Spinner CSS + message contextualisé
   par scope (bulk vs single).
 - Date de release passée de datetime-local à date (l'heure n'a pas de
   sens UX), avec défaut = aujourd'hui pour release_at et aujourd'hui-1an
   pour min_license_date (= license standard couvre les releases sur 1 an).

Emails de notification release :
 - Migration 004 : colonne contact_emails TEXT NULL sur licenses (CSV)
 - Onglet « Contacts » sur la modal licenses pour saisir les emails par
   license (parsing tolérant : CSV, ligne par ligne, point-virgule)
 - Bouton « ✉ Notifier » par version : POST notify_release filtre les
   licenses éligibles (channel match + min_license_date + can_see_betas
   pour BÊTA) et envoie un email HTML à chaque contact (dédup global)
 - Template email table-based + bgcolor (compat Outlook/Word engine),
   navy foncé #0F172A, logo Asterion en CID embed (= affichage direct
   sans demande de permission Outlook), bouton download installer
   centré (align="center" + margin auto), release notes en <pre>
 - Mailer.php helper : parse emails, multipart/related avec attachments
   inline, fallback execCommand pour clipboard

4-digit version support (X.Y.Z.B) :
 - SemVer Parse/CompareTo/ToString gèrent 3 ou 4 digits ; Build absent =
   0 implicite (1.5.4 == 1.5.4.0 < 1.5.4.13). HasExplicitBuild préserve
   le format d'origine au round-trip.
 - Regex InstallationRegistry étendue avec (?:\.\d+)? → reconnaît
   « PROSERVE v1.5.4.13 » côte-à-côte avec « PROSERVE v1.5.4 » sur disque
 - Server-side : versions.php, launcher.php, DownloadUrl.php, api/index.php,
   Releasenotes.php — toutes les regex de validation acceptent le 4ᵉ digit
 - Use case : dev/test iterations cohabitant avec leur release stable

Bugs fixes :
 - migrate.php : strip ligne par ligne les commentaires SQL avant le
   check is-empty. Sans ça, le PREMIER chunk d'un fichier migration
   (= header + premier ALTER) commençait par `--` et était silencieusement
   skip → ALTER jamais appliqué. Affectait migrations 003, 004.
 - SignManifest::getOrComputeSha256 ignorait son cache interne quand force
   demandé par le caller, retournant l'ancien hash en 0 ms même après
   re-upload SFTP (avec mtime préservé). Propage maintenant le flag $force.
   Bouton « 🔁 Hash » per-row force maintenant un re-calcul systématique.
 - DownloadManager : 416 (Range Not Satisfiable) ajouté aux URL-refresh
   triggers, avec HEAD probe pour comparer taille serveur vs manifest →
   message d'erreur explicite si ZIP tronqué. Bps display lissé sur une
   fenêtre glissante de 12 samples (3 s) → plus de clignotement quand un
   segment finit / Polly retry. SHA mismatch popup enrichi avec les
   deux SHAs (attendu vs calculé) extraits via regex de l'exception.
 - DownloadUrl.php : signature de l'URL utilisait un template hardcodé
   /builds/proserve-{version}.zip, ignorant tout rename serveur. Lit
   maintenant download.url du manifest et signe le filename réel.

Strings i18n (5 langues) :
 - ~15 nouveaux : SHA mismatch enrichi avec sources, 416 size mismatch,
   stale manifest, manifest refreshed auto-retry, force fresh menu

Bumps : 0.29.7 → 0.29.10 (4-digit support + accumulated UI fixes).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-28 17:24:50 +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.