# Korrektur der Konto-Logout-Wiederholung im Launch SDK

Datum: 2026-10-24. AUTH-07 wurde behoben und die Kontolebenszyklus-Einstiege von Go, JavaScript, Python, C#, Java, Ruby, Rust, C und C++ wurden synchronisiert. **Keine Bereitstellung, keine SDK-Veröffentlichung und kein Git-Commit oder Push.** Diese Aufgabe änderte keinen Launch- oder Licentivo-Servergeschäftscode.

## Verhalten

Beim ausdrücklichen Logout wird der Kontodatensatz im sicheren Speicher zuerst als „nur zum Widerruf ausstehend“ markiert; danach wird das offizielle SDK abgemeldet und der Kontositzungswiderruf an Launch übermittelt. Unabhängig von Netzwerk- oder Abbruchstatus stoppt die lokale Laufzeit und darf keine geschützten Funktionen weiter ausführen.

Solange Launch den Widerruf nicht bestätigt, bewahrt das SDK den Auftrag und die für Wiederholungen benötigten ursprünglichen Kontozugangsdaten, behandelt ihn aber nicht mehr als angemeldetes Konto. Erneutes `Logout`, `Login` oder `Restore` setzt den Widerruf fort; `Restore` verwendet den Auftrag nicht, um Identität anzufordern oder die Autorisierungslaufzeit zu starten. Erst nach erfolgreicher Antwort oder HTTP 401, das die Nichtauthentifizierbarkeit der ursprünglichen Sitzung anzeigt, wird der Kontoauftrag gelöscht. Dadurch kann auch eine verlorene Antwort wiederhergestellt werden und ein zweiter Logout meldet nicht Erfolg, ohne den Widerruf nachgereicht zu haben.

Normale angemeldete Datensätze bleiben mit v2 kompatibel. Ausstehende Widerrufsdatensätze verwenden ein privates v3-Format; Java und Rust entfernten außerdem die für normale Anmeldung benötigte Form der Zugangsdatenfelder, damit ältere SDKs den Auftrag nicht als normale Anmeldung verkennen. Der Auftrag speichert keine kurzlebige Identitäts-Assertion, Lizenzschlüssel oder signierte Berechtigung.

Der Kontoauftrag verwendet den ursprünglich konfigurierten sicheren `Store`. **Prozessübergreifende Wiederherstellung erfordert persistenten sicheren Speicher**, beispielsweise Windows DPAPI oder einen vom SDK unterstützten verschlüsselten Store; der standardmäßige `MemoryStore` bewahrt Daten nur im aktuellen Prozess. Wiederholungen werden durch spätere Anmeldung, Wiederherstellung oder Logout ausgelöst; es gibt keine neue unabhängige Hintergrundaufgabe. Unvollständige Speicherung oder Widerruf gibt einen Fehler oder ausstehenden Zustand zurück, keinen Erfolg.

Geräte-Logout-Tickets und `.logout.json` des Licentivo SDK werden weiterhin von diesem verwaltet; Launch löscht dessen Cache-Verzeichnis nicht und entscheidet nicht über Geräte-, Funktions- oder Offline-Berechtigungen. Native Beispiele und SDK-Dokumentation aller Sprachen wurden ebenfalls aktualisiert.

## Verifikation

| Umfang | Ergebnis |
| --- | --- |
| Launch-Go-Quellpakete | 185 bestandene Testeinträge einschließlich Unterfällen; keine Fehler; `go vet` bestanden |
| Echtes Launch HTTP und MySQL | Nach Unterbrechung der Logout-Anfrage bleibt der sichere Auftrag erhalten; nach SDK-Neuerstellung kann die Anmeldung nicht wiederhergestellt werden; nach Netzwerkwiederherstellung wird der Widerruf nachgereicht und sowohl Authentifizierungs- als auch Identitätsschnittstelle lehnen das alte Token ab |
| JavaScript | 10 Prüfungen bestanden, einschließlich fehlgeschlagenem Logout, Wiederherstellung nach Neuerstellung und 401-Bestätigung |
| Python | 8 Prüfungen bestanden, einschließlich lokaler Kontobereinigung nach Logout, Wiederherstellung nach Neuerstellung und Windows DPAPI |
| C# | Lebenszyklus, Auftragswiederherstellung, Erhaltung des SDK-Logout-Protokolls und DPAPI-Prüfung bestanden |
| Java | 7 Gruppen von Lebenszyklus- und Sicherheitstests bestanden, einschließlich Offline-Logout-Wiederholung |
| Ruby | Regression für Kontolebenszyklus, Auftragswiederherstellung und verschlüsselten Speicher bestanden |
| Rust | Alle lokalen Tests bestanden, einschließlich Wiederherstellung des Auftrags nach Neuerstellung und tatsächlicher SDK-Ausführung |
| C / C++ | Tatsächlich signiertes SDK, Wiederherstellung nach Neuerstellung ohne Netzwerk, 401-Bestätigung, DPAPI und C++-Laufzeiteinstieg bestanden |
| Aktuelle Licentivo-Autorisierungskorrekturen | 45 bestandene Testeinträge, keine Fehler, keine Überspringungen; einschließlich negativer Benachrichtigung bei Richtliniendrift, Geräteabgleich bei Downgrade, manueller Geräteobergrenze und Regression bestehender Autorisierungen |
| Eingebettetes offizielles SDK | Alle Hashes der 115 Dateien im Manifest stimmen überein; Autorisierungs- und Kryptografieimplementierung wurden nicht geändert |

