Intégration d’application avec Launch et Licentivo

Ce guide concerne le fournisseur Licentivo. Pour intégrer le système de licences du marchand sans Licentivo, suivez l’API de licences personnalisée et le parcours d’intégration, choisissez custom_http pour le produit et l’environnement, et conservez le SDK d’exécution de ce système.

Ces modifications locales non publiées utilisent l’échange d’identité de compte. Consultez le contrat de responsabilités et de synchronisation des achats pour la migration et la révocation des sessions côté serveur. Ce changement ne publie ni ne met à jour les numéros de version des paquets.

Launch gère les comptes du marchand, commandes, prix, devis de renouvellement et de mise à niveau, remboursements et dates absolues achetées. Licentivo gère les licences, politiques, quotas d’appareils, sessions d’autorisation, permissions signées et décisions à l’exécution. Une connexion Launch réussie ou un achat synchronisé n’autorise jamais l’exécution d’une opération protégée.

Utilisez la page d’intégration de l’administration pour obtenir l’appel de connexion directe et les clés publiques de produit épinglées. Les neuf adaptateurs de langage incluent le SDK officiel. Les clés de gestion du marchand et de paiement restent sur le serveur. Les paramètres publics du produit ne contiennent ni identifiants client, ni ID d’appareil, ni chemins de cache, ni assertions d’identité.

Échange de compte

sequenceDiagram
    participant App as Application
    participant Launch as Launch server
    participant SDK as Official Licentivo SDK
    participant Lic as Licentivo server
    App->>Launch: Account login
    Launch-->>App: Account session
    App->>Launch: POST /software/products/{id}/identity
    Launch-->>App: Short-lived signed identity assertion
    App->>SDK: In-memory identity + connection + environment
    SDK->>Lic: POST /launch/exchange
    Lic-->>SDK: Restricted device credential + signed permission + logout ticket
    App->>SDK: RunFeature around every protected action

L’adaptateur demande POST /api/v1/software/products/{id}/identity avec {"environment":"sandbox"} ou live. L’assertion d’identité renvoyée dure au maximum 120 secondes et est liée à un émetteur enregistré, une audience, une vraie session de connexion, un produit, un environnement et une référence d’achat. Elle ne contient aucun droit de fonctionnalité, quota d’appareils ou politique hors ligne.

Le SDK officiel reçoit ces valeurs en mémoire :

{
  "product_id": "LICENTIVO_PRODUCT_UUID",
  "trusted_keys": {"SIGNING_KEY_ID": "PINNED_PUBLIC_KEY"},
  "launch_connection_id": "LICENTIVO_LAUNCH_CONNECTION_UUID",
  "environment": "sandbox",
  "identity_token": "SHORT_LIVED_ASSERTION_FROM_LAUNCH",
  "license_key": ""
}

N’écrivez pas cette configuration d’exécution dans un fichier public et ne persistez pas son assertion dans un enregistrement de compte. Les enregistrements mémorisés Launch v2 conservent uniquement la session du compte et le contexte public de routage. L’ancien point d’accès client /credential renvoie HTTP 410.

Cycle de vie et stockage

• Login : authentifier le compte, demander une nouvelle assertion, démarrer le SDK officiel.
• Restore : confirmer en ligne le compte mémorisé, demander une nouvelle assertion, démarrer le SDK officiel. Une panne de Launch ne choisit pas l’autorisation hors ligne.
• RunFeature : déléguer chaque exécution protégée au SDK officiel. Un rappel refusé ne doit jamais s’exécuter.
• Close / Dispose / Drop : arrêter le travail en arrière-plan, conserver la connexion volontairement mémorisée et le lien à l’appareil.
• Logout : appeler la déconnexion unifiée du SDK officiel, puis effacer l’enregistrement de compte Launch et terminer sa session de compte.
• ReleaseDevice : alias de compatibilité pour la déconnexion explicite. Signaler fidèlement toute révocation distante en attente.

Seul le SDK officiel supprime ses fichiers d’identifiants d’appareil et de bail. Ne supprimez jamais son répertoire de cache ni .logout.json : ce journal conserve les tickets de libération à portée limitée nécessaires après des requêtes réseau échouées. Le SDK reprend les tickets en attente lors de la prochaine initialisation du cache correspondant. Le stockage de compte de Launch et celui du SDK relèvent de responsables distincts.

Les applications nécessitant un démarrage hors ligne utilisent le parcours de récupération documenté du SDK officiel. Seul le SDK vérifie l’autorisation signée, le contexte du produit et de l’environnement, l’expiration, le comportement de l’horloge et l’état de l’appareil. Les adaptateurs Launch ne déduisent aucune permission des dates achetées, d’une commande locale ou de la présence d’un fichier.

Les sessions de compte résident uniquement en mémoire par défaut. Les stockages persistants doivent chiffrer et authentifier leurs enregistrements et protéger leurs clés avec les mécanismes d’identifiants du système d’exploitation. Utilisez un cache distinct accessible en écriture pour chaque marchand, compte, produit et environnement. Les moteurs de rendu du navigateur doivent recevoir les résultats métier, sans jetons de compte de bureau, assertions ou identifiants d’appareil.

Achats et appareils

Launch calcule les dates absolues achetées à partir des paiements vérifiés et de la couverture immuable des commandes, puis transmet des instantanés versionnés à /api/v1/launch/connections/{id}/events. Il interroge l’événement jusqu’à l’état applied ; un simple accusé de réception ne constitue pas la livraison. Réessayer un renouvellement ou un remboursement ne peut ajouter une seconde fois la durée. Les remboursements retirent uniquement la couverture de la commande concernée ; lors d’un nouvel achat après remboursement intégral, une nouvelle référence remplace l’achat remboursé.

Les utilisateurs privés d’accès à un appareil peuvent ouvrir la page de gestion des appareils de Launch. Les listes, libérations restantes, actions autorisées et résultats d’opération proviennent de Licentivo. Une libération transmet la génération de liaison affichée et conserve le même ID d’opération. Launch ne maintient aucun compteur de libération ni exécuteur de tâches concurrent.

Vérifications et limites

Testez l’échange de compte, le stockage éphémère des assertions, l’exécution des fonctionnalités contrôlée par le SDK, la fermeture ordinaire, la déconnexion explicite dans un nouveau processus, les journaux de libération en attente et l’isolation produit/environnement. Testez les véritables baux signés du SDK officiel, les vérifications hors ligne et le rejet des altérations séparément du transport de compte Launch. La compilation et les jeux d’essai ne prouvent pas la validation en production.

Launch utilise également les points d’accès POST session-revocations et GET d’accusé de réception de Licentivo V39 pour la déconnexion de bureau, la déconnexion forcée d’une session, les changements de mot de passe et la désactivation d’un compte. Il fige durablement les destinataires et la requête d’origine, récupère les réponses perdues et confirme chaque environnement indépendamment. Les notifications globales de compte en attente suspendent les nouvelles authentifications de bureau ; après confirmation, une connexion réellement nouvelle doit avoir un auth_time strictement postérieur à la dernière seconde revoked_before. La récupération par le site reste disponible. Ces notifications ne modifient jamais les dates achetées. Voir le contrat de responsabilités et de récupération.

Voir l’intégration manuelle, l’intégration avec l’IA, les paquets d’intégration et la validation.