Guide d’intégration manuelle (langues 9, pas d’IA nécessaire)

Ce guide est destiné aux fournisseurs Licentivo. Les marchands avec d’autres systèmes d’autorisation existants peuvent choisir un service personnalisé dans le backend sous 'Sélection et personnalisation de l’autorisation', s’intégrer selon Custom Authorization API and Integration Process , et continuer à utiliser leur propre SDK de système d’autorisation.

Les modifications non publiées adoptent actuellement l'échange d'identité de compte. Les responsabilités spécifiques et les contraintes de migration sont détaillées dans Achat Term et Limites SDK de compte . Launch calcule le terme d'achat ; Licentivo SDK exécute l'autorisation.

Installe uniquement le package d'intégration Launch pour la langue correspondante. Le package Launch inclut en interne le SDK officiel, l'adaptateur par défaut et la configuration du lien ; l'adresse d'autorisation officielle est fixée à https://www.licentivo.com. Le programme se connecte en utilisant le compte enregistré par l'acheteur dans le magasin Launch actuel.

Obtenir le code d'initialisation complet

1. Compléter l'association des logiciels, des packages de vente et des stratégies d'autorisation Licentivo dans le backend Launch, et le publier dans l'environnement correspondant.
2. Ouvrez Accès au programme → Vérification d'accès et code, et sélectionnez le logiciel, la langue et l'environnement test/production.
3. Cliquez sur 'Lire les informations produit et générer le code d'accès'. Launch lit automatiquement l'adresse publique actuelle du site, les mappages de produits existants et la clé publique de signature.
4. Copiez la fonction de lien sur la page dans votre propre projet et écrivez manuellement l'interface et les appels métier comme décrit ci-dessous. Vous pouvez également consulter les paramètres remplis automatiquement et appeler directement la version linguistique correspondante de Connect/connect.

Il n'est pas nécessaire de remplir manuellement les deux identifiants de produit internes, et il n'est pas nécessaire de générer launch-config.json ou product.json. La page peut enregistrer la fonction de lien du code source. Le config.yaml privé du serveur est uniquement destiné au démarrage du service Launch et ne peut pas être publié avec le logiciel client.

L'adresse du site provient de l'adresse publique valide de l'instance actuelle (configuration de démarrage public_url, ou adresse publique valide dans les paramètres du site backend). Cela peut être un nom de domaine ou une adresse IP avec un port, mais il doit inclure un protocole ; l'accès en production utilise un HTTPS valide. L'adresse d'écoute http_addr n'est pas une adresse d'accès client. Après avoir changé l'adresse du site, la cartographie du produit ou l'environnement, récupérez de nouveau la fonction de lien depuis le site actuel ; les sessions et caches du site précédent ne peuvent pas être utilisés pour l'autorisation du nouveau site.

Les deux numéros de produit sont des correspondances internes existantes : produit logiciel Launch et produit d'autorisation Licentivo. La page d'accès les remplit automatiquement selon le logiciel sélectionné ; l'acheteur ne saisit que le compte du magasin. La clé publique de signature est lue par le serveur en utilisant le Licentivo configuré, et la clé de gestion ainsi que les informations d'autorisation client n'entrent pas dans le code source.

La fonction de Connect/connect

Connect/connect est le nom utilisé dans différentes langues pour l’opération « créer un client d’application Launch ». Go, C# et certaines interfaces natives utilisent Connect en majuscules, tandis que Python, JavaScript, Ruby et d’autres langages utilisent connect selon leurs propres styles. Les connectLaunch(), connect_launch() ou LaunchConnection.Open() générés par le backend sont des fonctions de projet avec des paramètres publics pré-remplis et appellent en interne les points d’entrée correspondants dans chaque langage.

La connexion ne fait que compléter l’initialisation : elle vérifie l’adresse du magasin, le mappage des produits, l’environnement et la clé publique de signature, crée un client Launch et configure le SDK Licentivo officiel à l’intérieur du package. Elle ne vérifie pas l’identité du client ni n’active directement les fonctionnalités payantes. La séquence complète est :

Connect/connect → Login or Restore → RunFeature → Logout / Close
                                       └──────────→ ReleaseDevice (explicit device unlink only)

Pendant l'exécution de l'application, vous devriez garder le même objet client afin que le SDK puisse gérer correctement les « heartbeats » et les sièges flottants. La fermeture normale conserve l'association de l'appareil ; lorsque le client quitte explicitement, appeler l'entrée compatible avec ReleaseDevice utilise le même flux de sortie officiel du SDK.

