Launch: duración de compra y límites del SDK de cuentas

Este cambio solo se ha desarrollado y verificado localmente; no se ha desplegado Launch ni publicado paquetes SDK. El código fuente actual depende del protocolo de autorización de cuentas de Licentivo y de las actualizaciones correspondientes del SDK oficial; no puede combinarse con servidores antiguos que solo admiten claves de licencia de larga duración.

Responsabilidades

Los pedidos, la duración de compra y los indicadores de sincronización completada de Launch no pueden habilitar funciones protegidas. El cliente debe ejecutar el trabajo protegido mediante las interfaces de ejecución del SDK oficial, como RunFeature.

Cada producto de Launch conserva una ruta pública estable a un producto de Licentivo. Los planes del mismo producto pueden elegir políticas distintas, pero no cambiar a otro producto remoto; el guardado de asignaciones se valida en serie mediante un bloqueo de fila del producto común en la base de datos. La identidad del cliente, la publicación de planes y la configuración de integración SDK leen la misma vinculación; los borradores no pueden cambiar el contexto de producto de clientes que ya han comprado. Esto solo verifica la coherencia de la configuración de integración y no decide las autorizaciones de funciones ni dispositivos. Si una base antigua carece del campo estable, se da prioridad al historial de compras y publicaciones; si no se puede identificar una correspondencia única, se devuelve PRODUCT_MAPPING_CONFLICT. Consulte la corrección de concurrencia de asignaciones.

Sincronización de la duración de compra

Reutiliza las interfaces existentes sin añadir hechos de pago, hechos de reembolso ni servicios de cotización:

• POST /api/v1/launch/connections, PUT /connections/{id}: registran claves públicas de firma de identidad; producción y pruebas crean conexiones independientes.
• PUT /api/v1/launch/connections/{id}/plans/{plan}: registra una referencia única a la versión del plan de Launch y las versiones del producto y la política remotos.
• POST /api/v1/launch/connections/{id}/events: envía una instantánea completa de compra con versión.
• GET /api/v1/launch/connections/{id}/events/{event}: confirma el resultado del procesamiento.
• POST /api/v1/launch/connections/{id}/events/{event}/retry: reintenta el evento original después de comprobarlo.

La instantánea solo contiene ID de evento, entorno, tipo de evento, referencia de compra, referencia anónima de cuenta, producto de Launch, referencia de versión de plan, versión creciente y los valores absolutos valid_from / valid_until; en una migración se adjunta el ID de licencia antiguo. No se envían claves de pago, precios, correos de clientes ni claves de licencia de larga duración. En compras permanentes, valid_until es null y Licentivo verifica que coincida con la política.

Launch confirma el pago, registra intervalos inmutables de cobertura de compra y guarda las tareas de sincronización en la misma transacción de base de datos. Calcula la fecha límite por ciclos naturales de día/mes/año; las renovaciones conservan el anclaje de compra original, y si el pago se realiza después del vencimiento, empiezan en la hora real de pago. Launch sigue calculando las cotizaciones y los plazos de cambios a planes superiores.

Cada cambio envía los valores absolutos completos; los reintentos usan el mismo ID de evento y cuerpo, sin enviar «añadir otros N días». La tarea guarda de forma persistente la solicitud, la conexión remota y el progreso del procesamiento; las respuestas perdidas, los reinicios y los workers concurrentes no vuelven a acumular duración.

HTTP 202 solo indica que Licentivo ha recibido la solicitud. La sincronización solo se marca como completada al recibir applied; con pending se sigue consultando y manual_review y stale no confirmados permanecen pendientes de comprobación. Los errores de red se reintentan con esperas progresivas; al alcanzar el límite de fallos consecutivos se pasa a comprobación manual.

Un reembolso solo elimina el intervalo de cobertura del pedido correspondiente: reembolsar un cambio a plan superior restaura el plan base; reembolsar una renovación elimina su ampliación. Si quedan compras no reembolsadas, se sincroniza el resultado recalculado sin revocar todas las compras. Después de reembolsar todas las compras se envía entitlement.refunded. Una compra posterior usa una referencia de compra nueva para evitar reactivar licencias remotas revocadas.

