Baixar MarkdownDocumento original no GitHub
Correção de repetição de logout de conta do Launch SDK
Data: 2026-10-24. AUTH-07 foi corrigido e pontos de entrada do ciclo de vida de conta Go, JavaScript, Python, C#, Java, Ruby, Rust, C e C++ foram sincronizados. SDK não foi implantado ou publicado, e não houve commit ou push Git. Este trabalho não alterou código comercial de servidor Launch ou Licentivo.
Comportamento
Logout explícito primeiro marca o registro da conta no armazenamento seguro como “somente revogação pendente”, depois chama logout do SDK oficial e envia revogação da sessão de conta ao Launch. Independentemente de rede ou cancelamento, o runtime local para e recursos protegidos não podem continuar.
Enquanto o Launch não confirma a revogação, o SDK mantém a tarefa pendente e as credenciais originais necessárias para nova tentativa, mas não as considera conta conectada. Novo Logout, Login ou Restore recupera a solicitação de revogação; Restore não usa a pendência para solicitar identidade ou iniciar runtime de autorização. A pendência só é excluída após sucesso ou HTTP 401 indicando que a sessão original não pode mais autenticar. Assim, resposta perdida também é recuperável e não ocorre “segundo logout retorna sucesso sem reenviar a revogação”.
Registros de login normais continuam compatíveis com v2. Registros de revogação pendente usam formato privado v3; Java e Rust também removeram a forma dos campos de credenciais necessários ao login normal, impedindo que SDK antigo confunda pendência com login. A pendência não armazena asserções curtas, chaves de licença ou permissões assinadas.
A pendência de conta usa o Store seguro originalmente configurado. Recuperação entre processos exige armazenamento seguro persistente, como Windows DPAPI ou armazenamento criptografado suportado pelo SDK; MemoryStore padrão mantém dados apenas neste processo. Nova tentativa é acionada por login, restauração ou logout posteriores, sem nova tarefa independente em segundo plano. Falha de armazenamento ou revogação incompleta retorna erro ou resultado pendente, sem informar sucesso.
Tickets de logout de dispositivo e .logout.json continuam gerenciados pelo SDK Licentivo; Launch não exclui seu diretório de cache nem decide direitos de dispositivos, recursos ou offline. Exemplos nativos e documentação SDK de cada linguagem também foram atualizados.
Verificação
| Escopo | Resultado |
|---|---|
| Pacotes de fonte Launch Go | 185 registros de testes aprovados, incluindo subtestes; nenhuma falha; go vet passou |
| Launch HTTP real e MySQL | Após interrupção do pedido de logout, pendência segura preservada; SDK reconstruído não consegue restaurar login; após retorno da rede, revogação reenviada e interfaces de autenticação e identidade rejeitam o token antigo |
| JavaScript | 10 aprovados, incluindo falha de logout, recuperação após reconstrução e confirmação 401 |
| Python | 8 aprovados, incluindo limpeza de conta local após logout, recuperação após reconstrução e Windows DPAPI |
| C# | Ciclo de vida, recuperação de pendência, retenção de log de logout SDK e verificações DPAPI aprovados |
| Java | 7 grupos de testes de ciclo de vida e segurança aprovados, incluindo repetição de logout offline |
| Ruby | Regressão de ciclo de vida de conta, recuperação de pendência e armazenamento criptografado aprovada |
| Rust | Todos os testes locais aprovados, incluindo recuperação de pendência após reconstrução e execução do SDK real |
| C / C++ | SDK assinado real, recuperação após reconstrução sem rede, confirmação 401, DPAPI e ponto de execução C++ aprovados |
| Correções atuais de autorização Licentivo | 45 registros de testes aprovados, sem falhas ou ignorados; inclui notificações negativas com desvio de política, coordenação de dispositivos em plano inferior, limite manual de dispositivos e regressão de autorização existente |
| SDK oficial incorporado | Hashes de todos os 115 arquivos do manifesto coincidem; implementação de autorização ou criptografia não foi alterada |
Na regressão de fonte Launch, quatro testes dependentes de outros bancos dedicados foram ignorados e não contados como aprovados: TestMySQLBaseline, TestProductUploadRoundTrip, TestInitialAdministratorMustChangePasswordBeforeAdministration, TestNewPaymentProvidersAndRegistrationWithoutMail; os fluxos SDK, HTTP de conta, sincronização de compra e mapeamento desta rodada foram verificados em banco de teste isolado.
Teste conjunto dos dois lados
Com MySQL 8.0.32 local isolado, Launch atual, serviço Licentivo e seus workers, Go Launch SDK real e runtime oficial de autorização e armazenamento de conta DPAPI, foram concluídas 15 etapas comerciais.
Foram adicionadas duas verificações de falha de logout:
- A solicitação não chegou ao Launch: o endpoint de logout da conta retorna temporariamente 503. O SDK interrompe recursos locais, a vinculação real de dispositivo Licentivo é liberada e a revogação de conta permanece pendente. Após reconstruir o SDK, apenas logout é repetido; quando a conexão retorna, a sessão Launch original é revogada e Licentivo confirma a notificação correspondente.
- Servidor revogou, mas a resposta foi perdida: o Launch processou logout e o proxy de teste substituiu a resposta por 503. A pendência persistiu após reconstruir o SDK; quando a conexão retornou, HTTP 401 confirmou a invalidez da sessão original e a pendência foi excluída. Não houve restauração de login ou reativação do dispositivo.
As demais etapas cobriram sincronização de compra e execução de recurso assinado reais, recuperação após fechamento comum, logout normal, desvinculação remota e geração antiga, reembolso de renovação, revogação de conta e novo login, recusa de execução após reembolso integral, recuperação de reembolso, chargeback e regressão de tradução de documentos grandes. Três atualizações Licentivo foram fornecidas por seu responsável; este trabalho apenas compilou e verificou.
Canais de pagamento e DeepL usaram serviços simulados isolados, sem cobrança, reembolso ou tradução paga reais. A verificação conjunta com serviços reais usou Go; outras linguagens concluíram regressão SDK local, sem afirmar aceitação de implantação real separada para cada uma das nove.
192.168.2.177 não foi acessado nesta rodada. Processos temporários MySQL e Licentivo foram encerrados, serviços existentes e evidências preservados. Material original em .local/logout-retry-fix-20261024/; resumo e hashes de fonte em evidências de verificação.