Launch: durata degli acquisti e limiti degli SDK account

Questa modifica viene sviluppata e verificata soltanto in locale; Launch non è stato distribuito e i pacchetti SDK non sono stati pubblicati. Il codice sorgente attuale dipende dal protocollo di autorizzazione degli account Licentivo e dai relativi aggiornamenti dell'SDK ufficiale; non può essere usato insieme ai vecchi server che supportano soltanto chiavi di licenza a lungo termine.

Responsabilità

Gli ordini, le durate degli acquisti e gli indicatori di sincronizzazione completata di Launch non possono consentire l'accesso alle funzionalità protette. Il client deve eseguire le operazioni applicative protette tramite le interfacce di esecuzione dell'SDK ufficiale, come RunFeature.

Ogni prodotto Launch conserva una rotta pubblica stabile verso un prodotto Licentivo. I piani dello stesso prodotto possono scegliere politiche diverse, ma non possono passare a un altro prodotto remoto; il salvataggio delle mappature viene convalidato in modo serializzato tramite il blocco della riga del prodotto comune nel database. L'identità del cliente, la pubblicazione dei piani e la configurazione di integrazione SDK leggono la stessa associazione; le bozze non possono cambiare il contesto del prodotto dei clienti che hanno acquistato. Questo verifica soltanto la coerenza della configurazione di integrazione, senza decidere le autorizzazioni delle funzionalità o dei dispositivi. Se un vecchio database non contiene i campi stabili, si dà priorità alla cronologia di acquisti e pubblicazioni; quando non è possibile determinare un'unica corrispondenza, viene restituito PRODUCT_MAPPING_CONFLICT. Per i dettagli, consultare la correzione della concorrenza delle mappature.

Sincronizzazione della durata degli acquisti

Riutilizza le interfacce esistenti, senza introdurre nuovi fatti di pagamento, fatti di rimborso o servizi di preventivazione:

• POST /api/v1/launch/connections, PUT /connections/{id}: registrano le chiavi pubbliche di firma dell'identità; gli ambienti di produzione e test stabiliscono connessioni separate.
• PUT /api/v1/launch/connections/{id}/plans/{plan}: registra un riferimento univoco alla versione del piano Launch e le versioni del prodotto e della politica remoti.
• POST /api/v1/launch/connections/{id}/events: invia un'istantanea completa e con versione dell'acquisto.
• GET /api/v1/launch/connections/{id}/events/{event}: conferma il risultato dell'elaborazione.
• POST /api/v1/launch/connections/{id}/events/{event}/retry: riprova l'evento originale dopo la verifica.

L'istantanea contiene soltanto l'identificativo dell'evento, l'ambiente, il tipo di evento, il riferimento dell'acquisto, il riferimento anonimo dell'account, il prodotto Launch, il riferimento della versione del piano, la versione crescente e i valori assoluti valid_from / valid_until; durante la migrazione viene aggiunto l'ID della vecchia licenza. Non vengono inviati chiavi di pagamento, prezzi, email dei clienti o chiavi di licenza a lungo termine. Per gli acquisti permanenti, valid_until è null; Licentivo verifica la corrispondenza con la politica.

Launch conferma il pagamento, registra gli intervalli immutabili di copertura degli acquisti e salva le attività di sincronizzazione nella stessa transazione del database. La scadenza viene calcolata secondo cicli di calendario giornalieri/mensili/annuali; i rinnovi mantengono l'ancoraggio dell'acquisto originale, mentre un pagamento effettuato dopo la scadenza decorre dall'orario effettivo del pagamento. I preventivi di upgrade e le durate continuano a essere calcolati in Launch.

Ogni modifica invia i valori assoluti completi; i tentativi successivi usano lo stesso ID evento e lo stesso corpo, senza inviare «aggiungi altri N giorni». L'attività salva in modo persistente la richiesta, la connessione remota e l'avanzamento dell'elaborazione; risposte perse, riavvii del processo e worker concorrenti non accumulano nuovamente la durata.

HTTP 202 indica soltanto che Licentivo ha ricevuto la richiesta. La sincronizzazione viene contrassegnata come completata soltanto dopo aver ricevuto applied; con pending si continua la consultazione, mentre manual_review e stale non confermati rimangono in attesa di verifica. Gli errori di rete vengono ritentati con attese progressive; raggiunto il limite di errori consecutivi, si passa alla verifica manuale.

