Pacotes de integração de aplicativos Launch

O Launch 0.1.6 incorpora o SDK oficial Licentivo 0.11.6 para as nove linguagens. Instale apenas o pacote Launch da sua linguagem. Sua implementação, adaptador padrão, avisos de licença e configuração de vinculação do SDK estão incluídos. Declarações TypeScript pertencem ao JavaScript; o backend Go Web confiável é um exemplo adicional. Fontes públicas, comandos de registro e disponibilidade por linguagem são mantidos no repositório Launch SDK e em seu estado de publicação.

A atualização 0.1.6 traz a correção upstream C/C++ CMake para consumidores de curl config-package e FindCURL. O protocolo de licenciamento, APIs do aplicativo e ciclo de vida da conta não mudaram. Aplicativos existentes podem atualizar o pacote Launch e recompilar sem alterar o código de integração. O registro de publicação 0.1.6 acompanha a disponibilidade pública e a verificação de instalação limpa separadamente dos builds locais.

Instalar de um registro público

As verificações públicas de instalação 0.1.6 passaram para as nove linguagens: Go, Python, C#, Java, Node.js/TypeScript, Rust, Ruby, C e C++. Os comandos de registro e downloads nativos abaixo estão disponíveis publicamente e foram verificados em consumidores independentes. O estado de publicação registra checksums exatos dos pacotes, resultados de instalação e limites das plataformas.

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 coordenadas Maven/Gradle com.licentivo.launch:launch-client:0.1.6. C/C++ usam o arquivo nativo compatível com ABI da release versionada do GitHub. Consulte o estado de publicação para propagação do registro e resultados de verificação.

Instalar uma distribuição baixada

Use os artefatos identificados em integration-packages.json. Cada linguagem registra sdk_managed: true e requires_separate_official_sdk: false. Verifique SHA256SUMS antes da instalação.

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 apenas o JAR Launch no classpath; seu POM não tem dependência do SDK oficial. Consumidores Go offline podem extrair o ZIP do módulo e usar require/replace local para github.com/spf86/licentivo-launch-sdk. Consumidores Rust offline podem extrair o crate ou ZIP de fonte e adicionar dependência de caminho local licentivo-launch. Não é necessário pacote ou checkout do SDK oficial.

Para C/C++, extraia o ZIP de instalação nativa, adicione seu prefixo ao CMake e use:

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

O Launch resolve seu próprio SDK, bibliotecas transitivas e DLLs Windows incluídas. O build.rs do Rust compila o núcleo C incorporado e copia DLLs incluídas ao lado dos executáveis Cargo. A gem de plataforma Ruby inclui seu núcleo nativo privado e bibliotecas de execução; a gem de fonte compila o núcleo automaticamente.

As cadeias de ferramentas e dependências comuns continuam necessárias: pip resolve cryptography, NuGet resolve BouncyCastle.Cryptography e Cargo resolve crates Rust comuns. Arquivos nativos abrangem Windows amd64 GNU e Linux amd64. Distribuições Windows incluem curl. Outros sistemas usam o código-fonte completo com compilador C11 e bibliotecas de desenvolvimento curl/OpenSSL normais do OS. O núcleo nativo Windows do SDK 0.11.6 exige GNU/MinGW.

Inicializar o aplicativo

Selecione o software existente no Launch. Ele lê automaticamente a URL atual do comerciante, o mapeamento existente de plano/produto e as chaves públicas oficiais de assinatura, fornecendo uma função de conexão preenchida. Copie essa função para o aplicativo; não é necessário inserir IDs internos manualmente nem gerar arquivo de configuração. A inicialização do servidor ainda usa o config.yaml privado, que nunca acompanha o aplicativo.

Use o ponto de entrada do pacote, como launchclient.Connect, Python Application.connect, C# Application.Connect ou Node Application.connect. A fábrica integrada cria e gerencia o SDK. Fábricas personalizadas são ganchos opcionais de teste/integração, não etapas de instalação. As APIs exatas estão no README e exemplo de cada pacote.