Entrée pour l'installation et l'initialisation

La vérification de l'installation de la version 0.1.6 pour neuf langues a toutes été réussies (9/9). Les méthodes d'installation dans le tableau ci-dessous ont toutes été vérifiées. GitHub Release fournit également des packages natifs et des fichiers hors ligne ; instructions d'utilisation voir instructions d'installation du package à télécharger .

Les fichiers de code source et README pour chaque langage sont disponibles sur dépôt SDK Launch, les packages natifs et fichiers hors ligne peuvent être trouvés sur v0.1.6 Release, et les résultats d'installation publics sont sur vérification du registre en neuf langues. Le README propre à chaque package fournit les commandes d'installation et les API. Le package JavaScript inclut les déclarations TypeScript. Les dépendances pour les langages normaux sont résolues par le gestionnaire de packages, telles que la cryptographie de Python, BouncyCastle pour C#, et la base de Ruby64 ; il n’est pas nécessaire d’installer le package SDK officiel.

Le module Go public s'appelle github.com/spf86/licentivo-launch-sdk, avec le chemin d'importation github.com/spf86/licentivo-launch-sdk/pkg/launchclient, et l'application n'a pas besoin d'un remplacement local. Le package natif Windows utilise amd64 GNU/MinGW, et il existe également un package natif Linux amd64. Le package plateforme Ruby et la distribution Rust/native Windows incluent curl ; la compilation à partir du code source sur d'autres plateformes nécessite les dépendances de développement standard C11 et curl/OpenSSL. Les détails de la chaîne d'outils se trouvent dans le README de chaque package.

Connexion et opérations protégées

Les extraits suivants utilisent la fonction connect copiée à l'étape précédente. email et password proviennent de votre propre interface de connexion ; ne codez pas de mots de passe dans le code source ou la configuration. export doit être remplacé par un nom de fonctionnalité qui existe réellement dans le plan du package.

Go

app, err := connectLaunch()
if err != nil { return err }
defer app.Close()
if _, err := app.Login(ctx, email, password); err != nil { return err }
return app.RunFeature("export", func() error {
    return exportReport()
})

ctx utilise le contexte du cycle de vie de l'application, et vous ne devriez pas annuler les signaux de vie immédiatement après une requête de connexion. Les opérations réseau s'exécutent sur un thread de travail en arrière-plan. Utilisez Restore(ctx) pour les appels de récupération ; Logout(ctx) pour la déconnexion ; ReleaseDevice(ctx) pour libérer les appareils.

Python

with connect_launch() as app:
    app.login(email, password)
    result = app.run_feature("export", export_report)

restore() restaure les sessions sécurisées existantes ; s'il n'y en a pas, il affiche l'interface de connexion. logout() nettoie les comptes ; release_device() libère explicitement les appareils. Ne laissez pas les opérations réseau synchrones bloquer la boucle d'événements du bureau.

C# / .NET

await using var app = LaunchConnection.Open();
await app.Login(email, password);
await app.RunFeature("export", async () => {
    await ExportReport();
});

Utilisez await Restore(), await Logout() et await ReleaseDevice(). Gardez le cycle de vie du SDK actif tant que l'application fonctionne et utilisez des flux d'interface asynchrones.

Java

try (var app = LaunchConnection.open()) {
    app.login(email, passwordChars);
    app.runFeature("export", () -> exportReport());
}

Le mot de passe utilise char[]. restore() renvoie NO_SESSION en cas d’échec lorsqu’il n’y a pas de session, et l’écran de connexion devrait s’afficher ; les autres échecs ne peuvent pas être considérés comme une autorisation. logout() et releaseDevice() sont des opérations différentes. try-with-resources s’occupe de la fermeture.

JavaScript / Node.js / TypeScript

const app = connectLaunch();
try {
  await app.login(email, password);
  const result = await app.runFeature('export', () => exportReport());
} finally {
  await app.close();
}

restore() renvoie null lorsqu’il n’y a pas de session ; les opérations métier ne sont autorisées qu’après une récupération normale. La valeur booléenne renvoyée par logout() indique si la déconnexion distante est confirmée, et un échec de libération de l’appareil doit afficher une erreur. Le code s’exécute sur Node.js, le processus principal d’Electron, ou un backend de confiance ; le navigateur et le processus de rendu d’Electron ne sauvegardent pas les identifiants d’autorisation.

Rust

let mut app = connect_launch()?;
app.login(&email, &password)?;
let result = app.run_feature("export", || {
    export_report()?;
    Ok(())
})?;
app.close();