Un rimborso rimuove soltanto l'intervallo di copertura dell'ordine corrispondente: il rimborso di un upgrade ripristina il piano di base; il rimborso di un rinnovo rimuove la relativa estensione. Se restano acquisti non rimborsati, viene sincronizzato il risultato ricalcolato senza revocare tutti gli acquisti. Dopo il rimborso di tutti gli acquisti viene inviato entitlement.refunded. Un acquisto successivo usa un nuovo riferimento di acquisto per impedire la riattivazione di licenze remote revocate.

Anche le contestazioni perse o gli storni confermati dal canale rimuovono soltanto la copertura dell'ordine corrispondente. L'ordine viene mostrato come reversed; le modifiche effettive all'autorizzazione vengono comunque elaborate da Licentivo dopo l'applicazione dell'istantanea dell'acquisto. Le controversie in sospeso non modificano il record dell'acquisto. Le notifiche storiche di storno in attesa di verifica possono essere recuperate verificandone nuovamente la firma e reinviandole tramite il canale originale.

Dopo che un rimborso dall'esito sconosciuto è passato alla verifica manuale, l'amministratore può ripristinare l'operazione originale tramite POST /api/v1/admin/refunds/{id}/reconcile. La ricevuta deve corrispondere alla transazione, alla valuta e all'importo originali; l'identificativo dell'operazione e l'orario di approvazione originali non devono essere modificati. Oltre la finestra di ritentativo sicura, le richieste di trasferimento di fondi non devono essere reinviate alla cieca.

Account e client

1. Il client usa POST /api/v1/auth/login per stabilire una sessione reale di accesso desktop.
2. L'SDK Launch richiede POST /api/v1/software/products/{id}/identity, specificando sandbox o live.
3. Launch emette un'attestazione di identità valida al massimo 120 secondi, con destinatario e contesto di prodotto/acquisto specificati; include il vero sid di accesso e la scadenza dell'accesso. L'attestazione non contiene funzionalità, quote dei dispositivi o permessi offline.
4. L'SDK Launch passa all'SDK ufficiale identity_token, launch_connection_id e environment soltanto in memoria; license_key è vuoto.
5. L'SDK ufficiale chiama /api/v1/launch/exchange di Licentivo; Licentivo decide l'autorizzazione e rilascia le credenziali del dispositivo e l'autorizzazione firmata.

I normali record degli account Launch usano v2 e conservano soltanto la sessione dell'account e le informazioni pubbliche di instradamento, senza attestazioni, chiavi di licenza o autorizzazioni. Alla disconnessione esplicita diventano attività private v3 riservate alla revoca, che non possono ripristinare l'accesso; vengono eliminate soltanto dopo la conferma della revoca della sessione Launch. La vecchia interfaccia /credential restituisce HTTP 410. Le chiavi pubbliche e gli ID dei prodotti possono essere distribuiti con l'applicazione; le chiavi amministrative rimangono soltanto sul server.

Disconnessione, chiusura e scollegamento remoto

La disconnessione dell'SDK ufficiale interrompe immediatamente l'uso dell'autorizzazione da parte di questo processo, elimina le sue credenziali di esecuzione e revoca l'associazione remota usando un ticket di disconnessione dedicato. In caso di errore di rete, il file .logout.json dell'SDK deve essere conservato e il risultato deve indicare che la revoca remota è in sospeso, senza segnalare lo scollegamento come riuscito. L'SDK Launch non elimina, scorre per pulire né modifica la directory della cache dell'SDK ufficiale; i ticket di revoca in sospeso vengono recuperati ed elaborati dall'SDK ufficiale alla successiva inizializzazione della cache corrispondente.

Anche la disconnessione dell'account Launch ha uno stato indipendente in sospeso: in caso di errore di rete, annullamento o risposta persa, i record di sicurezza necessari per riprovare non vengono eliminati. Un nuovo accesso, ripristino o tentativo di disconnessione reinvia soltanto la revoca della sessione originale; l'attività in sospeso non può ripristinare l'accesso. Viene eliminata dopo il successo o dopo che HTTP 401 ha confermato l'invalidità della sessione. Il ripristino tra processi richiede uno Store sicuro persistente; MemoryStore è valido soltanto nel processo corrente. Per i dettagli, consultare la correzione dei tentativi di disconnessione e i test di integrazione.

Le richieste di scollegamento remoto includono activation_id e expected_generation restituiti dall'elenco originale; i tentativi successivi riutilizzano operation_id. Launch non calcola il numero di scollegamenti, non approva né esegue autonomamente la coda di scollegamento e non aggiorna la generazione per riprovare automaticamente una vecchia operazione. Il numero rimanente, il permesso di rilascio, la revisione e il risultato finale provengono tutti da Licentivo.

