Descargar MarkdownDocumento original en GitHub
Correcciones de cierre de sesión de cuentas y múltiples instancias del SDK de Launch, y pruebas de integración entre ambos sistemas
Fecha: 2026-10-24. Completadas las correcciones correspondientes al SDK de Launch de las tareas 1 y 3 autorizadas por el usuario, relativas a la persistencia de cuentas de AUTH-08 y a AUTH-10. Se integraron las actualizaciones de Licentivo y se completó la integración local. Esta tarea no se puso en producción, no publicó SDK ni realizó commits o envíos a Git.
Resultados de la corrección
Las tareas pendientes de cierre de sesión y el inicio de sesión actual recuperable usan claves distintas en el almacén seguro. Si falla escribir el marcador de cierre, solo se limpia el acceso antiguo de esa instancia, sin eliminar otras sesiones. La intención local adicional de cierre de cuenta se registra con un resumen criptográfico del alcance y las credenciales de sesión; se comprueba antes de recuperar la cuenta, incluidos fallos de escritura/eliminación del almacén seguro y reinicios tras un timeout de mutex. No guarda bearer, afirmaciones de identidad ni licencias y no decide permisos de funciones.
Las operaciones de ciclo de vida de cuentas del mismo usuario del sistema operativo y dispositivo se coordinan entre instancias y procesos. Los cierres tardíos de instancias antiguas, las limpiezas por HTTP 401, los reenvíos tras fallos y los cierres repetidos después del éxito no pueden sobrescribir ni eliminar accesos nuevos guardados posteriormente. Las tareas de sesiones antiguas pueden reenviar la revocación de cuenta por separado, sin recrear el entorno de autorización de otras sesiones actuales.
Se actualizaron los puntos de entrada del ciclo de vida Application de Go, JavaScript, Python, C#, Java, Ruby, Rust y C/C++, los ejemplos nativos y las instrucciones de integración. Las firmas de métodos públicos del Store seguro no cambian; deben admitir correctamente varias claves opacas y guardado atómico. Las credenciales de cuenta del MemoryStore predeterminado siguen guardándose solo en memoria. Si ni el Store seguro ni el marcador local de cierre pueden persistir, el SDK informa explícitamente del error y detiene esta instancia, sin afirmar que el cierre se haya completado de forma recuperable tras reiniciar.
Actualizaciones de Licentivo
Las pruebas reales de ejecución de esta ronda usaron el SDK oficial 0.11.1, con identificador fijo de instantánea local-20261024-5d74ba5ea131. Se sincronizó mediante el script de importación existente del repositorio; el manifiesto contiene 115 archivos: 23 cambiaron realmente, 92 no cambiaron y no hubo archivos nuevos. Los cambios corresponden a 17 archivos fuente del proyecto original; el núcleo C se empaqueta repetidamente en los paquetes nativo, Ruby y Rust. Al terminar las pruebas se verificaron los hashes de los archivos de destino y la instantánea original de esta importación probada.
Esta tarea no modificó el código fuente del servidor de Licentivo; la implementación de autorización del SDK usa la versión proporcionada por la otra parte. Las pruebas locales se ajustaron al contrato actualizado: el cierre de sesión conserva las credenciales y los archivos de permiso compartidos del equipo y el registro de cierre del SDK bloquea sesiones antiguas; el segundo acuse de una desvinculación duplicada puede ser stale. Se siguen comprobando el rechazo real de ejecución, la recuperación de vinculaciones nuevas y la cuota de autoservicio, sin relajar esos requisitos de negocio.
Al finalizar, el espacio de trabajo se había actualizado adicionalmente al SDK de Licentivo 0.11.2 (licentivo-sdk-v0.11.2-release-20261024). Los hashes de los 115 archivos de destino actuales coinciden con el manifiesto y los archivos fuente originales. Frente a la instantánea probada en esta ronda, los únicos cambios de los archivos originales están en VERSION, la constante VERSION de Ruby y el número de versión de CMake; la implementación de autorización es la misma. El script de importación actual también añade búsqueda de bibliotecas nativas en el directorio de extensiones de la gem Ruby. Los registros de pruebas de ejecución anteriores corresponden a la instantánea fija 0.11.1; este informe no constituye un registro de aceptación de los paquetes publicados de 0.11.2.
Verificación
| Alcance | Resultado |
|---|---|
| HTTP de cuentas Go de Launch, DPAPI, fallos de almacenamiento del cierre de sesión y bloqueos entre procesos | 26 registros superados, incluidos subcasos; sin fallos ni omisiones |
| Regresión de cuentas Go y SDK firmado tras sincronizar el SDK oficial | 21 pruebas superadas; se omitieron dos pruebas HTTP que requieren bases de datos independientes, ya verificadas en la fila anterior y en la integración real entre ambos sistemas |
| Regresión actual de autorización HTTP de Licentivo y controles específicos | Uniendo dos ejecuciones por caso de prueba, 62 registros finales superados; incluye la nueva comprobación tras corregir las aserciones de acuses duplicados |
| SDK Go oficial actual | 67 registros superados, sin fallos |
| JavaScript / Python | 14 / 12 pruebas superadas, incluido el entorno de ejecución con firmas reales |
| C# / Java | Ciclo de vida y entorno oficial superados; 9 grupos de pruebas Java de cuenta/seguridad superados |
| Ruby / Rust | 17 pruebas Ruby superadas de la capa de wrapper y el SDK nativo real; 16 pruebas Rust superadas |
| C / C++ | Ambos controladores de ciclo de vida del SDK con firmas reales superados, cubriendo DPAPI, falta de red, fallos de almacenamiento y cierre de sesión de instancias antiguas |
La integración real entre ambos sistemas usó Launch real, Licentivo actual, MySQL, SDK Go de Launch, SDK oficial de autorización y DPAPI, y obtuvo 18 registros de fases superadas (17 fases de verificación y un registro de finalización). Incluye sincronización de duración de compra, funciones protegidas reales, recuperación tras cierre normal, fallos de escritura del almacenamiento de cierre/fallos de escritura y eliminación combinados con interrupciones de red en ambos sistemas, rechazo de recuperación de cuentas antiguas tras reiniciar, reenvío de revocación al volver la red, nuevo inicio de sesión, pérdida de respuestas, desvinculación remota, renovaciones y reembolsos y rechazo de autorización tras reversiones.
Las verificaciones específicas con servicios reales también confirmaron que enviar distintos ID de operación para la misma generación de vinculación solo consume una unidad de cuota de autoservicio; el cierre antiguo no elimina credenciales ni permisos de vinculaciones nuevas y estas se pueden recuperar sin red; un JWT nuevo emitido para el mismo sid antiguo no puede recuperar una vinculación ya cerrada, mientras que un inicio de sesión real nuevo sí puede activar; los tickets de cierre antiguos no afectan a vinculaciones nuevas; y la ejecución sin conexión no supera el plazo firmado conocido.
En esta ronda no se encontraron problemas de negocio bloqueantes nuevos. Las pruebas de ejecución se completaron en Windows; la cadena real entre ambos sistemas usó Go y los demás lenguajes completaron pruebas SDK locales con firmas. Los servicios de pago y traducción fueron simulaciones aisladas, sin cargos, reembolsos ni despliegues reales; no se accedió a 192.168.2.177. Se confirmó la detención del servicio Licentivo temporal y de MySQL y se conservaron los servicios originales y los demás cambios del espacio de trabajo.
Los registros originales, las instantáneas de código fuente probadas y las herramientas de comprobación están en el directorio ignorado .local/account-store-fix-20261024/. Consulte un resumen compartible en las pruebas de verificación.