In der Launch-Quellregression wurden vier Tests übersprungen, die andere dedizierte Datenbanken benötigen: `TestMySQLBaseline`, `TestProductUploadRoundTrip`, `TestInitialAdministratorMustChangePasswordBeforeAdministration`, `TestNewPaymentProvidersAndRegistrationWithoutMail`; sie wurden nicht als bestanden gezählt. SDK-, Konto-HTTP-, Kaufsynchronisierungs- und Zuordnungsabläufe wurden diesmal mit einer separaten Testdatenbank geprüft.

## Integrationstest beider Seiten

Mit separatem lokalem MySQL 8.0.32, aktuellem Launch, Licentivo-Dienst und dessen Workern, tatsächlichem Go Launch SDK und offizieller Autorisierungslaufzeit sowie DPAPI-Kontospeicher wurden **15 Geschäftsphasen** abgeschlossen.

Zwei neue Logout-Fehlerszenarien geprüft:

1. **Anfrage erreicht Launch nicht**: Die Konto-Logout-Schnittstelle gibt vorübergehend 503 zurück. Das SDK stoppt lokale Funktionen, die echte Licentivo-Gerätebindung wird freigegeben und der Kontowiderrufsauftrag bleibt erhalten. Nach SDK-Neuerstellung wird weiterhin nur der Logout wiederholt; nach Wiederherstellung der Verbindung wird die ursprüngliche Launch-Sitzung widerrufen und Licentivo bestätigt den Empfang der entsprechenden Sitzungsbenachrichtigung.
2. **Server hat widerrufen, aber Antwort ging verloren**: Launch hat den Logout verarbeitet, der Testproxy ersetzt die Antwort durch 503. Der Auftrag bleibt über SDK-Neuerstellung hinweg erhalten; nach Wiederherstellung der Verbindung bestätigt HTTP 401 die Ungültigkeit der ursprünglichen Sitzung und der Auftrag wird gelöscht. Dabei werden weder Anmeldung wiederhergestellt noch Gerät erneut aktiviert.

Weitere Phasen decken tatsächliche Kaufsynchronisierung und signierte Funktionsausführung, Wiederherstellung nach normalem Schließen, normalen Logout, Remote-Entbindung und alte Generationen, Verlängerungserstattung, Kontowiderruf und erneute Anmeldung, Ausführungsverweigerung bei voller Erstattung, Erstattungswiederherstellung, Chargeback und Übersetzungsregression für große Dokumente ab. Drei Licentivo-Updates wurden von der dafür zuständigen Stelle bereitgestellt; diese Aufgabe hat sie nur gebaut und geprüft.

Zahlungsanbieter und DeepL verwendeten isolierte simulierte Dienste, ohne echte Abbuchung, Erstattung oder kostenpflichtige Übersetzung. Die Verifikation echter gemeinsamer Dienste verwendete Go; andere Sprachen absolvierten lokale SDK-Regressionen. Es wird nicht behauptet, dass alle neun Sprachen jeweils eine echte Dienstbereitstellungsabnahme abgeschlossen haben.

In dieser Runde wurde `192.168.2.177` nicht aufgerufen. Temporäre MySQL- und Licentivo-Prozesse wurden gestoppt, bestehende Dienste und Testnachweise blieben erhalten. Originalmaterial liegt in `.local/logout-retry-fix-20261024/`; Zusammenfassung und Quell-Hashes siehe [Verifikationsnachweise](https://github.com/spf86/licentivo-launch/blob/main/docs/logout-retry-fix-evidence-2026-10-24.json).