Zum Inhalt springen
Zurück zur Launch-Dokumentation

Markdown herunterladenOriginaldokument auf GitHub

Korrektur von Konto-Logout und Mehrinstanzbetrieb im Launch SDK sowie Integrationstest beider Seiten

Datum: 2026-10-24. Die dem Launch SDK zugewiesenen Korrekturen der vom Benutzer autorisierten Punkte 1 und 3 wurden abgeschlossen; sie entsprechen dem Kontopersistenzteil von AUTH-08 und AUTH-10. Von Licentivo bereitgestellte Updates wurden synchronisiert und lokal integriert getestet. Diese Aufgabe wurde nicht bereitgestellt, kein SDK veröffentlicht und kein Git-Commit oder Push durchgeführt.

Korrekturergebnis

Der ausstehende Konto-Logout und die aktuell wiederherstellbare Anmeldung verwenden unterschiedliche Schlüssel im sicheren Speicher. Schlägt das Schreiben der Logout-Markierung fehl, wird nur die alte Anmeldung dieser Instanz bereinigt, ohne andere Sitzungen zu löschen. Eine zusätzliche lokale Konto-Logout-Absicht wird als Hash von Umfang und Sitzungszugangsdaten erfasst; vor Kontowiederherstellung wird sie geprüft, auch bei Neustart nach fehlgeschlagenem Schreiben/Löschen im sicheren Speicher oder Mutex-Timeout. Sie speichert weder bearer, Identitäts-Assertion noch Lizenz und entscheidet nicht über Funktionsberechtigungen.

Kontolebenszyklusoperationen desselben OS-Benutzers und Geräts werden instanz- und prozessübergreifend koordiniert. Verspäteter Logout einer alten Instanz, HTTP 401-Bereinigung, Nachreichen nach Fehlern und erneuter Logout nach Erfolg dürfen eine später gespeicherte neue Anmeldung weder überschreiben noch löschen. Der Auftrag einer alten Sitzung kann den Kontowiderruf unabhängig nachreichen, ohne die Autorisierungslaufzeit einer anderen aktuellen Sitzung neu zu erstellen.

Application-Lebenszyklus-Einstiege, native Beispiele und Integrationsanleitungen für Go, JavaScript, Python, C#, Java, Ruby, Rust und C/C++ wurden synchronisiert. Öffentliche Methodensignaturen des sicheren Store bleiben unverändert; er muss mehrere opake Schlüssel und atomare Speicherung korrekt unterstützen. Konto-Zugangsdaten des standardmäßigen MemoryStore bleiben nur im Speicher. Wenn weder sicherer Store noch lokale Logout-Markierung persistiert werden können, meldet das SDK ausdrücklich einen Fehler und stoppt diese Instanz, ohne einen über Neustarts hinweg abgeschlossenen Logout zu behaupten.

Licentivo-Update

Die tatsächlich ausgeführten Tests dieser Runde verwendeten offizielles SDK 0.11.1 mit der festen Snapshot-Kennung local-20261024-5d74ba5ea131. Synchronisiert wurde mit dem vorhandenen Importskript des Repositorys; das Manifest umfasst 115 Dateien, tatsächlich geändert 23, unverändert 92, keine neuen Dateien. Die Änderungen entsprechen 17 Upstream-Quelldateien; der C-Kern wird in nativen, Ruby- und Rust-Paketen mehrfach gebündelt. Für diesen getesteten Import wurden nach Testabschluss die Hashes der Zieldateien und des Upstream-Snapshots geprüft.

Der Licentivo-Serverquellcode wurde durch diese Aufgabe nicht geändert; die Autorisierungsimplementierung des SDK verwendet die von der Gegenseite bereitgestellte Version. Lokale Tests wurden an deren aktualisierten Vertrag angepasst: Logout bewahrt gemeinsame Maschinenzugangsdaten und Lizenzdateien, während der Logout-Datensatz des SDK die alte Sitzung blockiert; der zweite Beleg bei wiederholter Entbindung kann stale sein. Tatsächliche Ausführungsverweigerung, Wiederherstellung neuer Bindungen und Selbstbedienungskontingent werden weiterhin geprüft; diese Geschäftsanforderungen wurden nicht gelockert.