Le rappel renvoie Result<T, Failure>. restore(), logout() et release_device() renvoient des résultats et des échecs qui doivent être gérés. Drop s'occupe également de fermer le runtime. Par défaut, le cœur natif est compilé et lié par build.rs, donc vous n'avez pas besoin de lier le SDK officiel vous-même.

Ruby

app = connect_launch
begin
  app.login(email, password)
  result = app.run_feature('export') { export_report }
ensure
  app.close
end

restore restaure la session, logout se déconnecte, release_device libère l'appareil. Protégez les opérations avec un bloc de code ; les exceptions ne peuvent pas être converties en succès.

C

static int export_action(void *context) {
    return export_report(context); /* Return 1 only on success. */
}

launch_application *app = connect_launch();
if (!app) return 0;
int ok = launch_application_login(app, email, password);
if (ok) ok = launch_application_run_feature(app, "export", export_action, context);
/* Check launch_application_error(app) on failure; never log credentials. */
launch_application_close(app);
return ok;

launch_application_restore a trois états : 1 restauré, 0 pas de session, -1 échec. Il ne faut afficher la connexion normalement que lorsqu'il n'y a pas de session ; refus ou exceptions ne peuvent pas être comptés comme succès. Les valeurs de retour de logout et release_device doivent aussi être vérifiées.

CMake importe seulement Launch:

find_package(LicentivoLaunch CONFIG REQUIRED)
add_executable(myapp main.c)
licentivo_launch_link(myapp)

C++

auto app = connectLaunch();
app.Login(email.c_str(), password.c_str());
app.RunFeature("export", [&] { exportReport(); });

Restore(), Logout(), ReleaseDevice() suivent la sémantique des exceptions en C++. Les destructeurs RAII s’occupent de la fermeture. CMake utilise licentivo_launch_link(myapp CXX), Launch gère automatiquement le lien avec le SDK et les bibliothèques d’exécution dans le paquet de distribution.

Cycle de vie, stockage sécurisé et erreurs

La création d’un objet de connexion ne fait qu’achever l’initialisation. Le programme doit être connecté ou restauré avec succès et utiliser des callbacks protégés pour chaque opération commerciale. Les commandes payées, les sessions existantes ou les boutons cliquables ne peuvent pas remplacer la vérification du SDK.

Par défaut, les sessions ne sont stockées qu'en mémoire. Se souvenir d'une connexion nécessite un stockage sécurisé : Go, Python, C#, et C/C++ natif fournissent DPAPI pour l'utilisateur actuel Windows ; Java, Node, Rust, et Ruby offrent un stockage AES-GCM en utilisant la clé de l'appelant. Les applis Cross-platform devraient se connecter au magasin d'identifiants du système. Ne mettez pas la clé et le texte chiffré dans le même répertoire classique.

L'arrêt régulier garde les sessions activement mémorisées par l'utilisateur et arrête l'exécution. Lors de la déconnexion, appelez d'abord le SDK officiel pour une déconnexion unifiée, puis effacez les propres enregistrements de compte de Launch. ReleaseDevice est une entrée compatible dans le même processus ; n'indiquez pas une libération réussie si la révocation à distance est en attente. Ne nettoyez pas le répertoire cache du SDK officiel ni ne quittez les journaux de récupération. La protection de session dans Launch ne signifie pas que tous les fichiers de l'appareil du SDK officiel sont chiffrés, donc les permissions du répertoire cache doivent être limitées.

401/403/404 explicite, incompatibilité de compte, annulation ou limitation de débit ne peuvent pas devenir une autorisation hors ligne réussie. Les politiques pour la première activation et les restrictions hors ligne nécessitent encore une connexion réseau. Lorsque le domaine/IP du serveur est inaccessible, affichez les problèmes de connexion ; ne vous connectez pas secrètement à d'autres sites.

Acceptation et référence

Vérifiez la connexion réelle, l'autorisation du compte, les opérations protégées, la récupération après redémarrage, la validité hors ligne et l'expiration hors ligne, la falsification du cache, la déconnexion, le changement de compte et la libération de l'appareil. Cet article ne nécessite pas l'utilisation de l'IA. Les outils de test et les limites d'acceptation externes se trouvent dans acceptance.md ; les packages locaux et les instructions de construction se trouvent dans integration-packages.md.

Les vérifications de configuration, la génération de code et les tests locaux ne prouvent pas automatiquement un paiement réel, l'émission d'une autorisation ou le succès de l'activation sur le site officiel. Les magasins externes et les environnements de test de paiement doivent être configurés et acceptés séparément.