Guía de integración manual (9 lenguajes, sin necesidad de IA)

Esta guía se aplica al proveedor Licentivo. Los comerciantes que ya usan otro sistema de autorización pueden seleccionar un servicio personalizado en «Selección y personalización de la autorización» en el backend, seguir la API de autorización personalizada y el procedimiento de integración y continuar usando el SDK de su propio sistema de autorización.

Los cambios actuales aún no publicados usan el intercambio de identidad de cuentas. Consulte las responsabilidades y restricciones de migración en Duración de compra y límites del SDK de cuentas. Launch calcula la duración de compra; el SDK de Licentivo aplica la autorización.

Instale solo el paquete de integración de Launch del lenguaje correspondiente. El paquete de Launch incluye el SDK oficial, el adaptador predeterminado y la configuración de enlace; la dirección oficial de autorización es fija: https://www.licentivo.com. El programa inicia sesión con la cuenta registrada por el comprador en la tienda Launch actual.

Obtener el código de inicialización rellenado

1. Complete en el backend de Launch la asociación entre software, planes de venta y políticas de autorización de Licentivo, y publíquela en el entorno correspondiente.
2. Abra Integración del programa → Comprobación de integración y código y seleccione el software, el lenguaje y el entorno de prueba/producción.
3. Haga clic en «Leer información del producto y generar código de integración». Launch lee automáticamente la dirección pública actual del sitio, las asignaciones de productos existentes y la clave pública de firma.
4. Copie la función de conexión de la página a su proyecto y escriba manualmente la interfaz y las llamadas de negocio como se describe a continuación. También puede revisar los parámetros rellenados automáticamente y llamar directamente a Connect/connect del lenguaje correspondiente.

No es necesario introducir manualmente los dos ID internos de producto ni generar launch-config.json o product.json. La página permite guardar la función de conexión como código fuente. El archivo privado del servidor config.yaml solo sirve para iniciar el servicio Launch y no se puede distribuir con el software de los clientes.

La dirección del sitio procede de la dirección pública válida de la instancia actual (public_url de la configuración de inicio o la dirección pública válida de la configuración del sitio en el backend). Puede ser un dominio o una dirección IP con puerto, pero debe incluir el protocolo; la integración en producción usa HTTPS válido. La dirección de escucha http_addr no es la dirección de acceso de los clientes. Después de cambiar la dirección del sitio, la asignación de productos o el entorno, obtenga de nuevo la función de conexión del sitio actual; las sesiones y las cachés del sitio antiguo no deben usarse como autorización del sitio nuevo.

Los dos identificadores de producto representan una correspondencia interna ya existente: el producto de software de Launch y el producto de autorización de Licentivo. La página de integración los rellena automáticamente según el software seleccionado; el comprador solo introduce la cuenta de la tienda. El servidor obtiene la clave pública de firma mediante la conexión Licentivo configurada; la clave administrativa y las credenciales de autorización de los clientes no se incluyen en el código fuente.

Función de Connect/connect

Connect/connect es el nombre que los distintos lenguajes dan a la operación «crear un cliente de aplicación Launch». Go, C# y algunas interfaces nativas usan Connect con inicial mayúscula; Python, JavaScript, Ruby y otros lenguajes usan connect según sus convenciones. connectLaunch(), connect_launch() o LaunchConnection.Open(), generados por el backend, son funciones del proyecto con los parámetros públicos rellenados que llaman internamente al punto de entrada del lenguaje correspondiente.

La conexión solo completa la inicialización: verifica la dirección de la tienda, la asignación de productos, el entorno y la clave pública de firma, crea el cliente Launch y configura el SDK oficial de Licentivo incluido en el paquete. No verifica la identidad del cliente ni habilita directamente las funciones de pago. La secuencia completa es:

Connect/connect → Login or Restore → RunFeature → Logout / Close
                                       └──────────→ ReleaseDevice (explicit device unlink only)

Durante la ejecución de la aplicación debe mantenerse el mismo objeto cliente para que el SDK gestione correctamente los heartbeats y los puestos flotantes. El cierre normal conserva la vinculación del dispositivo; el cierre de sesión explícito del cliente y el punto de entrada compatible ReleaseDevice llaman al mismo procedimiento de cierre de sesión del SDK oficial.

Instalación y punto de entrada de inicialización

