DEUX features liées :
1. CHANNELS : chaque license peut être attribuée à un manifest distinct
(« channel »). Permet de servir des versions différentes selon le
client. Le serveur lit ?channel=X et sert manifest/versions-{X}.json
avec fallback transparent sur versions.json. NULL = default.
2. BÊTA : nouveau flag isBeta + betaNotes par version dans le manifest.
Visible uniquement par les licenses avec can_see_betas=1. Affichage
d'une pill orange « BÊTA » sur la row + tooltip avec les notes pour
les testeurs. Les installations locales déjà présentes restent
visibles même si l'accès BÊTA est retiré ensuite (on n'efface pas
le disque du client).
DB :
002_channel_betas.sql ajoute channel + can_see_betas sur licenses.
Idempotent (ALTER TABLE IF NOT EXISTS), zero data migration.
Serveur PHP :
- ValidateLicense.php signe channel + canSeeBetas dans la réponse
(ordre des clés CRITIQUE pour matcher le canonical client).
- Manifest.php : whitelist regex anti-traversal sur ?channel=, fallback
silencieux sur versions.json si channel inconnu (évite leak de la
liste de channels par probing).
- SignManifest.php prend un channel optionnel → l'admin peut signer
chaque manifest indépendamment.
- admin/licenses.php : dropdown channel + checkbox bêta sur create,
bouton détails repliable par-row pour edit.
- admin/versions.php : channel switcher en tête, badge BÊTA sur chaque
row, dialog repliable « Bêta » avec checkbox + notes des testeurs.
Client C# :
- License.Channel + License.CanSeeBetas (dans le canonical signé).
- VersionManifest.IsBeta + BetaNotes.
- ManifestService prend un channelProvider via DI, lu depuis license
cachée à chaque fetch (lazy, pas de circular dep).
- MainViewModel.RebuildList filtre les versions IsBeta si !CanSeeBetas
(mais conserve les installées locales — on ne retire pas l'accès
rétroactivement à ce qui est déjà sur disque).
- VersionRowViewModel : props IsBeta / BetaNotes / BetaTooltip.
- MainWindow.xaml : pill orange à côté du n° version pour le featured
et les rows compactes, tooltip dynamique avec les notes testeurs.
Backward compat signature :
Anciennes licenses cachées (signées sans channel/canSeeBetas) sont
toujours validées via un fallback canonical legacy dans VerifySignature.
Sans ce fallback, le passage à v0.26 invaliderait toutes les caches
hors-ligne et bloquerait les users en mobilité.
Migration côté admin : jouer 002_channel_betas.sql sur la base, déployer
les fichiers PHP, créer manifest/versions-{channel}.json pour les
nouveaux channels (l'admin versions.php propose un input « Créer/utiliser
un nouveau channel »). Les licenses existantes restent en channel=NULL
= default = comportement actuel.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.php→api/config.php - Remplis la section
db,base_url - Génère les clés Ed25519 :
Recopie
cd ~/www/PS_Launcher php tools/generate-keypair.phpprivate_key_hexetpublic_key_hexdansapi/config.phpsectioned25519. Recopie aussipublic_key_hexdanssrc/PSLauncher.Core/Resources/server-pubkey.txtcô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.php → admin_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)
- Connecte-toi sur
https://tondomaine.com/PS_Launcher/admin/. - Onglet Versions → formulaire « Ajouter une version » : numéro, date min de license, release notes Markdown.
- Upload le ZIP correspondant via SFTP dans
www/PS_Launcher/builds/proserve-{version}.zip. - Bouton 🔁 Sync (sign-manifest) : calcule SHA-256, met à jour
latest, signe le manifest avec Ed25519. - 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.phpest 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.