Launch-Kauflaufzeit und Grenzen des Konto-SDK

Diese Änderung wurde nur lokal entwickelt und geprüft; Launch wurde nicht bereitgestellt und kein SDK-Paket veröffentlicht. Der aktuelle Quellcode hängt vom Kontoautorisierungsprotokoll von Licentivo und den zugehörigen offiziellen SDK-Aktualisierungen ab und darf nicht mit alten Servern gemischt werden, die nur langfristige Lizenzschlüssel unterstützen.

Zuständigkeiten

Launch-Bestellungen, Kaufzeiträume und Synchronisierungsabschlussmarkierungen dürfen geschützte Funktionen nicht freigeben. Der Client muss geschützte Geschäftsvorgänge über Laufzeitschnittstellen wie RunFeature des offiziellen SDK ausführen.

Jedes Launch-Produkt speichert eine stabile öffentliche Licentivo-Produktroute. Pläne desselben Produkts können unterschiedliche Richtlinien wählen, aber nicht zu einem anderen entfernten Produkt wechseln; das Speichern von Zuordnungen wird über eine Datenbankzeilensperre des gemeinsamen Produkts seriell geprüft. Kundenidentität, Planveröffentlichung und SDK-Integrationskonfiguration lesen dieselbe Bindung; Entwürfe können den Produktkontext bestehender Käufer nicht ändern. Dies prüft nur die Konsistenz der Integrationskonfiguration und entscheidet nicht über Funktions- oder Geräteautorisierung. Fehlt das stabile Feld in einer alten Datenbank, werden Kauf- und Veröffentlichungshistorie bevorzugt herangezogen; ist keine eindeutige Bestätigung möglich, wird PRODUCT_MAPPING_CONFLICT zurückgegeben, siehe Korrektur der Zuordnungs-Nebenläufigkeit.

Synchronisierung des Kaufzeitraums

Bestehende Schnittstellen wiederverwenden, keine neuen Zahlungsfakten, Erstattungsfakten oder Angebotsdienste hinzufügen:

• POST /api/v1/launch/connections、PUT /connections/{id}: Öffentliche Identitätssignaturschlüssel registrieren; für Produktions- und Testumgebung getrennte Verbindungen erstellen.
• PUT /api/v1/launch/connections/{id}/plans/{plan}: Eindeutige Launch-Planversionsreferenz sowie entferntes Produkt und Richtlinienversion registrieren.
• POST /api/v1/launch/connections/{id}/events: Vollständigen versionierten Kauf-Snapshot übermitteln.
• GET /api/v1/launch/connections/{id}/events/{event}: Verarbeitungsergebnis bestätigen.
• POST /api/v1/launch/connections/{id}/events/{event}/retry: Nach Prüfung das ursprüngliche Ereignis erneut versuchen.

Der Snapshot enthält nur Ereignisnummer, Umgebung, Ereignistyp, Kaufreferenz, anonyme Kontoreferenz, Launch-Produkt, Planversionsreferenz, steigende Version und absolute valid_from / valid_until; bei Migration wird die alte Lizenz-ID hinzugefügt. Zahlungsschlüssel, Preis, Kunden-E-Mail oder langfristiger Lizenzschlüssel werden nicht gesendet. Bei dauerhaftem Kauf ist valid_until gleich null; Licentivo prüft die Übereinstimmung mit der Richtlinie.

Launch bestätigt die Zahlung, erfasst unveränderliche Kaufabdeckungsintervalle und speichert die Synchronisierungsaufgabe in derselben Datenbanktransaktion. Die Frist wird nach Kalenderzyklen in Tagen/Monaten/Jahren berechnet; Verlängerungen verwenden den ursprünglichen Kaufanker, und bei Zahlung erst nach Ablauf beginnt die Laufzeit zum tatsächlichen Zahlungszeitpunkt. Upgrade-Angebot und Laufzeit werden weiterhin in Launch berechnet.

Jede Änderung sendet vollständige absolute Werte; Wiederholungen verwenden dieselbe Ereignis-ID und denselben Body und senden kein „weitere N Tage hinzufügen“. Die Aufgabe speichert Anfrage, Remote-Verbindung und Verarbeitungsfortschritt dauerhaft; verlorene Antworten, Prozessneustarts und gleichzeitige Worker addieren die Laufzeit nicht mehrfach.

HTTP 202 bedeutet nur, dass Licentivo empfangen hat. Erst bei applied wird die Synchronisierung als abgeschlossen markiert; pending wird weiter abgefragt, manual_review und nicht bestätigbares stale bleiben zur Prüfung offen. Netzwerkfehler werden mit Backoff wiederholt; nach Erreichen des Limits aufeinanderfolgender Fehler folgt eine manuelle Prüfung.

Eine Erstattung entfernt nur das Abdeckungsintervall der jeweiligen Bestellung: Die Erstattung einer Upgrade-Bestellung stellt den Basisplan wieder her; die Erstattung einer Verlängerungsbestellung entfernt den entsprechenden Verlängerungsanteil. Wenn nicht erstattete Käufe verbleiben, wird das neu berechnete Ergebnis synchronisiert, ohne alle Käufe zu widerrufen. Nach Erstattung aller Käufe wird entitlement.refunded gesendet. Ein späterer erneuter Kauf verwendet eine neue Kaufreferenz, um eine Wiederbelebung der widerrufenen Remote-Lizenz zu verhindern.

