Paquets d’intégration d’application Launch

Launch 0.1.6 intègre le SDK officiel Licentivo 0.11.6 pour les neuf langages. Installez uniquement le paquet Launch de votre langage. Son implémentation, son adaptateur par défaut, ses mentions de licence et sa configuration de liaison au SDK sont inclus. Les déclarations TypeScript font partie de JavaScript ; le backend Web Go de confiance constitue un exemple supplémentaire. Les sources publiques, les commandes d’installation et la disponibilité par langage sont suivies dans le dépôt du SDK Launch et son état de publication.

La mise à jour 0.1.6 inclut le correctif CMake C/C++ amont pour les utilisateurs des paquets de configuration curl et de FindCURL. Le protocole de licence, les API d’application et le cycle de vie du compte restent inchangés. Les applications existantes peuvent mettre à jour le paquet Launch puis le reconstruire sans modifier leur code d’intégration. Le registre de publication 0.1.6 suit séparément la disponibilité publique, la vérification d’une installation propre et les compilations locales.

Installer depuis un registre public

Les vérifications publiques d’installation de la version 0.1.6 ont réussi pour les neuf langages : Go, Python, C#, Java, Node.js/TypeScript, Rust, Ruby, C et C++. Les commandes de registre et téléchargements natifs ci-dessous sont publics et ont été vérifiés dans des projets consommateurs indépendants. L’état de publication consigne les sommes de contrôle exactes des paquets, les résultats d’installation et les limites des plateformes.

go get github.com/spf86/licentivo-launch-sdk/pkg/launchclient@v0.1.6
python -m pip install licentivo-launch==0.1.6
npm install @licentivo/launch@0.1.6
dotnet add package Licentivo.Launch --version 0.1.6
cargo add licentivo-launch@=0.1.6
gem install licentivo-launch --version 0.1.6

Java utilise les coordonnées Maven/Gradle com.licentivo.launch:launch-client:0.1.6. C/C++ utilisent l’archive native compatible ABI de la version GitHub correspondante. Consultez l’état de publication pour la propagation dans les registres et les résultats de vérification.

Installer une distribution téléchargée

Utilisez les artefacts indiqués dans integration-packages.json. Chaque langage indique sdk_managed: true et requires_separate_official_sdk: false. Vérifiez SHA256SUMS avant l’installation.

python -m pip install ./licentivo_launch-0.1.6-py3-none-any.whl
npm install ./licentivo-launch-0.1.6.tgz
dotnet add YOUR_PROJECT package Licentivo.Launch --version 0.1.6 --source YOUR_LOCAL_FEED
gem install --local ./licentivo-launch-0.1.6-x64-mingw-ucrt.gem

Java utilise uniquement le JAR Launch dans son classpath ; son POM ne dépend pas du SDK officiel. Les utilisateurs Go hors ligne peuvent extraire le ZIP du module et employer un require/replace local pour github.com/spf86/licentivo-launch-sdk. Les utilisateurs Rust hors ligne peuvent extraire la crate ou le ZIP source puis ajouter une dépendance locale de chemin licentivo-launch. Aucun paquet ni checkout du SDK officiel n’est nécessaire.

Pour C/C++, extrayez le ZIP d’installation native, ajoutez son préfixe à CMake et utilisez :

find_package(LicentivoLaunch CONFIG REQUIRED)
add_executable(myapp main.c)
licentivo_launch_link(myapp)
# C++17 target: licentivo_launch_link(myapp CXX)

Launch résout son propre SDK, ses bibliothèques transitives et les DLL Windows incluses. Le fichier build.rs de Rust compile son cœur C intégré et copie les DLL incluses à côté des exécutables Cargo. La gem Ruby de la plateforme inclut son cœur natif privé et ses bibliothèques d’exécution ; la gem source compile automatiquement le cœur.

Les chaînes d’outils et dépendances ordinaires du langage restent nécessaires : pip résout cryptography, NuGet résout BouncyCastle.Cryptography et Cargo résout les crates Rust ordinaires. Les archives natives couvrent Windows amd64 GNU et Linux amd64. Les distributions Windows incluent curl. Les autres systèmes utilisent les sources complètes avec un compilateur C11 et les bibliothèques de développement curl/OpenSSL du système. Le cœur natif Windows du SDK 0.11.6 exige GNU/MinGW.

Initialiser l’application

Sélectionnez le logiciel existant dans Launch. Celui-ci lit automatiquement l’URL actuelle du marchand, le mappage existant entre forfaits et produits ainsi que les clés publiques de signature officielles, puis fournit une fonction de connexion préremplie. Copiez cette fonction dans l’application ; aucune saisie manuelle d’ID interne ni génération de fichier de configuration n’est nécessaire. Le démarrage du serveur utilise toujours le fichier privé config.yaml, qui n’est jamais distribué avec l’application.

Utilisez le point d’entrée du paquet, par exemple launchclient.Connect, Application.connect en Python, Application.Connect en C# ou Application.connect en Node. La fabrique intégrée crée et gère le SDK. Les fabriques personnalisées sont des points d’extension facultatifs pour les tests ou l’intégration, pas des étapes d’installation. Les API exactes figurent dans le README et l’exemple de chaque paquet.

