Pacchetti di integrazione delle applicazioni Launch

Launch 0.1.6 include l'SDK ufficiale Licentivo 0.11.6 per tutti i nove linguaggi. Installare soltanto il pacchetto Launch del proprio linguaggio. Sono inclusi l'implementazione, l'adattatore predefinito, gli avvisi di licenza e la configurazione di collegamento dell'SDK. Le dichiarazioni TypeScript appartengono a JavaScript; il backend Web attendibile in Go è un esempio aggiuntivo. I sorgenti pubblici, i comandi dei registri e la disponibilità per ciascun linguaggio sono mantenuti nel repository degli SDK Launch e nel relativo stato di pubblicazione.

L'aggiornamento 0.1.6 include la correzione CMake C/C++ a monte per chi usa curl config-package e FindCURL. Il protocollo di licenza, le API applicative e il ciclo di vita degli account rimangono invariati. Le applicazioni esistenti possono aggiornare il pacchetto Launch e ricompilare senza modificare il codice di integrazione. Il registro di pubblicazione della versione 0.1.6 documenta la disponibilità pubblica e la verifica delle installazioni pulite separatamente dalle compilazioni locali.

Installare da un registro pubblico

Le verifiche delle installazioni pubbliche della versione 0.1.6 sono state superate per tutti i nove linguaggi: Go, Python, C#, Java, Node.js/TypeScript, Rust, Ruby, C e C++. I comandi dei registri e i download nativi riportati di seguito sono disponibili pubblicamente e verificati in progetti utilizzatori indipendenti. Lo stato di pubblicazione registra i checksum esatti dei pacchetti, i risultati delle installazioni e i limiti delle piattaforme.

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 usa le coordinate Maven/Gradle com.licentivo.launch:launch-client:0.1.6. C/C++ usano l'archivio nativo compatibile con l'ABI della release GitHub con versione. Consultare lo stato di pubblicazione per la propagazione nei registri e i risultati delle verifiche.

Installare una distribuzione scaricata

Usare gli artefatti identificati in integration-packages.json. Ogni linguaggio riporta sdk_managed: true e requires_separate_official_sdk: false. Verificare SHA256SUMS prima dell'installazione.

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 usa soltanto il JAR Launch nel proprio classpath; il suo POM non contiene dipendenze dall'SDK ufficiale. Chi usa Go offline può estrarre lo ZIP del modulo e usare un require/replace locale per github.com/spf86/licentivo-launch-sdk. Chi usa Rust offline può estrarre il crate o lo ZIP dei sorgenti e aggiungere una dipendenza di percorso locale licentivo-launch. Non occorre alcun pacchetto o checkout dell'SDK ufficiale.

Per C/C++, estrarre lo ZIP di installazione nativo, aggiungerne il prefisso a CMake e usare:

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

Launch risolve il proprio SDK, le librerie transitive e le DLL Windows incluse. Il build.rs di Rust compila il nucleo C incorporato e copia le DLL incluse accanto agli eseguibili Cargo. La gem Ruby specifica della piattaforma include il proprio nucleo nativo privato e le librerie runtime; la gem dei sorgenti compila automaticamente il nucleo.

Continuano a essere necessarie le normali toolchain dei linguaggi e le dipendenze ordinarie: pip risolve cryptography, NuGet risolve BouncyCastle.Cryptography e Cargo risolve i normali crate Rust. Gli archivi nativi coprono Windows amd64 GNU e Linux amd64. Le distribuzioni Windows includono curl. Gli altri sistemi operativi usano i sorgenti completi con un compilatore C11 e le normali librerie di sviluppo curl/OpenSSL del sistema operativo. Il nucleo nativo Windows dell'SDK 0.11.6 richiede GNU/MinGW.

Inizializzare l'applicazione

Selezionare il software esistente in Launch. Legge automaticamente l'URL corrente del commerciante, la mappatura esistente tra piani e prodotti e le chiavi pubbliche di firma ufficiali, quindi fornisce una funzione di connessione precompilata. Copiare questa funzione nell'applicazione; non occorre inserire manualmente ID interni né generare file di configurazione. L'avvio del server continua a usare il file privato config.yaml, che non viene mai distribuito con l'applicazione.

Usare il punto di ingresso del pacchetto, ad esempio launchclient.Connect, Application.connect in Python, Application.Connect in C# o Application.connect in Node. La factory inclusa crea e gestisce l'SDK. Le factory personalizzate sono hook facoltativi di test/integrazione, non passaggi di installazione. Le API esatte si trovano nel README e nell'esempio di ciascun pacchetto.