Las disputas perdidas o reversiones confirmadas por el canal también eliminan solo la cobertura de compra del pedido correspondiente. El pedido se muestra como reversed; Licentivo sigue procesando los cambios reales de autorización tras aplicar la instantánea de compra. Las disputas pendientes no cambian los registros de compra. Las notificaciones históricas de reversión pendientes de comprobación pueden recuperarse verificando de nuevo sus firmas y reenviándolas por el canal original.

Después de que un reembolso desconocido pase a comprobación manual, el administrador puede recuperar la operación original mediante POST /api/v1/admin/refunds/{id}/reconcile. El recibo debe coincidir con la transacción, moneda e importe originales; no deben cambiarse el ID de operación ni la hora de aprobación originales. Fuera de la ventana segura de reintento no se deben reenviar solicitudes de fondos a ciegas.

Cuentas y clientes

1. El cliente usa POST /api/v1/auth/login para establecer una sesión real de acceso de escritorio.
2. El SDK de Launch solicita POST /api/v1/software/products/{id}/identity, especificando sandbox o live.
3. Launch emite una afirmación de identidad de 120 segundos como máximo, con destinatario y contexto de producto/compra especificados; incluye el sid real de acceso y su vencimiento. La afirmación no contiene funciones, cuotas de dispositivos ni permisos sin conexión.
4. El SDK de Launch solo pasa identity_token, launch_connection_id y environment al SDK oficial en memoria; license_key está vacío.
5. El SDK oficial llama a /api/v1/launch/exchange de Licentivo; Licentivo decide la autorización y emite las credenciales del dispositivo y el permiso firmado.

Los registros normales de cuentas de Launch usan v2 y solo conservan la sesión de cuenta y la información pública de enrutamiento, sin afirmaciones, claves de licencia ni permisos de autorización. Un cierre de sesión explícito los convierte en tareas privadas v3 exclusivas de revocación, que no pueden recuperar el inicio de sesión; se eliminan después de confirmar la revocación de la sesión de Launch. La antigua interfaz /credential devuelve HTTP 410. Las claves públicas y los ID de producto pueden distribuirse con la aplicación; las claves administrativas permanecen solo en el servidor.

Cierre de sesión, cierre y desvinculación remota

El cierre de sesión del SDK oficial detiene inmediatamente el uso de la autorización por este proceso, limpia sus credenciales de ejecución y revoca la vinculación remota con un ticket dedicado de cierre de sesión. Si falla la red, debe conservarse el archivo .logout.json del SDK y mostrarse que la revocación remota está pendiente, sin indicar que la desvinculación ha terminado correctamente. El SDK de Launch no elimina, recorre para limpiar ni modifica el directorio de caché del SDK oficial; el SDK oficial recupera y procesa los tickets pendientes de revocación al inicializar de nuevo la caché correspondiente.

El cierre de sesión de una cuenta Launch también tiene un estado pendiente independiente: en errores de red, cancelaciones o respuestas perdidas no se eliminan los registros seguros necesarios para reintentar. Volver a iniciar sesión, recuperar o cerrar sesión solo reenvía la revocación de la sesión original; la tarea pendiente no puede recuperar el inicio de sesión. Se elimina tras el éxito o cuando HTTP 401 confirma que la sesión no es válida. La recuperación entre procesos requiere un Store seguro persistente; MemoryStore solo es válido en el proceso actual. Consulte la corrección de reintentos de cierre de sesión y pruebas de integración.

Las solicitudes de desvinculación remota incluyen activation_id y expected_generation de la lista original; los reintentos reutilizan operation_id. Launch no calcula el número de desvinculaciones, no aprueba ni ejecuta por su cuenta la cola y no actualiza la generación para reintentar automáticamente una operación antigua. El número restante, el permiso de liberación, la revisión y el resultado final proceden de Licentivo.