Launch gère la connexion au compte, les identifiants à portée limitée, les tentatives bornées en cas d’attente et la restauration. Le SDK intégré vérifie les signatures et autorise chaque opération protégée. La fermeture normale, la déconnexion et la libération de l’appareil restent distinctes. Les applications Web vérifient les permissions sur un backend de confiance ; le code Node/Electron appartient au processus principal ou serveur.

Les instructions de développement manuel figurent toujours dans manual-integration.md et dans le README de chaque langage. La page d’intégration IA de l’administration génère des instructions en anglais pour le même parcours d’initialisation directe. Elle exclut les mots de passe, les clés de gestion et les identifiants d’exécution de client ou d’appareil, et n’appelle aucun service d’IA. Voir l’intégration avec l’IA.

Construire les distributions en tant que mainteneur

Seuls les mainteneurs qui actualisent le SDK intégré ont besoin des sources amont examinées. Les utilisateurs des paquets peuvent ignorer cette section.

./scripts/prepare-examples.ps1 -Source 'C:\path\to\reviewed-sdk\sdk'
./scripts/build-integration-packages.ps1 -Output artifacts/NEW_DIRECTORY -BuildRustCrate -BuildNative -CurlRoot PATH_TO_CURL -CCompiler PATH_TO_GCC

Indiquez si nécessaire les chemins des outils avec -Python, -DotNet, -JavaHome, -Ruby, -Cargo et -CMake. Le constructeur vérifie le manifeste amont, puis prepare-managed-sdk.mjs intègre les sources et consigne les valeurs SHA-256 source/destination dans sdk/managed-sdk-manifest.json. Les emplacements et imports des modules sont adaptés au besoin ; la vérification cryptographique reste dans l’implémentation examinée. Les licences et mentions MIT accompagnent chaque copie intégrée.

Chaque compilation crée un nouveau répertoire contenant les artefacts par langage, les archives sources, une archive source combinée, un inventaire et les sommes de contrôle. -SourceOnly produit explicitement des artefacts sources ; les cibles ignorées ne constituent pas des versions binaires testées. L’archive combinée conserve les chemins des paquets, exemples, documents et tests sans exiger examples/vendor.

Vérifier les installations et le comportement

scripts/test-managed-installations.ps1 installe la distribution dans de nouveaux projets consommateurs. Il vérifie les neuf cibles sans paquet séparé du SDK officiel, chemin vers ses sources, adaptateur copié ni configuration manuelle de liaison. Il compile et exécute les extraits exacts de connexion directe générés, y compris les données publiques échappées, et indique configuration_files_required: false. Son rapport est distinct de la suite d’exécution.

scripts/test-integration-packages.ps1 exécute les régressions du cycle de vie et des jeux d’essai du vrai SDK signés localement. Fournissez les chemins des outils et une compilation native de test configurée :

./scripts/test-integration-packages.ps1 -Python python -DotNet dotnet -JavaHome $env:JAVA_HOME -Ruby ruby -Cargo cargo -NativeBuildDirectory .cache/launch-native-build

Les compilations depuis les sources du dépôt utilisent les dépendances natives ordinaires du système ; les mainteneurs Windows peuvent définir LICENTIVO_CURL_ROOT. Ce réglage concerne la compilation des sources et ne constitue pas une installation séparée du SDK. Avec plusieurs installations MinGW Rust/C++, -NativeRuntimeDirectories limite les répertoires de DLL C++ aux vérifications natives. L’absence d’un prérequis fait échouer la cible concernée. all_nine_passed exige la réussite des neuf vérifications.

Stockage et validation

Les sessions sont stockées en mémoire par défaut. La mémorisation de la connexion exige un stockage protégé. Les stockages AES-GCM nécessitent une clé de 32 octets obtenue depuis un coffre du système et jamais placée à côté du texte chiffré. Les mots de passe ne sont jamais persistés. Go, Python, C# et C/C++ natifs proposent le DPAPI de l’utilisateur Windows courant ; Java, Node, Rust et Ruby proposent des stockages chiffrés avec des clés gérées par l’appelant.

Les fichiers d’appareil du SDK conservent leur format amont. Le chiffrement des sessions ne chiffre pas tous les fichiers du SDK. Limitez l’accès aux répertoires de cache propres au compte, au produit et à l’environnement, et excluez-les des installateurs, journaux et du contrôle de version. Un changement d’identité ou de configuration ne permet pas de réutiliser le cache d’un autre compte.

Un refus explicite de session ou de droit ne permet aucun repli hors ligne. Seules une panne de transport ou une réponse HTTP 5xx peuvent utiliser une autorisation existante dont la signature a été vérifiée, dans les limites de sa politique signée. La première activation, les postes flottants et les politiques interdisant le mode hors ligne conservent leurs exigences de connexion.

Les rapports locaux ne prouvent jamais un paiement, une émission ou une activation externes réels. Cet environnement a été reporté ; voir acceptance.md. La publication dans les registres et la qualification des versions autres que Windows exigent un travail et des preuves distincts.