Integração de aplicativo com Launch e Licentivo

Este guia aplica-se ao provedor Licentivo. Para conectar um sistema de licenciamento próprio do comerciante sem Licentivo, use a API de licenciamento personalizado e fluxo de integração, selecione custom_http para produto/ambiente e mantenha o SDK de execução desse sistema.

Estas mudanças locais não publicadas usam troca de identidade de conta. Consulte o contrato de responsabilidades e sincronização de compras para migração e revogação de sessão no servidor. Números de versão dos pacotes não foram publicados ou atualizados por esta mudança.

O Launch é responsável por contas de comerciantes, pedidos, preços, cotações de renovação/upgrade, reembolsos e datas absolutas compradas. O Licentivo é responsável por licenças, políticas, franquias de dispositivos, sessões de autorização, permissões assinadas e decisões de execução. Um login Launch bem-sucedido ou compra sincronizada nunca é permissão para executar trabalho protegido.

Use a página administrativa de integração para obter a chamada de conexão direta e chaves públicas fixadas do produto. Os wrappers das nove linguagens contêm o SDK oficial. Chaves de gerenciamento do comerciante e de pagamento permanecem no servidor. Configurações públicas do produto não contêm credenciais de clientes, IDs de dispositivos, caminhos de cache ou asserções de identidade.

Troca de conta

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

O wrapper solicita POST /api/v1/software/products/{id}/identity com {"environment":"sandbox"} ou live. A asserção de identidade retornada dura no máximo 120 segundos e é vinculada a emissor registrado, audience, sessão real de login, produto, ambiente e referência de compra. Não contém grants de recursos, franquia de dispositivos ou política offline.

O SDK oficial recebe estes valores em memória:

{
  "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ão grave esta configuração de execução em arquivo público nem persista sua asserção em registro de conta. Registros lembrados Launch v2 armazenam apenas a sessão da conta e o contexto público de roteamento. O endpoint antigo de cliente /credential retorna HTTP 410.

Ciclo de vida e armazenamento

• Login: autenticar a conta, solicitar nova asserção, iniciar o SDK oficial.
• Restore: confirmar online a conta lembrada, solicitar nova asserção, iniciar o SDK oficial. Uma indisponibilidade do Launch não seleciona permissão offline.
• RunFeature: delegar cada execução protegida ao SDK oficial. Um callback rejeitado nunca deve executar.
• Close / Dispose / Drop: interromper trabalho em segundo plano, preservar login intencionalmente lembrado e vinculação do nó.
• Logout: invocar logout unificado do SDK oficial, limpar o registro de conta Launch e encerrar sua sessão.
• ReleaseDevice: alias de compatibilidade para logout explícito. Informe honestamente a revogação remota pendente.

Somente o SDK oficial remove seus arquivos de credencial e concessão do dispositivo. Nunca exclua seu diretório de cache ou .logout.json: esse diário contém tickets de liberação restritos necessários após falhas de rede. O SDK retoma tickets pendentes quando o cache correspondente é inicializado novamente. O armazenamento de conta do Launch e o do SDK têm responsáveis separados.

Aplicativos que precisam de inicialização offline usam o fluxo de recuperação documentado do SDK oficial. Somente o SDK verifica permissão assinada, contexto de produto/ambiente, expiração, comportamento do relógio e estado do dispositivo. Wrappers Launch não inferem permissão de datas compradas, pedido local ou presença de arquivo.

Sessões de conta apenas em memória são o padrão. Armazenamentos persistentes de conta devem criptografar/autenticar seus registros e proteger chaves com recursos de credenciais do sistema operacional. Use cache gravável separado por comerciante, conta, produto e ambiente. Renderizadores de navegador devem receber resultados comerciais, não tokens de conta desktop, asserções ou credenciais de dispositivo.

Compras e dispositivos

O Launch calcula datas absolutas compradas a partir de pagamentos verificados e cobertura imutável de pedidos, então envia snapshots versionados para /api/v1/launch/connections/{id}/events. Consulta o evento até applied; somente recebimento não é cumprimento. Tentativas de renovação e reembolso não podem adicionar a duração novamente. Reembolsos removem apenas a cobertura do pedido pertinente; uma compra integralmente reembolsada recebe nova referência na recompra.

Usuários sem acesso a um dispositivo podem abrir a página de gerenciamento de dispositivos do Launch. Listas, liberações restantes, ações permitidas e resultados vêm do Licentivo. Uma liberação leva a geração de vinculação exibida e ID de operação inalterado. O Launch não mantém contador de liberações ou executor de tarefas concorrente.

Verificação e limitações

Teste troca de conta, armazenamento efêmero de asserção, execução de recursos controlada pelo SDK, fechamento comum, logout explícito em novo processo, diários de liberação pendente e isolamento de produto/ambiente. Teste concessões assinadas reais, verificações offline e rejeição de adulteração do SDK oficial separadamente do transporte de conta Launch. Compilação e fixtures não estabelecem aceitação em produção.

O Launch também usa POST e GET de recibo de session-revocations do Licentivo V39 para logout desktop, logout forçado de sessão, alterações de senha e desativação de conta. Ele fixa duravelmente os destinatários e solicitação originais, recupera respostas perdidas e confirma cada ambiente independentemente. Notificações pendentes de toda a conta suspendem nova autenticação desktop; após confirmação, um login realmente novo deve ter auth_time estritamente posterior ao último segundo revoked_before. Recuperação pelo site continua disponível. Essas notificações nunca alteram datas compradas. Consulte o contrato de limites e recuperação.

Consulte integração manual, integração AI, pacotes de integração e aceitação.