Descargar MarkdownDocumento original en GitHub
Corrección de reintentos de cierre de sesión de cuentas del SDK de Launch
Fecha: 2026-10-24. Se corrigió AUTH-07 y se actualizaron los puntos de entrada del ciclo de vida de cuentas de Go, JavaScript, Python, C#, Java, Ruby, Rust, C y C++. Sin despliegue, publicación del SDK, commits ni envíos a Git. Esta tarea no modificó el código de negocio del servidor de Launch ni de Licentivo.
Comportamiento
El cierre de sesión explícito marca primero el registro de cuenta del almacén seguro como «solo pendiente de revocación», llama después al cierre de sesión del SDK oficial y envía a Launch la revocación de la sesión de cuenta. Independientemente del estado de red o cancelación, el entorno de ejecución local se detiene y no permite seguir ejecutando funciones protegidas.
Mientras Launch no confirme la revocación, el SDK conserva la tarea pendiente y las credenciales originales de cuenta necesarias para reintentar, sin tratarla como una cuenta con sesión iniciada. Volver a llamar a Logout, Login o Restore reanuda la solicitud de revocación; Restore no usa la tarea pendiente para solicitar identidad ni iniciar el entorno de autorización. La tarea de cuenta solo se elimina tras recibir una respuesta correcta o un HTTP 401 que indique que la sesión original ya no puede autenticarse. Así también se recupera una respuesta perdida y se evita que «el segundo cierre de sesión devuelva éxito sin haber reenviado nunca la revocación».
Los registros normales de cuentas con sesión iniciada siguen siendo compatibles con v2. Los registros pendientes de revocación usan un formato privado v3; Java y Rust también eliminaron de esa estructura los campos de credenciales necesarios para el inicio normal, para evitar que los SDK antiguos confundan las tareas pendientes con sesiones normales. Las tareas pendientes no guardan afirmaciones de identidad breves, claves de licencia ni permisos firmados.
Las tareas pendientes de cuentas usan el Store seguro configurado originalmente. La recuperación entre procesos requiere almacenamiento seguro persistente, como Windows DPAPI o un almacén cifrado compatible con el SDK; el MemoryStore predeterminado solo conserva los datos en el proceso actual. Los reintentos se activan en operaciones posteriores de inicio de sesión, recuperación o cierre de sesión, sin añadir tareas independientes en segundo plano. El almacenamiento o la revocación sin completar devuelve un error o resultado pendiente, sin indicar éxito.
El SDK de Licentivo sigue gestionando sus tickets de cierre de sesión de dispositivos y .logout.json; Launch no elimina su directorio de caché ni decide permisos de dispositivos, funciones o uso sin conexión. También se actualizaron los ejemplos nativos y la documentación SDK de cada lenguaje.
Verificación
| Alcance | Resultado |
|---|---|
| Paquetes de código fuente Go de Launch | 185 registros de pruebas superadas, incluidos subcasos; sin fallos; go vet superado |
| HTTP real de Launch y MySQL | Tras interrumpirse la solicitud de cierre de sesión, se conserva la tarea segura pendiente; al recrear el SDK no se puede recuperar el inicio de sesión; al volver la red se reenvía la revocación y las interfaces de autenticación e identidad rechazan el token antiguo |
| JavaScript | 10 pruebas superadas, incluidos cierre de sesión fallido, recuperación tras recreación y confirmación 401 |
| Python | 8 pruebas superadas, incluidas limpieza de cuenta local tras cerrar sesión, recuperación tras recreación y Windows DPAPI |
| C# | Superadas las comprobaciones de ciclo de vida, recuperación de tareas pendientes, conservación de registros de cierre del SDK y DPAPI |
| Java | 7 grupos de pruebas de ciclo de vida y seguridad superados, incluidos reintentos de cierre de sesión sin conexión |
| Ruby | Regresión del ciclo de vida de cuentas, recuperación de tareas pendientes y almacenamiento cifrado superada |
| Rust | Todas las pruebas locales superadas, incluida recuperación de tareas pendientes tras recreación y ejecución real del SDK |
| C / C++ | Superadas las pruebas del SDK con firmas reales, recuperación tras recreación sin red, confirmación 401, DPAPI y puntos de entrada de ejecución C++ |
| Correcciones actuales de autorización de Licentivo | 45 registros de pruebas superadas, sin fallos ni omisiones; incluyen notificaciones negativas ante desviaciones de políticas, coordinación de dispositivos con límites reducidos, topes manuales de dispositivos y regresión de autorizaciones existentes |
| SDK oficial incorporado | Los hashes de los 115 archivos del manifiesto coinciden; no se modificó su implementación de autorización ni cifrado |
En la regresión del código fuente de Launch se omitieron las cuatro pruebas TestMySQLBaseline, TestProductUploadRoundTrip, TestInitialAdministratorMustChangePasswordBeforeAdministration y TestNewPaymentProvidersAndRegistrationWithoutMail, que dependen de otras bases dedicadas; no se contaron como superadas. El SDK, el HTTP de cuentas, la sincronización de compras y los procedimientos de asignación de esta tarea se verificaron con bases de datos de prueba independientes.
Pruebas de integración entre ambos sistemas
Se completaron 15 fases de negocio usando un MySQL 8.0.32 local independiente, los servicios actuales de Launch y Licentivo con sus workers, el SDK Go real de Launch y el entorno oficial de autorización, y almacenamiento DPAPI de cuentas.
Se añadieron dos verificaciones de fallos de cierre de sesión:
- Solicitud no entregada a Launch: la interfaz de cierre de sesión de cuenta devuelve temporalmente 503. El SDK detiene las funciones locales, se libera la vinculación real de dispositivo de Licentivo y se conserva la tarea de revocación de cuenta pendiente. Después de recrear el SDK solo se reintenta el cierre de sesión; al recuperar la conexión se revoca la sesión original de Launch y Licentivo confirma que recibió la notificación correspondiente.
- Servidor ya revocado, pero respuesta perdida: Launch ha procesado el cierre y el proxy de prueba sustituye la respuesta por 503. La tarea pendiente se conserva entre recreaciones del SDK; al recuperar la conexión, HTTP 401 confirma que la sesión original ha dejado de ser válida y elimina la tarea. No se recupera el inicio de sesión ni se reactiva el dispositivo durante el proceso.
Las demás fases cubren sincronización real de compras y ejecución de funciones firmadas, recuperación tras cierre normal, cierre de sesión normal, desvinculación remota y generaciones antiguas, renovaciones y reembolsos, revocación de cuentas y nuevo inicio de sesión, rechazo de ejecución tras reembolso total, recuperación de reembolsos, reversiones y regresión de traducción de documentos largos. El responsable de Licentivo proporcionó sus tres actualizaciones; esta tarea solo las compiló y verificó.
Los canales de pago y DeepL usan servicios simulados aislados, sin cargos, reembolsos ni traducciones de pago reales. La verificación conjunta con servicios reales usa Go; los demás lenguajes completan la regresión SDK local, sin afirmar que cada uno de los nueve haya completado una aceptación completa de despliegue con servicios reales.
En esta ronda no se accedió a 192.168.2.177. Se detuvieron los procesos temporales de MySQL y Licentivo y se conservaron los servicios originales y las pruebas. Los materiales originales están en .local/logout-retry-fix-20261024/; consulte el resumen y los hashes de código fuente en las pruebas de verificación.