Todas las verificaciones de instalación pública de los nueve lenguajes de la versión 0.1.6 se han superado (9/9); todos los métodos de instalación de la tabla siguiente están verificados. La versión de GitHub también ofrece paquetes nativos y archivos sin conexión; consulte su uso en las instrucciones de instalación de paquetes descargados.

El código fuente público y los README de cada lenguaje están en el repositorio del SDK de Launch; los paquetes nativos y archivos sin conexión, en la versión v0.1.6; y los resultados de instalación pública, en la verificación de los registros de los nueve lenguajes. El README de cada paquete proporciona los comandos de instalación y las API. El paquete JavaScript incluye declaraciones TypeScript. El gestor de paquetes resuelve las dependencias habituales de cada lenguaje, como cryptography de Python, BouncyCastle de C# y base64 de Ruby; no es necesario instalar el paquete del SDK oficial.

El módulo público de Go se llama github.com/spf86/licentivo-launch-sdk y la ruta de importación es github.com/spf86/licentivo-launch-sdk/pkg/launchclient; la aplicación no necesita un replace local. El paquete nativo de Windows usa amd64 GNU/MinGW y también hay un paquete nativo de Linux amd64. Los paquetes de Ruby por plataforma y la distribución de Windows Rust/native incluyen curl; la compilación desde el código fuente en otras plataformas requiere las dependencias de desarrollo habituales de C11 y curl/OpenSSL. Consulte las instrucciones de las herramientas de cada plataforma en el README de cada paquete.

Inicio de sesión y operaciones protegidas

Los fragmentos siguientes usan la función de conexión copiada en el paso anterior. email y password proceden de su interfaz de inicio de sesión; no escriba contraseñas en el código fuente ni en la configuración. export debe sustituirse por el nombre de una función que exista realmente en la política del plan.

Go

app, err := connectLaunch()
if err != nil { return err }
defer app.Close()
if _, err := app.Login(ctx, email, password); err != nil { return err }
return app.RunFeature("export", func() error {
    return exportReport()
})

ctx usa el contexto del ciclo de vida de la aplicación; no deben cancelarse los heartbeats inmediatamente al terminar la solicitud de inicio de sesión. Ejecute las operaciones de red en un hilo de trabajo en segundo plano. Para recuperar, llame a Restore(ctx); para cerrar la sesión de la cuenta, a Logout(ctx); para liberar el dispositivo, a ReleaseDevice(ctx).

Python

with connect_launch() as app:
    app.login(email, password)
    result = app.run_feature("export", export_report)

restore() recupera una sesión segura existente; si no hay sesión, muestre la interfaz de inicio de sesión. logout() limpia la cuenta; release_device() libera explícitamente el dispositivo. No permita que las operaciones de red síncronas bloqueen el bucle de eventos de la aplicación de escritorio.

C# / .NET

await using var app = LaunchConnection.Open();
await app.Login(email, password);
await app.RunFeature("export", async () => {
    await ExportReport();
});

Use await Restore(), await Logout() y await ReleaseDevice(). Mantenga activo el ciclo de vida del SDK mientras se ejecuta la aplicación y use procedimientos de interfaz asíncronos.

Java

try (var app = LaunchConnection.open()) {
    app.login(email, passwordChars);
    app.runFeature("export", () -> exportReport());
}

La contraseña usa char[]. Si no hay sesión, restore() devuelve el error NO_SESSION y debe mostrarse la interfaz de inicio de sesión; los demás errores no pueden considerarse una autorización. logout() y releaseDevice() son operaciones distintas. try-with-resources se encarga del cierre.

JavaScript / Node.js / TypeScript

const app = connectLaunch();
try {
  await app.login(email, password);
  const result = await app.runFeature('export', () => exportReport());
} finally {
  await app.close();
}

restore() devuelve null cuando no hay sesión; las operaciones de negocio solo se permiten después de una recuperación correcta. El valor booleano devuelto por logout() indica si se ha confirmado el cierre de sesión remoto; si falla la liberación del dispositivo, debe mostrarse un error. El código se ejecuta en Node.js, el proceso principal de Electron o un backend de confianza; el navegador y el proceso de renderizado de Electron no guardan credenciales de autorización.

Rust

let mut app = connect_launch()?;
app.login(&email, &password)?;
let result = app.run_feature("export", || {
    export_report()?;
    Ok(())
})?;
app.close();