Launch gestisce l'accesso agli account, le credenziali con ambito limitato, i tentativi limitati per gli stati in sospeso e il ripristino. L'SDK incorporato verifica le firme e autorizza ogni operazione protetta. Chiusura ordinaria, disconnessione e rilascio del dispositivo rimangono operazioni distinte. Le applicazioni Web verificano i permessi in un backend attendibile; il codice Node/Electron deve trovarsi nel processo principale o sul server.

Le istruzioni per lo sviluppo manuale rimangono in manual-integration.md e nei README di tutti i linguaggi. La pagina amministrativa di integrazione con IA genera istruzioni in inglese per la stessa procedura di inizializzazione diretta. Esclude password, chiavi amministrative e credenziali di esecuzione dei clienti/dispositivi e non chiama servizi di IA. Consultare Integrazione con IA.

Compilare le distribuzioni come manutentore

Soltanto i manutentori che aggiornano l'SDK incorporato hanno bisogno dei sorgenti a monte revisionati. Chi utilizza i pacchetti può saltare questa sezione.

./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

Fornire i percorsi degli strumenti con -Python, -DotNet, -JavaHome, -Ruby, -Cargo e -CMake secondo necessità. Il generatore verifica il manifest a monte, quindi prepare-managed-sdk.mjs incorpora i sorgenti e registra i valori SHA-256 di origine/destinazione in sdk/managed-sdk-manifest.json. Le posizioni dei moduli e le importazioni cambiano dove necessario; la verifica crittografica rimane nell'implementazione revisionata. Ogni copia incorporata include le licenze MIT e gli avvisi.

Ogni compilazione crea una nuova directory con artefatti per linguaggio, archivi dei sorgenti, un bundle combinato dei sorgenti, inventario e checksum. -SourceOnly produce esplicitamente artefatti sorgente; le destinazioni saltate non sono release binarie testate. Il bundle combinato conserva i percorsi di pacchetti, esempi, documentazione e test senza richiedere examples/vendor.

Verificare installazioni e comportamento

scripts/test-managed-installations.ps1 installa la distribuzione in nuovi progetti utilizzatori. Verifica tutte e nove le destinazioni senza un pacchetto separato dell'SDK ufficiale, un percorso dei sorgenti SDK, un adattatore copiato o una configurazione manuale del collegamento SDK. Compila ed esegue gli esatti frammenti generati per la connessione diretta, inclusi i dati pubblici con escape, e riporta configuration_files_required: false. Il suo report è separato dalla suite di esecuzione.

scripts/test-integration-packages.ps1 esegue i test di regressione del ciclo di vita e le fixture firmate localmente che usano l'SDK reale. Fornire i percorsi degli strumenti e una compilazione di test nativa configurata:

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

Le compilazioni dai sorgenti del repository usano le normali dipendenze native del sistema operativo; i manutentori Windows possono fornire LICENTIVO_CURL_ROOT. È un'impostazione degli strumenti di compilazione dai sorgenti, non un'installazione separata dell'SDK. Con installazioni MinGW diverse per Rust/C++, -NativeRuntimeDirectories limita le directory delle DLL C++ ai controlli nativi. I prerequisiti mancanti fanno fallire la destinazione interessata. all_nine_passed richiede che tutti e nove i controlli siano superati.

Archiviazione e collaudo

Le sessioni vengono conservate in memoria per impostazione predefinita. Per ricordare l'accesso occorre un archivio protetto. Gli archivi AES-GCM richiedono una chiave di 32 byte ottenuta da un archivio sicuro del sistema operativo e mai salvata accanto al testo cifrato. Le password non vengono mai conservate in modo persistente. Go, Python, C# e C/C++ nativi offrono DPAPI per l'utente Windows corrente; Java, Node, Rust e Ruby offrono archivi cifrati con chiavi gestite dal chiamante.

I file dei dispositivi dell'SDK mantengono il formato a monte. La cifratura delle sessioni non cifra tutti i file dell'SDK. Limitare l'accesso alle directory della cache separate per account/prodotto/ambiente ed escluderle da programmi di installazione, log e controllo di versione. Le modifiche all'identità/alla configurazione non possono riutilizzare la cache di un altro account.

Un rifiuto esplicito della sessione o del diritto non consente il ripiego offline. Soltanto gli errori di trasporto o HTTP 5xx possono usare un'autorizzazione esistente verificata crittograficamente e conforme alla relativa politica firmata. La prima attivazione, i posti flottanti e le politiche che vietano il funzionamento offline mantengono i propri requisiti di connessione.

I report locali non dimostrano mai pagamenti reali, rilasci di licenze o attivazioni esterne. Tale ambiente è stato rinviato; consultare acceptance.md. La pubblicazione nei registri e la qualificazione delle release per sistemi diversi da Windows richiedono attività e prove separate.