Integración de aplicaciones con Launch y Licentivo

Esta guía se aplica al proveedor Licentivo. Para conectar un sistema de licencias del comerciante sin Licentivo, use la API de licencias personalizadas y el procedimiento de integración, seleccione custom_http para el producto/entorno y mantenga el SDK de ejecución de ese sistema.

Estos cambios locales sin publicar usan el intercambio de identidad de cuentas. Consulte el contrato de responsabilidades y sincronización de compras para migración y revocación de sesiones del servidor. Este cambio no ha publicado ni actualizado números de versión de paquetes.

Launch gestiona cuentas del comerciante, pedidos, precios, cotizaciones de renovación/cambio a plan superior, reembolsos y fechas absolutas de compra. Licentivo gestiona licencias, políticas, cuotas de dispositivos, sesiones de autorización, permisos firmados y decisiones de ejecución. Un inicio de sesión correcto en Launch o una compra sincronizada nunca constituyen permiso para ejecutar trabajo protegido.

Use la página administrativa de integración para obtener la llamada de conexión directa y las claves públicas fijadas del producto. Los wrappers de los nueve lenguajes contienen el SDK oficial. Las claves administrativas y de pago del comerciante permanecen en el servidor. La configuración pública de producto no contiene credenciales de clientes, ID de dispositivos, rutas de caché ni afirmaciones de identidad.

Intercambio de cuentas

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

El wrapper solicita POST /api/v1/software/products/{id}/identity con {"environment":"sandbox"} o live. La afirmación de identidad devuelta dura como máximo 120 segundos y está vinculada a un emisor registrado, audiencia, sesión real de acceso, producto, entorno y referencia de compra. No contiene permisos de funciones, cuota de dispositivos ni política sin conexión.

El SDK oficial recibe estos valores en memoria:

{
  "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": ""
}

No escriba esta configuración de ejecución en un archivo público ni conserve su afirmación en un registro de cuenta. Los registros de acceso recordado Launch v2 solo guardan la sesión de cuenta y el contexto público de enrutamiento. El antiguo endpoint cliente /credential devuelve HTTP 410.

Ciclo de vida y almacenamiento

• Login: autenticar la cuenta, solicitar una afirmación nueva e iniciar el SDK oficial.
• Restore: confirmar en línea la cuenta recordada, solicitar una afirmación nueva e iniciar el SDK oficial. Una interrupción de Launch no determina un permiso sin conexión.
• RunFeature: delegar toda ejecución protegida al SDK oficial. Un callback rechazado nunca debe ejecutarse.
• Close / Dispose / Drop: detener el trabajo de segundo plano y conservar el acceso recordado intencionadamente y la vinculación al equipo.
• Logout: invocar el cierre de sesión unificado del SDK oficial, limpiar después el registro de cuenta Launch y terminar su sesión de cuenta.
• ReleaseDevice: alias compatible de cierre de sesión explícito. Informe con precisión de la revocación remota pendiente.

Solo el SDK oficial elimina su credencial de dispositivo y los archivos de arrendamiento. Nunca elimine su directorio de caché ni .logout.json: ese registro contiene tickets de liberación restringidos necesarios tras solicitudes de red fallidas. El SDK reanuda los tickets pendientes cuando se inicializa de nuevo la caché correspondiente. El almacenamiento de cuentas propio de Launch y el almacenamiento SDK tienen responsables separados.

Las aplicaciones que necesitan arrancar sin conexión usan el procedimiento documentado de recuperación del SDK oficial. Solo el SDK verifica el permiso firmado, el contexto de producto/entorno, el vencimiento, el comportamiento del reloj y el estado del dispositivo. Los wrappers de Launch no deducen permisos de fechas de compra, pedidos locales ni de la presencia de un archivo.

Las sesiones de cuenta solo en memoria son el valor predeterminado. Los almacenes persistentes de cuentas deben cifrar/autenticar sus registros y proteger las claves con las funciones de credenciales del sistema operativo. Use una caché escribible independiente por comerciante, cuenta, producto y entorno. Los procesos de renderizado del navegador deben recibir resultados de negocio en lugar de tokens de cuentas de escritorio, afirmaciones o credenciales de dispositivos.

Compras y dispositivos

Launch calcula fechas absolutas de compra a partir de pagos verificados y cobertura inmutable de pedidos, y envía instantáneas con versión a /api/v1/launch/connections/{id}/events. Consulta periódicamente el evento hasta applied; la recepción por sí sola no equivale a entrega completada. Los reintentos de renovación y reembolso no pueden añadir duración por segunda vez. Los reembolsos eliminan solo la cobertura del pedido correspondiente; una compra totalmente reembolsada se sustituye por una referencia nueva al volver a comprar.

Los usuarios sin acceso a un dispositivo pueden abrir la página de gestión de dispositivos de Launch. Las listas, las liberaciones restantes, las acciones permitidas y los resultados de operaciones proceden de Licentivo. Una liberación incluye la generación de vinculación mostrada y un ID de operación que no cambia. Launch no mantiene un contador de liberaciones ni un ejecutor de tareas paralelo.

Verificación y limitaciones

Pruebe el intercambio de cuentas, el almacenamiento efímero de afirmaciones, la ejecución de funciones controlada por el SDK, el cierre normal, el cierre explícito desde un proceso nuevo, los registros de liberación pendientes y el aislamiento de producto/entorno. Pruebe los arrendamientos firmados reales del SDK oficial, sus comprobaciones sin conexión y el rechazo de manipulaciones por separado del transporte de cuentas Launch. La compilación y las fixtures no demuestran la aceptación en producción.

Launch también usa los endpoints POST session-revocations y GET de acuses de Licentivo V39 para cierre de sesión de escritorio, cierre forzado, cambios de contraseña y deshabilitación de cuentas. Congela de forma persistente los destinatarios y la solicitud originales, recupera respuestas perdidas y confirma cada entorno por separado. Las notificaciones pendientes de toda la cuenta suspenden nuevas autenticaciones de escritorio; tras la confirmación, un inicio de sesión realmente nuevo debe tener auth_time estrictamente posterior al último segundo de revoked_before. La recuperación mediante el sitio sigue disponible. Estas notificaciones nunca cambian las fechas de compra. Consulte el contrato de límites y recuperación.

Consulte Integración manual, Integración con IA, Paquetes de integración y Aceptación.