Ein vom Kanal bestätigter verlorener Chargeback oder eine Zahlungsrücknahme entfernt ebenfalls nur die Kaufabdeckung der jeweiligen Bestellung. Die Bestellung wird als reversed angezeigt; die tatsächliche Autorisierungsänderung erfolgt erst, nachdem Licentivo den Kauf-Snapshot angewendet hat. Ein offener Streitfall ändert den Kaufdatensatz nicht. Historische zur Prüfung ausstehende Rücknahmebenachrichtigungen können durch erneute Signaturprüfung und erneutes Senden über den ursprünglichen Kanal wiederhergestellt werden.

Nach Übergang einer unbekannten Erstattung in die manuelle Prüfung kann ein Administrator die ursprüngliche Operation über POST /api/v1/admin/refunds/{id}/reconcile wiederherstellen. Der Beleg muss zur ursprünglichen Transaktion, Währung und zum Betrag passen; ursprüngliche Operationsnummer und Genehmigungszeit dürfen nicht geändert werden. Nach Ablauf des sicheren Wiederholungsfensters dürfen Geldanfragen nicht blind erneut eingereicht werden.

Konto und Client

1. Der Client erstellt mit POST /api/v1/auth/login eine echte Desktop-Anmeldesitzung.
2. Das Launch SDK fordert POST /api/v1/software/products/{id}/identity an und gibt sandbox oder live an.
3. Launch stellt eine Identitäts-Assertion für höchstens 120 Sekunden mit angegebenem Empfänger und Produkt-/Kaufkontext aus; sie enthält die echte Anmelde-sid und den Anmeldeablauf. Die Assertion enthält keine Funktionen, Gerätequoten oder Offline-Berechtigungen.
4. Das Launch SDK übergibt identity_token, launch_connection_id und environment nur im Speicher an das offizielle SDK; license_key ist leer.
5. Das offizielle SDK ruft Licentivo /api/v1/launch/exchange auf; Licentivo entscheidet über die Autorisierung und gibt Gerätezugangsdaten und signierte Berechtigungen aus.

Der normale Launch-Kontodatensatz verwendet v2 und speichert nur Kontositzung und öffentliche Routeninformationen, keine Assertion, Lizenzschlüssel oder Autorisierungslizenz. Beim ausdrücklichen Logout wird er zu einem privaten v3-Auftrag ausschließlich für den Widerruf; daraus kann keine Anmeldung wiederhergestellt werden. Erst nach bestätigtem Widerruf der Launch-Sitzung wird er gelöscht. Die alte Schnittstelle /credential gibt HTTP 410 zurück. Öffentliche Schlüssel und Produkt-ID können mit der Anwendung verteilt werden; der Management-Schlüssel bleibt ausschließlich auf dem Server.

Logout, Schließen und Remote-Entbindung

Der Logout des offiziellen SDK beendet sofort die Nutzung der Autorisierung in diesem Prozess, bereinigt seine Laufzeit-Zugangsdaten und widerruft die Remote-Bindung mit einem speziellen Logout-Ticket. Bei Netzwerkfehlern muss die .logout.json des SDK erhalten bleiben; das Ergebnis muss den ausstehenden Remote-Widerruf anzeigen und darf keine erfolgreiche Entbindung melden. Das Launch SDK löscht, durchsucht oder verändert das Cache-Verzeichnis des offiziellen SDK nicht; das offizielle SDK setzt die Verarbeitung ausstehender Widerrufstickets nach erneuter Initialisierung des entsprechenden Caches fort.

Der Launch-Konto-Logout besitzt ebenfalls einen eigenen ausstehenden Auftrag: Bei Netzwerkfehler, Abbruch oder verlorener Antwort werden die für Wiederholungen benötigten Sicherheitsdaten nicht gelöscht; erneute Anmeldung, Wiederherstellung oder Logout reichen nur den ursprünglichen Sitzungswiderruf nach, und der Auftrag kann nicht zur Wiederherstellung der Anmeldung verwendet werden. Nach Erfolg oder HTTP 401 zur Bestätigung der ungültigen Sitzung wird er gelöscht. Prozessübergreifende Wiederherstellung erfordert einen persistenten sicheren Store; MemoryStore gilt nur im aktuellen Prozess. Siehe Logout-Wiederholungskorrektur und Integrationstest.

Eine Remote-Entbindungsanfrage enthält activation_id und expected_generation aus der ursprünglichen Liste; Wiederholungen verwenden dieselbe operation_id. Launch berechnet keine Entbindungsanzahl, genehmigt oder verarbeitet keine Entbindungswarteschlange selbst und wiederholt alte Operationen nicht automatisch nach Aktualisierung der Generation. Verbleibende Anzahl, Zulässigkeit der Freigabe, Prüfung und Endergebnis stammen alle von Licentivo.

