Aller au contenu

Schémas

Diagramme de séquence — Activation & gestion de licence

Ce déroulé suppose qu'un éditeur a déjà été provisionné par l'opérateur de la plateforme (POST /platform/publishers) et possède ses propres X-Client-Token / X-Admin-Token. "Utilisateur" ci-dessous est l'utilisateur final de l'éditeur, pas un client direct de cette API — voir Overview.

Déroulé pas à pas :
1. Activation – l'utilisateur final lance l'app de l'éditeur et saisit sa clé. L'app appelle POST /activate (avec le X-Client-Token de l'éditeur) et email, license_key, device_hash, device_name. L'API limite le débit par (éditeur, email), vérifie la propriété, l'état enabled et le quota d'appareils, puis renvoie un jeton signé (avec un kid) que l'app conserve pour déverrouiller les fonctions Pro.
2. (Optionnel) Vérification – l'app récupère les clés de signature via GET /public-keys, choisit celle dont le kid correspond au jeton, et vérifie la signature (Ed25519) — entièrement hors-ligne.
3. Gestion admin – un administrateur de l'éditeur peut créer/lister des licences et (dés)activer une licence (effet immédiat), scopé à son propre compte éditeur.
4. Changement d’appareil – quand l'utilisateur final migre de machine, l'app appelle POST /deactivate pour libérer un slot et réactiver ailleurs.

%%{init: { "theme": "base", "sequence": { "showSequenceNumbers": true, "useMaxWidth": true }, "themeVariables": { "darkMode": true, "background": "transparent", "fontSize": "18px", "primaryTextColor": "#e7ebf2", "actorTextColor": "#e7ebf2", "noteTextColor": "#dfe4ec", "lineColor": "#8fb4ff", "signalColor": "#8fb4ff", "actorBorder": "#8fb4ff", "actorBkg": "#1b2330", "activationBorderColor":"#8fb4ff", "activationBkgColor": "#242e3d", "noteBkgColor": "#242e3d" } }}%% sequenceDiagram autonumber actor Utilisateur as Utilisateur final (client de l'éditeur) participant App as App de l'éditeur participant API as Licenses API participant Admin as Admin de l'éditeur participant Key as Clés de signature (GET /public-keys) Utilisateur->>App: Ouvre l’app / saisit la clé licence App->>API: POST /activate\n{ email, license_key,\n device_hash, device_name }\n(X-Client-Token: celui de cet éditeur) API-->>API: Rate-limit (éditeur, email)\nValidation de la licence (statut, email, quota d’appareils) API-->>App: 200 { jeton signé + kid + métadonnées } Note over App: L’app conserve le jeton signé\net déverrouille les fonctions Pro rect rgb(27,35,48) App->>Key: GET /public-keys (cache par kid) App-->>App: Vérifie la signature (Ed25519) end Admin->>API: Activer/Désactiver, lister, créer des licences\n(X-Admin-Token: celui de cet éditeur) API-->>Admin: Détails de licence + appareils actifs Utilisateur->>App: Change de machine App->>API: POST /deactivate\n{ license_key_hash, device_hash } API-->>App: Slot libéré (réactivation ailleurs)

Diagramme Entité–Relation

  • PUBLISHERS : une ligne par tenant (studio de jeu, SaaS, éditeur de logiciel) — détient le hash de client_token/admin_token et un interrupteur enabled. Tout le reste est scopé à un éditeur.
  • USERS : une ligne par (éditeur, email) — le même email peut exister indépendamment sous deux éditeurs différents.
  • LICENSES : appartient à un éditeur et à un utilisateur ; contient license_key_hash, product, edition, enabled, max_activations, features_json (optionnel), dates.
  • ACTIVATIONS : chaque enregistrement lie une licence à un appareil (device_hash, device_name), avec un indicateur deactivated et une date.
  • Tables de support non représentées ci-dessous : SIGNING_KEYS (clés Ed25519 rotatives, partagées par la plateforme), RATE_LIMIT_HITS (limitation par éditeur+email sur /activate), AUDIT_LOG (journal append-only des actions admin/plateforme).

Relations - Un PUBLISHER possède plusieurs USERS et plusieurs LICENSES. - Un USER possède plusieurs LICENSES. - Une LICENSE possède plusieurs ACTIVATIONS (appareils).

erDiagram PUBLISHERS ||--o{ USERS : scopes PUBLISHERS ||--o{ LICENSES : scopes USERS ||--o{ LICENSES : owns LICENSES ||--o{ ACTIVATIONS : has