Integrazione delle applicazioni con Launch e Licentivo

Questa guida si applica al fornitore Licentivo. Per collegare un sistema di licenze del commerciante senza Licentivo, usare le API e la procedura di integrazione delle licenze personalizzate, selezionare custom_http per il prodotto/ambiente e mantenere l'SDK di esecuzione di quel sistema.

Queste modifiche locali non pubblicate usano lo scambio dell'identità dell'account. Consultare il contratto sulle responsabilità e sulla sincronizzazione degli acquisti per la migrazione e la revoca delle sessioni sul server. Questa modifica non ha pubblicato né aggiornato i numeri di versione dei pacchetti.

Launch gestisce gli account del commerciante, gli ordini, i prezzi, i preventivi di rinnovo/upgrade, i rimborsi e le date assolute degli acquisti. Licentivo gestisce le licenze, le politiche, le quote dei dispositivi, le sessioni di autorizzazione, i permessi firmati e le decisioni in fase di esecuzione. Un accesso Launch riuscito o un acquisto sincronizzato non costituiscono mai un permesso di eseguire operazioni protette.

Usare la pagina amministrativa di integrazione per ottenere la chiamata di connessione diretta e le chiavi pubbliche fissate del prodotto. Tutti i wrapper dei nove linguaggi contengono l'SDK ufficiale. Le chiavi amministrative del commerciante e quelle di pagamento rimangono sul server. Le impostazioni pubbliche del prodotto non contengono credenziali dei clienti, ID dei dispositivi, percorsi della cache o attestazioni di identità.

Scambio dell'account

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

Il wrapper richiede POST /api/v1/software/products/{id}/identity con {"environment":"sandbox"} oppure live. L'attestazione di identità restituita dura al massimo 120 secondi ed è vincolata a emittente registrato, destinatario, sessione di accesso reale, prodotto, ambiente e riferimento di acquisto. Non contiene autorizzazioni di funzionalità, quote dei dispositivi o politiche offline.

L'SDK ufficiale riceve questi valori in 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": ""
}

Non scrivere questa configurazione di esecuzione in un file pubblico e non conservare in modo persistente la sua attestazione in un record dell'account. I record di accesso ricordato Launch v2 memorizzano soltanto la sessione dell'account e il contesto pubblico di instradamento. Il vecchio endpoint cliente /credential restituisce HTTP 410.

Ciclo di vita e archiviazione

• Login: autentica l'account, richiede una nuova attestazione, avvia l'SDK ufficiale.
• Restore: conferma online l'account ricordato, richiede una nuova attestazione, avvia l'SDK ufficiale. Un'interruzione di Launch non determina un permesso offline.
• RunFeature: delega ogni esecuzione protetta all'SDK ufficiale. Un callback rifiutato non deve mai essere eseguito.
• Close / Dispose / Drop: interrompono le attività in background, conservano l'accesso ricordato intenzionalmente e l'associazione del dispositivo.
• Logout: invoca la disconnessione unificata dell'SDK ufficiale, quindi elimina il record dell'account Launch e termina la relativa sessione dell'account.
• ReleaseDevice: alias compatibile della disconnessione esplicita. Segnalare correttamente la revoca remota in sospeso.

Soltanto l'SDK ufficiale rimuove la propria credenziale del dispositivo e i file dei lease. Non eliminare mai la sua directory della cache o .logout.json: quel registro contiene i ticket di rilascio limitati necessari dopo le richieste di rete fallite. L'SDK riprende i ticket in sospeso quando la cache corrispondente viene inizializzata nuovamente. L'archivio degli account di Launch e l'archivio dell'SDK hanno responsabili distinti.

Le applicazioni che richiedono l'avvio offline usano la procedura di ripristino documentata dell'SDK ufficiale. Solo l'SDK verifica il permesso firmato, il contesto di prodotto/ambiente, la scadenza, il comportamento dell'orologio e lo stato del dispositivo. I wrapper Launch non deducono il permesso dalle date degli acquisti, da un ordine locale o dalla presenza di un file.

Le sessioni degli account conservate soltanto in memoria sono l'impostazione predefinita. Gli archivi persistenti degli account devono cifrare/autenticare i propri record e proteggere le chiavi con le funzionalità per le credenziali del sistema operativo. Usare una cache scrivibile separata per commerciante, account, prodotto e ambiente. I processi di rendering dei browser devono ricevere risultati applicativi anziché token di account desktop, attestazioni o credenziali dei dispositivi.

Acquisti e dispositivi

Launch calcola le date assolute degli acquisti dai pagamenti verificati e dalla copertura immutabile degli ordini, quindi invia istantanee con versione a /api/v1/launch/connections/{id}/events. Consulta periodicamente l'evento fino a applied; la sola ricezione non equivale all'evasione. I tentativi successivi di rinnovo e rimborso non possono aggiungere la durata una seconda volta. I rimborsi rimuovono soltanto la copertura dell'ordine pertinente; un acquisto interamente rimborsato viene sostituito da un nuovo riferimento in caso di riacquisto.

Gli utenti che non hanno accesso a un dispositivo possono aprire la pagina di gestione dei dispositivi di Launch. Gli elenchi, i rilasci rimanenti, le azioni consentite e i risultati delle operazioni provengono da Licentivo. Un rilascio include la generazione dell'associazione visualizzata e un ID operazione invariato. Launch non mantiene un contatore di rilasci o un esecutore di attività concorrente.

Verifica e limitazioni

Testare lo scambio dell'account, l'archiviazione temporanea delle attestazioni, l'esecuzione delle funzionalità controllata dall'SDK, la chiusura ordinaria, la disconnessione esplicita da un nuovo processo, i registri dei rilasci in sospeso e l'isolamento di prodotto/ambiente. Testare i lease firmati reali dell'SDK ufficiale, i controlli offline e il rifiuto delle manomissioni separatamente dal trasporto degli account Launch. La compilazione e le fixture non dimostrano il superamento del collaudo in produzione.

Launch usa inoltre gli endpoint POST session-revocations e GET delle ricevute di Licentivo V39 per la disconnessione desktop, la disconnessione forzata delle sessioni, le modifiche delle password e la disattivazione degli account. Congela in modo persistente i destinatari e la richiesta originali, recupera le risposte perse e conferma ogni ambiente indipendentemente. Le notifiche in sospeso a livello di account sospendono le nuove autenticazioni desktop; dopo la conferma, un accesso effettivamente nuovo deve avere auth_time strettamente successivo all'ultimo secondo revoked_before. Il ripristino tramite il sito rimane disponibile. Queste notifiche non modificano mai le date degli acquisti. Consultare il contratto sui limiti e sul ripristino.

Consultare Integrazione manuale, Integrazione con IA, Pacchetti di integrazione e Collaudo.