Zum Abschluss wurde der Arbeitsbereich separat auf Licentivo SDK 0.11.2 (licentivo-sdk-v0.11.2-release-20261024) aktualisiert. Die Hashes aller aktuellen 115 Zieldateien stimmen mit Manifest und Upstream-Quelldateien überein. Gegenüber dem in dieser Runde getesteten Snapshot änderten sich in den Upstream-Quelldateien nur VERSION, die Ruby-VERSION-Konstante und die CMake-Versionsnummer; die Autorisierungsimplementierung ist identisch. Das aktuelle Importskript ergänzt außerdem die Suche nach nativen Bibliotheken im Ruby-gem-Erweiterungsverzeichnis. Die obigen Laufzeittestaufzeichnungen beziehen sich auf den festen 0.11.1-Snapshot; dieser Bericht ist kein Abnahmenachweis für das 0.11.2-Releasepaket.

Verifikation

Umfang Ergebnis
Launch Go Konto-HTTP, DPAPI, Logout-Speicherfehler und prozessübergreifende Sperren 26 bestandene Einträge einschließlich Unterfällen; keine Fehler, keine Überspringungen
Go-Konto- und signierte SDK-Regression nach Synchronisierung des offiziellen SDK 21 bestanden; zwei HTTP-Tests mit separater Datenbank übersprungen, bereits in der vorherigen Zeile und im tatsächlichen Integrationstest beider Seiten geprüft
Aktuelle Licentivo-HTTP-Autorisierungsregression und gezielte Kontrollen Zwei Ausführungen nach Testfall zusammengeführt, 62 endgültig bestandene Einträge; einschließlich erneuter Prüfung nach Korrektur der Assertion für doppelte Belege
Aktuelles offizielles Go SDK 67 bestandene Einträge, keine Fehler
JavaScript / Python 14 / 12 Prüfungen bestanden, einschließlich tatsächlich signierter Laufzeit
C# / Java Lebenszyklus und offizielle Laufzeit bestanden; Java 9 Gruppen von Konto-/Sicherheitstests bestanden
Ruby / Rust Ruby 17 Wrapper- und tatsächliche native SDK-Prüfungen bestanden; Rust 16 Prüfungen bestanden
C / C++ Beide tatsächlich signierten SDK-Lebenszyklustreiber bestanden, einschließlich DPAPI, Netzwerkausfall, Speicherfehler und Logout alter Instanzen

Der echte Integrationstest beider Seiten verwendete tatsächliches Launch, aktuelles Licentivo, MySQL, Go Launch SDK, offizielles Autorisierungs-SDK und DPAPI und ergab 18 bestandene Phaseneinträge (17 Verifikationsphasen und ein Abschlusseintrag). Er umfasst Kaufzeitsynchronisierung, tatsächliche geschützte Funktionen, Wiederherstellung nach normalem Schließen, Logout-Speicherschreibfehler bzw. gleichzeitige Schreib-/Löschfehler zusammen mit Netzwerkausfall beider Seiten, Verweigerung der Wiederherstellung des alten Kontos nach Neustart, Nachreichen des Widerrufs nach Netzwerkwiederherstellung, neue Anmeldung, Antwortverlust, Remote-Entbindung, Verlängerungserstattung und Autorisierungsverweigerung nach Chargeback.

Gezielte Prüfungen mit tatsächlichen Diensten bestätigten außerdem: Verschiedene Operationsnummern für dieselbe Bindungsgeneration verbrauchen nur einmal Selbstbedienungskontingent; alter Logout löscht weder Zugangsdaten noch Lizenz der neuen Bindung, die auch ohne Netzwerk wiederhergestellt werden kann; ein neues JWT für dieselbe alte sid kann die abgemeldete Bindung nicht wiederherstellen, eine neue echte Anmeldung kann aktivieren; alte Logout-Tickets beeinflussen die neue Bindung nicht; Offline-Ausführung überschreitet keine bekannte signierte Frist.

In dieser Runde wurden keine neuen blockierenden Geschäftsprobleme festgestellt. Laufzeittests erfolgten unter Windows; die echte Geschäftskette beider Seiten verwendete Go, andere Sprachen absolvierten lokale signierte SDK-Tests. Zahlungs- und Übersetzungsdienste waren isolierte Simulationen, ohne tatsächliche Abbuchung, Erstattung oder Bereitstellung; 192.168.2.177 wurde nicht aufgerufen. Temporärer Licentivo-Dienst und MySQL wurden nachweislich gestoppt; bestehende Dienste und andere Arbeitsbereichsänderungen blieben erhalten.

Originalprotokolle, getesteter Quellcode-Snapshot und Prüfwerkzeuge liegen im ignorierten Verzeichnis .local/account-store-fix-20261024/. Eine teilbare Zusammenfassung siehe Verifikationsnachweise.