Anwendungsintegration mit Launch und Licentivo

Diese Anleitung gilt für den Licentivo-Anbieter. Um ein händlereigenes Lizenzsystem ohne Licentivo anzubinden, benutzerdefinierte Lizenzierungs-API und Integrationsablauf verwenden, custom_http für Produkt/Umgebung wählen und das Laufzeit-SDK dieses Systems beibehalten.

Diese lokalen, unveröffentlichten Änderungen verwenden Kontoidentitätsaustausch. Siehe Vertrag zu Zuständigkeiten und Kaufsynchronisierung für Migration und serverseitigen Sitzungswiderruf. Paketversionsnummern wurden durch diese Änderung weder veröffentlicht noch erhöht.

Launch ist für Händlerkonten, Bestellungen, Preise, Verlängerungs-/Upgrade-Angebote, Erstattungen und absolute Kaufdaten zuständig. Licentivo ist für Lizenzen, Richtlinien, Gerätekontingente, Autorisierungssitzungen, signierte Berechtigungen und Laufzeitentscheidungen zuständig. Eine erfolgreiche Launch-Anmeldung oder ein synchronisierter Kauf ist niemals eine Berechtigung zur Ausführung geschützter Arbeit.

Die Integrationsseite der Administration verwenden, um den direkten Verbindungsaufruf und angeheftete öffentliche Produktschlüssel zu erhalten. Alle neun Sprach-Wrapper enthalten das offizielle SDK. Händler-Management- und Zahlungsschlüssel bleiben auf dem Server. Öffentliche Produkteinstellungen enthalten keine Kundenzugangsdaten, Geräte-IDs, Cache-Pfade oder Identitäts-Assertions.

Kontoaustausch

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

Der Wrapper fordert POST /api/v1/software/products/{id}/identity mit {"environment":"sandbox"} oder live an. Die zurückgegebene Identitäts-Assertion gilt höchstens 120 Sekunden und ist an einen registrierten Aussteller, Empfänger, eine echte Anmeldesitzung, Produkt, Umgebung und Kaufreferenz gebunden. Sie enthält keine Funktionsberechtigungen, Gerätekontingente oder Offline-Richtlinie.

Das offizielle SDK erhält diese Werte im Speicher:

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

Diese Laufzeitkonfiguration nicht in eine öffentliche Datei schreiben und ihre Assertion nicht in einem Kontodatensatz speichern. Gemerkte Launch-v2-Datensätze speichern nur die Kontositzung und den öffentlichen Routingkontext. Der alte Kundenendpunkt /credential gibt HTTP 410 zurück.

Lebenszyklus und Speicherung

• Login: Konto authentifizieren, frische Assertion anfordern, offizielles SDK starten.
• Restore: Gemerktes Konto online bestätigen, frische Assertion anfordern, offizielles SDK starten. Ein Launch-Ausfall wählt keine Offline-Berechtigung.
• RunFeature: Jede geschützte Ausführung an das offizielle SDK delegieren. Ein abgelehnter Callback darf niemals ausgeführt werden.
• Close / Dispose / Drop: Hintergrundarbeit stoppen, ausdrücklich gemerkte Anmeldung und Knotenbindung behalten.
• Logout: Einheitlichen Logout des offiziellen SDK aufrufen, anschließend den Launch-Kontodatensatz löschen und seine Kontositzung beenden.
• ReleaseDevice: Kompatibilitätsalias für ausdrücklichen Logout. Ausstehenden Remote-Widerruf wahrheitsgemäß melden.

Nur das offizielle SDK entfernt seine Gerätezugangsdaten und Lease-Dateien. Niemals sein Cache-Verzeichnis oder .logout.json löschen: Dieses Journal enthält eingeschränkte Freigabetickets, die nach fehlgeschlagenen Netzwerkanfragen benötigt werden. Das SDK setzt ausstehende Tickets fort, wenn der passende Cache erneut initialisiert wird. Launch-Kontospeicher und SDK-Speicher haben getrennte Eigentümer.

Anwendungen mit Bedarf an Offline-Start verwenden den dokumentierten Wiederherstellungsablauf des offiziellen SDK. Nur das SDK prüft signierte Berechtigung, Produkt-/Umgebungskontext, Ablauf, Uhrverhalten und Gerätezustand. Launch-Wrapper leiten keine Berechtigung aus Kaufdaten, einer lokalen Bestellung oder dem Vorhandensein einer Datei ab.

Nur im Speicher gehaltene Kontositzungen sind der Standard. Persistente Kontospeicher müssen ihre Datensätze verschlüsseln und authentifizieren und ihre Schlüssel mit den Zugangsdatenfunktionen des Betriebssystems schützen. Je Händler, Konto, Produkt und Umgebung einen separaten beschreibbaren Cache verwenden. Browser-Renderer müssen Geschäftsergebnisse statt Desktop-Kontotoken, Assertions oder Gerätezugangsdaten erhalten.

Käufe und Geräte

Launch berechnet absolute Kaufdaten aus verifizierten Zahlungen und unveränderlicher Bestellabdeckung und sendet anschließend versionierte Snapshots an /api/v1/launch/connections/{id}/events. Es fragt das Ereignis bis applied ab; der Empfang allein ist keine Erfüllung. Wiederholungen von Verlängerungen und Erstattungen können die Dauer nicht ein zweites Mal hinzufügen. Erstattungen entfernen nur die Abdeckung der jeweiligen Bestellung; ein vollständig erstatteter Kauf erhält beim erneuten Kauf eine neue Referenz.

Benutzer ohne Zugriff auf ein Gerät können die Geräteverwaltungsseite von Launch öffnen. Listen, verbleibende Freigaben, erlaubte Aktionen und Operationsergebnisse stammen von Licentivo. Eine Freigabe enthält die angezeigte Bindungsgeneration und eine unveränderte Operations-ID. Launch unterhält keinen konkurrierenden Freigabezähler oder Auftragsausführer.

Prüfung und Einschränkungen

Kontoaustausch, kurzlebige Assertion-Speicherung, SDK-gesteuerte Funktionsausführung, normales Schließen, ausdrücklichen Logout aus einem neuen Prozess, Journale ausstehender Freigaben und Produkt-/Umgebungsisolierung testen. Die echten signierten Leases des offiziellen SDK, Offline-Prüfungen und Manipulationsablehnung getrennt vom Launch-Kontotransport testen. Kompilierung und Fixtures belegen keine Produktionsabnahme.

Launch verwendet außerdem die session-revocations-POST- und Beleg-GET-Endpunkte von Licentivo V39 für Desktop-Logout, erzwungenen Sitzungs-Logout, Passwortänderungen und Kontodeaktivierung. Es fixiert ursprüngliche Empfänger und Anfrage dauerhaft, stellt verlorene Antworten wieder her und bestätigt jede Umgebung unabhängig. Ausstehende kontoweite Benachrichtigungen pausieren neue Desktop-Authentifizierung; nach Bestätigung muss eine tatsächlich neue Anmeldung eine auth_time strikt nach der neuesten revoked_before-Sekunde haben. Website-Wiederherstellung bleibt verfügbar. Diese Benachrichtigungen ändern niemals Kaufdaten. Siehe Grenz- und Wiederherstellungsvertrag.

Siehe manuelle Integration, KI-Integration, Integrationspakete und Abnahme.