Die Kontowiederherstellung Restore muss online das Konto bestätigen und eine neue Identitäts-Assertion beziehen; Launch entscheidet bei Ausfall des Kontodienstes nicht selbst über Offline-Zugriff. Anwendungen mit Offline-Start integrieren den Wiederherstellungsvertrag des offiziellen SDK; Signatur, Offline-Frist und Uhrprüfung bleiben beim offiziellen SDK.

Serverseitiger Identitätswiderruf

Die vorhandenen Schnittstellen von Licentivo V39 anbinden; Schnittstellen für Geschäftsfakten oder Angebote sind nicht erforderlich:

• POST /api/v1/launch/connections/{id}/session-revocations: Alte Anmeldung einer angegebenen sid oder eines Kontos widerrufen und einen synchron festgeschriebenen Beleg zurückgeben.
• GET /api/v1/launch/connections/{id}/session-revocations/{event_id}: Das festgeschriebene Ergebnis des ursprünglichen Ereignisses abrufen, um eine Anfrage mit verlorener Antwort wiederherzustellen.

Gewöhnlicher Desktop-Logout und erzwungener Logout einer bestimmten Sitzung verwenden scope=session; der Widerruf aller Sitzungen durch Passwortänderung, Passwortreset, E-Mail-Änderung, Kontodeaktivierung und Rollenänderung von Website-Personal verwendet scope=account. Gewöhnlicher Logout einer Website-Sitzung beeinflusst Kundensoftware nicht. Launch meldet nur die ungültige Identität; Remote-Autorisierungssitzungen, Laufzeit-Zugangsdaten und Gerätefreigabe werden von Licentivo behandelt. Dabei wird weder der Kaufzeitraum geändert noch ein von Launch verwaltetes Entbindungskontingent verbraucht.

Lokale Sitzungsinvalidierung und Einreihung der Benachrichtigung erfolgen in derselben Transaktion. Die Warteschlange fixiert die zu diesem Zeitpunkt vorhandenen Verbindungen und Umgebungen und wiederholt mit derselben Ereignis-ID, anonymen Kontokennung und ursprünglichen Anfrage; später erstellte Verbindungen erhalten keine historischen Kontowiderrufe. Zuerst wird der ursprüngliche Beleg abgefragt; nur nach Bestätigung, dass er nicht existiert, wird erneut gesendet. Ergebnisse werden für jede Umgebung getrennt gespeichert; erst nach passenden Erfolgsbelegen für alle wird der Abschluss angezeigt. Netzwerkausfälle werden automatisch wiederholt, Zugangsdaten-/Vertragskonflikte gelangen zur manuellen Prüfung. Administratoren können Benachrichtigungen auf der Synchronisierungsaufgabenseite anzeigen und wiederholen; dabei entsteht kein neues Widerrufsereignis.

Der kontoweite Widerruf verwendet das revoked_before der ersten Annahme durch Licentivo als Grenze. Während die Benachrichtigung aussteht, werden neue Desktop-Anmeldungen und Identitäts-Assertions pausiert; nach Abschluss muss die auth_time einer echten Anmeldung strikt später als die Grenzsekunde aller Umgebungsbelege liegen. Eine Anmeldung in derselben Sekunde kann später erneut authentifiziert werden; das Aktualisieren von iat oder einer Identitäts-Assertion kann die alte Anmeldung nicht verlängern. Website-Anmeldungen bleiben für Wiederherstellungsoperationen nutzbar. Auch nach erneuter Kontoaktivierung ist eine neue Anmeldung erforderlich; alte Sitzungen werden nicht wiederhergestellt.

Migration alter Daten

Käufe mit bestätigter alter Lizenzbindung verwenden entitlement.migrated und übermitteln nur die alte Lizenz-ID, ohne den alten Schlüssel zu lesen oder auszugeben. Nach Bestätigung der Migration durch Licentivo wird ein unabhängiger Snapshot neuer Version gesendet, um aktuelle kommerzielle Laufzeit und Status zu synchronisieren. Nicht bestätigte alte Ausstellungsergebnisse und inkompatible Autorisierungen erfordern manuelle Prüfung; alte Verwaltungsbefehle werden nicht automatisch erneut ausgeführt.

Gewöhnlicher SDK-Logout, Remote-Geräteentbindung und serverseitiger Identitätswiderruf verwenden bestehende Schnittstellen. Die Remote-Deaktivierung unterliegt weiterhin der Laufzeit der bereits vom offiziellen SDK ausgestellten Offline-Lizenz; Launch verspricht keinen sofortigen Widerruf auf Offline-Geräten.

Der Konto-Logout verwendet einen unabhängigen sicheren Auftrag, eine Zusammenfassung des lokalen Sitzungs-Logouts und prozessübergreifende Koordination; alte Instanzen behandeln nur ihre eigene Anmeldung. Die Wiederherstellung nach Speicherfehlern reicht zuerst den Kontowiderruf nach, ohne Identität abzurufen oder Autorisierung zu starten; Funktionen, Offline-Lizenzen, Gerätegenerationen und Entbindungskontingente bleiben Entscheidungen von Licentivo. Siehe Korrektur und Integrationstest beider Seiten.