Il ripristino dell'account Restore richiede la rete per confermare l'account e ottenere una nuova attestazione di identità; Launch non decide autonomamente di consentire l'accesso offline se il servizio account non funziona. Le applicazioni che richiedono l'avvio offline devono integrarsi secondo il contratto di ripristino dell'SDK ufficiale; firma, durata offline e controlli dell'orologio rimangono responsabilità dell'SDK ufficiale.

Revoca dell'identità sul server

Integrazione con le interfacce esistenti di Licentivo V39, senza necessità di interfacce per fatti commerciali o preventivi:

• POST /api/v1/launch/connections/{id}/session-revocations: revoca i vecchi accessi dello sid o dell'account specificato e restituisce una ricevuta confermata in modo sincrono.
• GET /api/v1/launch/connections/{id}/session-revocations/{event_id}: recupera il risultato confermato dell'evento originale e ripristina le richieste la cui risposta è stata persa.

La disconnessione desktop ordinaria e la disconnessione forzata di una sessione specifica usano scope=session; l'invalidazione di tutte le sessioni dovuta a modifica o reimpostazione della password, modifica dell'email, disattivazione dell'account o modifica del ruolo del personale del sito usa scope=account. La disconnessione ordinaria di una sessione del sito non influisce sul software del cliente. Launch notifica soltanto che l'identità non è più valida; Licentivo gestisce le sessioni di autorizzazione remote, le credenziali di esecuzione e il rilascio dei dispositivi, senza modificare la durata degli acquisti né consumare la quota di scollegamento mantenuta da Launch.

L'invalidazione della sessione locale e l'accodamento della notifica avvengono nella stessa transazione. La coda congela le connessioni e gli ambienti esistenti in quel momento e riprova usando lo stesso ID evento, l'identificativo anonimo dell'account e la richiesta originale; le connessioni create successivamente non ricevono le revoche storiche degli account. Viene consultata prima la ricevuta originale e la richiesta viene reinviata soltanto dopo averne confermato l'assenza. I risultati vengono salvati in modo persistente per ciascun ambiente e il completamento viene mostrato soltanto dopo che tutti hanno restituito ricevute di successo corrispondenti. Le disconnessioni di rete comportano tentativi automatici; i conflitti di credenziali/contratto passano alla verifica manuale. Gli amministratori possono visualizzare le notifiche e riprovare nella pagina delle attività di sincronizzazione; i nuovi tentativi non generano nuovi eventi di revoca.

Le revoche a livello di account usano come limite revoked_before della prima accettazione da parte di Licentivo. Mentre la notifica è in sospeso, i nuovi accessi desktop e le attestazioni di identità vengono sospesi. Dopo il completamento, auth_time dell'accesso reale deve essere strettamente successivo al secondo di scadenza presente nelle ricevute di tutti gli ambienti. Gli accessi avvenuti nello stesso secondo possono autenticarsi nuovamente in seguito; aggiornare iat o l'attestazione di identità non consente di prolungare un vecchio accesso. L'accesso al sito rimane disponibile per le operazioni di ripristino. Anche dopo la riattivazione di un account è necessario accedere nuovamente; le vecchie sessioni non vengono ripristinate.

Migrazione dei dati legacy

Gli acquisti con un'associazione a una vecchia licenza già confermata usano entitlement.migrated e inviano soltanto l'ID della vecchia licenza, senza leggere o distribuire le vecchie chiavi. Dopo che Licentivo ha confermato la migrazione, viene inviata un'istantanea separata con una nuova versione per sincronizzare la durata e lo stato commerciali correnti. I risultati dei vecchi rilasci non confermati e le autorizzazioni incompatibili richiedono una verifica manuale; i vecchi comandi amministrativi non vengono riprodotti automaticamente.

La disconnessione ordinaria dell'SDK, lo scollegamento remoto dei dispositivi e la revoca dell'identità sul server usano tutti le interfacce esistenti. La disattivazione remota rimane soggetta alla durata delle autorizzazioni offline già emesse dall'SDK ufficiale; Launch non garantisce che i dispositivi offline ricevano una revoca immediata.

La disconnessione dell'account usa attività di sicurezza indipendenti, riepiloghi locali della disconnessione delle sessioni e coordinamento tra processi; le vecchie istanze gestiscono soltanto i propri accessi. Dopo un errore di archiviazione, il ripristino reinvia prima la revoca dell'account, senza ottenere un'identità né avviare l'autorizzazione. Le funzionalità, le autorizzazioni offline, le generazioni dei dispositivi e le quote di scollegamento continuano a essere determinate da Licentivo. Per i dettagli, consultare il resoconto della correzione e dei test di integrazione sui due lati.