O Launch gerencia login de conta, credenciais com escopo, tentativas pendentes limitadas e restauração. O SDK incorporado verifica assinaturas e autoriza cada operação protegida. Fechamento normal, logout e liberação de dispositivo são distintos. Aplicativos Web verificam permissões em backend confiável; código Node/Electron pertence ao processo principal ou servidor.

Instruções de desenvolvimento manual permanecem em manual-integration.md e no README de cada linguagem. A página administrativa de integração AI gera instruções em inglês para o mesmo fluxo de inicialização direta. Ela exclui senhas, chaves de gerenciamento e credenciais de cliente/dispositivo em execução e não chama serviço AI. Consulte integração AI.

Criar distribuições como mantenedor

Somente mantenedores que atualizam o SDK incorporado precisam de fontes upstream revisadas. Consumidores podem pular esta seção.

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

Forneça caminhos de ferramentas com -Python, -DotNet, -JavaHome, -Ruby, -Cargo e -CMake conforme necessário. O construtor verifica o manifesto upstream; depois prepare-managed-sdk.mjs incorpora as fontes e registra valores SHA-256 de origem/destino em sdk/managed-sdk-manifest.json. Locais/importações de módulos mudam quando necessário; a verificação criptográfica permanece na implementação revisada. Licenças MIT e avisos acompanham cada cópia incorporada.

Cada build cria um novo diretório com artefatos por linguagem, arquivos de fonte, pacote de fonte combinado, inventário e checksums. -SourceOnly emite explicitamente artefatos de fonte; alvos ignorados não são releases binárias testadas. O pacote combinado preserva caminhos de pacotes, exemplos, documentação e testes sem exigir examples/vendor.

Verificar instalações e comportamento

scripts/test-managed-installations.ps1 instala a distribuição em projetos novos de consumidores. Verifica os nove alvos sem pacote separado do SDK oficial, caminho de fonte do SDK, adaptador copiado ou configuração manual de vínculo do SDK. Compila e executa exatamente os trechos de conexão direta gerados, incluindo dados públicos escapados, e informa configuration_files_required: false. Seu relatório é separado da suíte de execução.

scripts/test-integration-packages.ps1 executa regressões de ciclo de vida e fixtures de SDK real assinadas localmente. Forneça caminhos das ferramentas e um build nativo de teste configurado:

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

Builds de fonte do repositório usam dependências nativas normais do OS; mantenedores Windows podem fornecer LICENTIVO_CURL_ROOT. É uma configuração da ferramenta de build de fonte, não instalação separada do SDK. Com instalações MinGW diferentes de Rust/C++, -NativeRuntimeDirectories limita diretórios de DLL C++ às verificações nativas. Pré-requisitos ausentes falham o alvo afetado. all_nine_passed exige sucesso das nove verificações.

Armazenamento e aceitação

Sessões usam memória por padrão. Login lembrado precisa de armazenamento protegido. Armazenamentos AES-GCM exigem chave de 32 bytes obtida de um cofre do OS e nunca armazenada junto ao texto cifrado. Senhas nunca são persistidas. Go, Python, C# e C/C++ nativo oferecem DPAPI do usuário atual no Windows; Java, Node, Rust e Ruby oferecem armazenamento criptografado com chaves gerenciadas pelo chamador.

Arquivos de dispositivo do SDK mantêm seu formato upstream. A criptografia de sessão não criptografa todos os arquivos do SDK. Restrinja diretórios de cache por conta/produto/ambiente e exclua-os de instaladores, logs e controle de versão. Mudanças de identidade/configuração não podem reutilizar cache de outra conta.

Negação explícita de sessão/entitlement não pode recorrer ao modo offline. Apenas falhas de transporte ou HTTP 5xx podem usar um grant existente verificado criptograficamente dentro da política assinada. Primeira ativação, assentos floating e políticas que proíbem operação offline mantêm seus requisitos de conexão.

Relatórios locais nunca comprovam pagamento real, emissão ou ativação externa. Esse ambiente foi adiado; consulte acceptance.md. Publicação no registro e qualificação de releases não Windows exigem trabalho e evidências separados.