La recuperación de cuenta Restore requiere conexión para confirmar la cuenta y obtener una afirmación de identidad nueva; Launch no decide por su cuenta permitir acceso sin conexión si falla el servicio de cuentas. Las aplicaciones que necesitan arrancar sin conexión deben integrarse según el contrato de recuperación del SDK oficial; el SDK oficial sigue verificando la firma, la duración sin conexión y el reloj.

Revocación de identidad del servidor

Integración con las interfaces existentes de Licentivo V39, sin necesidad de interfaces de hechos comerciales ni cotizaciones:

• POST /api/v1/launch/connections/{id}/session-revocations: revoca inicios de sesión antiguos del sid o cuenta especificados y devuelve un acuse confirmado síncronamente.
• GET /api/v1/launch/connections/{id}/session-revocations/{event_id}: obtiene el resultado confirmado del evento original y recupera solicitudes con respuestas perdidas.

El cierre de sesión normal de escritorio y el cierre forzado de una sesión concreta usan scope=session; la invalidación de todas las sesiones por cambio o restablecimiento de contraseña, cambio de correo, deshabilitación de cuenta o cambio de rol del personal del sitio usa scope=account. El cierre normal de una sesión del sitio no afecta al software del cliente. Launch solo notifica que la identidad ha dejado de ser válida; Licentivo gestiona las sesiones remotas de autorización, las credenciales de ejecución y la liberación de dispositivos, sin cambiar la duración de compra ni consumir la cuota de desvinculación mantenida por Launch.

La invalidación de la sesión local y la puesta en cola de la notificación se completan en la misma transacción. La cola congela las conexiones y entornos existentes en ese momento y reintenta con el mismo ID de evento, identificador anónimo de cuenta y solicitud original; las conexiones creadas después no reciben revocaciones históricas de cuentas. Primero se consulta el acuse original y solo se reenvía tras confirmar que no existe. Cada entorno conserva sus resultados de forma independiente y solo se muestra completado cuando todos han recibido acuses correctos coincidentes. La falta de red activa reintentos automáticos; los conflictos de credenciales/contrato pasan a comprobación manual. Los administradores pueden consultar y reintentar notificaciones en la página de tareas de sincronización; los reintentos no generan eventos de revocación nuevos.

La revocación de alcance de cuenta usa como límite el revoked_before de la primera aceptación de Licentivo. Mientras está pendiente la notificación, se suspenden nuevos inicios de sesión de escritorio y afirmaciones de identidad. Tras completarse, el auth_time del inicio de sesión real debe ser estrictamente posterior al segundo límite de los acuses de todos los entornos. Los inicios de sesión del mismo segundo pueden volver a autenticarse más tarde; actualizar iat o la afirmación de identidad no permite prolongar un inicio antiguo. El acceso al sitio sigue disponible para operaciones de recuperación. Tras volver a habilitar la cuenta también debe iniciarse sesión de nuevo; no se restauran sesiones antiguas.

Migración de datos antiguos

Las compras con una vinculación confirmada a una licencia antigua usan entitlement.migrated y solo envían el ID de esa licencia, sin leer ni entregar claves antiguas. Después de que Licentivo confirme la migración, se envía una instantánea independiente con versión nueva para sincronizar el plazo y el estado comerciales actuales. Los resultados antiguos de emisión no confirmados y las autorizaciones incompatibles requieren comprobación manual; los comandos administrativos antiguos no se reproducen automáticamente.

El cierre de sesión normal del SDK, la desvinculación remota de dispositivos y la revocación de identidad del servidor usan las interfaces existentes. La desactivación remota sigue limitada por el plazo de los permisos sin conexión ya emitidos por el SDK oficial; Launch no garantiza revocación inmediata en dispositivos sin conexión.

El cierre de sesión de cuentas usa tareas seguras independientes, resúmenes locales de cierre de sesión y coordinación entre procesos; las instancias antiguas solo gestionan sus propios accesos. La recuperación después de un fallo de almacenamiento reenvía primero la revocación de cuenta, sin obtener identidad ni iniciar autorización. Licentivo sigue decidiendo las funciones, permisos sin conexión, generaciones de dispositivos y cuotas de desvinculación. Consulte el registro de correcciones y pruebas de integración entre ambos sistemas.