El callback devuelve Result<T, Failure>. restore(), logout() y release_device() devuelven resultados y los errores deben gestionarse. Drop también cierra el entorno de ejecución. Por defecto, build.rs compila y enlaza el núcleo nativo; no es necesario enlazar el SDK oficial manualmente.

Ruby

app = connect_launch
begin
  app.login(email, password)
  result = app.run_feature('export') { export_report }
ensure
  app.close
end

restore recupera la sesión, logout cierra la sesión de la cuenta y release_device libera el dispositivo. Use un bloque de código para las operaciones protegidas; las excepciones no deben convertirse en resultados correctos.

C

static int export_action(void *context) {
    return export_report(context); /* Return 1 only on success. */
}

launch_application *app = connect_launch();
if (!app) return 0;
int ok = launch_application_login(app, email, password);
if (ok) ok = launch_application_run_feature(app, "export", export_action, context);
/* Check launch_application_error(app) on failure; never log credentials. */
launch_application_close(app);
return ok;

launch_application_restore tiene tres estados: 1 recuperado, 0 sin sesión y -1 error. Solo la ausencia de sesión debe mostrar normalmente el inicio de sesión; un rechazo o una excepción no deben considerarse un éxito. También deben comprobarse los valores devueltos por logout y release_device.

CMake solo importa Launch:

find_package(LicentivoLaunch CONFIG REQUIRED)
add_executable(myapp main.c)
licentivo_launch_link(myapp)

C++

auto app = connectLaunch();
app.Login(email.c_str(), password.c_str());
app.RunFeature("export", [&] { exportReport(); });

Restore(), Logout() y ReleaseDevice() siguen la semántica de excepciones de C++. El destructor RAII se encarga del cierre. CMake usa licentivo_launch_link(myapp CXX); Launch gestiona automáticamente el enlace del SDK y las bibliotecas de ejecución incluidas en el paquete de distribución.

Ciclo de vida, almacenamiento seguro y errores

Crear un objeto de conexión solo completa la inicialización. El programa debe iniciar sesión o recuperar la sesión correctamente y usar un callback de protección de funciones en cada operación de negocio. Un pedido pagado, una sesión existente o un botón habilitado no sustituyen la verificación del SDK.

Por defecto, las sesiones solo se guardan en memoria. Recordar el inicio de sesión requiere almacenamiento seguro: Go, Python, C# y C/C++ nativos ofrecen DPAPI del usuario actual de Windows; Java, Node, Rust y Ruby ofrecen almacenamiento AES-GCM con una clave del llamante. Las aplicaciones multiplataforma deben integrarse con el almacén de credenciales del sistema. No guarde la clave y el texto cifrado en el mismo directorio normal.

El cierre normal conserva las sesiones que el usuario ha elegido recordar y detiene el entorno de ejecución. El cierre de sesión de la cuenta llama primero al cierre de sesión unificado del SDK oficial y limpia después los registros propios de la cuenta de Launch. ReleaseDevice es un punto de entrada compatible del mismo procedimiento; si la revocación remota sigue pendiente, no debe indicarse que la liberación ha terminado correctamente. No limpie el directorio de caché del SDK oficial ni sus registros de recuperación del cierre de sesión. La protección de sesiones de Launch no implica que todos los archivos de dispositivos del SDK oficial estén cifrados; deben limitarse los permisos del directorio de caché.

Las respuestas explícitas 401/403/404, la cuenta incorrecta, la cancelación o los límites de frecuencia no deben convertirse en autorizaciones sin conexión correctas. La primera activación y las políticas que prohíben el uso sin conexión siguen necesitando red. Si no se puede acceder al dominio/IP del servidor, debe mostrarse un problema de conexión; no se debe conectar a otros sitios sin aviso.

Pruebas de aceptación y referencias

Verifique el inicio de sesión real, la autorización de la cuenta correspondiente, las operaciones protegidas, la recuperación tras reiniciar, la autorización sin conexión válida y su vencimiento, la manipulación de la caché, el cierre de sesión, el cambio de cuenta y la liberación de dispositivos. Este documento no requiere usar IA. Consulte las herramientas de prueba y los límites de aceptación externa en acceptance.md; los paquetes locales y las instrucciones de compilación están en integration-packages.md.

Las comprobaciones de configuración, la generación de código y las pruebas locales no demuestran automáticamente que los pagos reales, la emisión de autorizaciones o la activación en el sitio oficial hayan terminado correctamente. Las tiendas externas y las sandbox de pago deben configurarse y someterse a aceptación por separado.