# Correctif de reprise de déconnexion des comptes du SDK Launch

Date : 2026-10-24. AUTH-07 est corrigé et les points d’entrée du cycle de vie des comptes sont synchronisés pour Go, JavaScript, Python, C#, Java, Ruby, Rust, C et C++. **Aucun déploiement, aucune publication de SDK, aucun commit ni push Git.** Cette tâche n’a modifié aucun code métier serveur Launch ou Licentivo.

## Action

La déconnexion explicite marque d’abord l’enregistrement du compte dans le stockage sécurisé comme « révocation en attente uniquement », puis appelle la déconnexion du SDK officiel et transmet à Launch la révocation de la session du compte. Quel que soit l’état du réseau ou de l’annulation, le moteur local s’arrête et ne peut plus exécuter de fonctionnalités protégées.

Tant que Launch ne confirme pas la révocation, le SDK conserve l’élément en attente et les identifiants du compte d’origine nécessaires à la reprise, sans les considérer comme un compte connecté. Un nouvel appel `Logout`, `Login` ou `Restore` reprend la demande de révocation ; `Restore` n’utilise pas cet élément pour demander une identité ou démarrer le moteur d’autorisation. L’élément en attente est supprimé uniquement après une réponse réussie ou HTTP 401 confirmant que l’ancienne session ne peut plus s’authentifier. La récupération reste donc possible après une réponse perdue, sans annoncer une seconde déconnexion réussie alors que la révocation n’a jamais été retransmise.

Les enregistrements de connexion ordinaires restent compatibles v2. Les enregistrements en attente de révocation utilisent le format privé v3 ; Java et Rust retirent également la forme des champs d’identifiants nécessaire à une connexion normale, afin qu’un ancien SDK ne les prenne pas pour une session connectée. Ces éléments ne conservent ni assertion d’identité de courte durée, ni clé de licence, ni autorisation signée.

Les éléments de compte en attente utilisent le `Store` sécurisé déjà configuré. **Une récupération entre processus exige un stockage sécurisé persistant**, par exemple Windows DPAPI ou un stockage chiffré pris en charge par le SDK ; le `MemoryStore` par défaut conserve les données uniquement dans le processus courant. Les tentatives sont déclenchées par les opérations ultérieures de connexion, restauration ou déconnexion, sans nouvelle tâche de fond indépendante. Un stockage ou une révocation inachevés renvoient une erreur ou un résultat en attente et ne sont pas présentés comme une réussite.

Les tickets de déconnexion d’appareil et `.logout.json` restent gérés par le SDK Licentivo. Launch ne supprime pas son cache et ne décide pas des appareils, fonctionnalités ou permissions hors ligne. Les exemples natifs et les documents SDK de chaque langage sont également mis à jour.

## Vérification

| Périmètre | Résultat |
| --- | --- |
| Paquets source Go de Launch | 185 réussites de tests enregistrées, sous-tests inclus ; aucun échec ; `go vet` réussi |
| HTTP Launch réel et MySQL | Après interruption de la requête de déconnexion, l’élément sécurisé en attente subsiste ; reconstruire le SDK ne restaure pas la connexion ; après rétablissement du réseau, la révocation est retransmise et l’authentification et les interfaces d’identité de l’ancien token refusent toutes l’accès |
| JavaScript | 10 contrôles réussis, dont échec de déconnexion, récupération après reconstruction et confirmation par 401 |
| Python | 8 contrôles réussis, dont nettoyage local du compte après déconnexion, récupération après reconstruction et Windows DPAPI |
| C# | Vérifications réussies du cycle de vie, de la récupération des éléments en attente, de la conservation du journal de déconnexion SDK et de DPAPI |
| Java | 7 groupes de tests de cycle de vie et de sécurité réussis, dont la reprise de déconnexion hors ligne |
| Ruby | Régressions réussies du cycle de vie des comptes, de la récupération des éléments en attente et du stockage chiffré |
| Rust | Tous les tests locaux réussissent, y compris la récupération des éléments en attente après reconstruction et l’exécution réelle du SDK |
| C / C++ | Contrôles réussis du SDK avec signatures réelles, de la récupération après reconstruction sans réseau, de la confirmation par 401, de DPAPI et du point d’entrée d’exécution C++ |
| Correctifs courants des autorisations Licentivo | 45 réussites de tests enregistrées, sans échec ni test ignoré ; couvrent les notifications négatives après dérive de politique, la coordination des appareils sous une politique réduite, la limite manuelle d’appareils et les régressions d’autorisation existantes |
| SDK officiel intégré | Les empreintes des 115 fichiers du manifeste concordent ; aucune modification de l’implémentation d’autorisation ou de chiffrement |

Dans les régressions des sources Launch, les quatre tests `TestMySQLBaseline`, `TestProductUploadRoundTrip`, `TestInitialAdministratorMustChangePasswordBeforeAdministration` et `TestNewPaymentProvidersAndRegistrationWithoutMail`, qui nécessitent d’autres bases dédiées, ont été ignorés et non comptés comme réussis. Le SDK, HTTP des comptes, la synchronisation des achats et les mappages ont été vérifiés avec des bases de test isolées.

## Vérification intégrée des deux systèmes

**15 étapes métier** ont été réalisées avec un MySQL 8.0.32 local isolé, les services Launch et Licentivo courants et leurs traitements, le véritable SDK Go Launch et le moteur officiel d’autorisation, ainsi qu’un stockage de compte DPAPI.

Deux vérifications de panne de déconnexion ont été ajoutées :

1. **La requête n’atteint pas Launch** : l’interface de déconnexion renvoie temporairement 503. Le SDK arrête les fonctionnalités locales, libère le véritable lien d’appareil Licentivo et conserve la révocation de compte en attente. Après reconstruction, le SDK réessaie uniquement la déconnexion ; après rétablissement de la connexion, l’ancienne session Launch est révoquée et Licentivo confirme la réception de la notification correspondante.
2. **Le serveur a révoqué la session, mais la réponse est perdue** : Launch a traité la déconnexion et le proxy de test remplace la réponse par 503. L’élément en attente survit à la reconstruction du SDK ; après rétablissement, HTTP 401 confirme l’invalidité de l’ancienne session et permet sa suppression. Aucune connexion n’est restaurée et aucun appareil réactivé pendant ce processus.

Les autres étapes couvrent la synchronisation réelle des achats et l’exécution signée des fonctionnalités, la restauration après fermeture ordinaire, la déconnexion normale, la dissociation distante et les anciennes générations, les renouvellements et remboursements, la révocation et la nouvelle connexion du compte, le refus d’exécution après remboursement intégral, la récupération après remboursement, les contestations et la régression de traduction de grands documents. Les trois mises à jour Licentivo ont été fournies par leur responsable ; cette tâche les a uniquement compilées et vérifiées.

Les fournisseurs de paiement et DeepL utilisent des simulateurs isolés, sans débit, remboursement ni traduction payante réels. La vérification des véritables services réunis utilise Go ; les autres langages ont passé les régressions SDK locales. Il n’est pas affirmé que les neuf langages aient chacun passé une validation de déploiement sur des services réels.

`192.168.2.177` n’a pas été consulté lors de cette série. Les processus temporaires MySQL et Licentivo sont arrêtés ; les services préexistants et les preuves de test sont conservés. Les données d’origine sont dans `.local/logout-retry-fix-20261024/` ; le résumé et les empreintes des sources figurent dans les [preuves de vérification](https://github.com/spf86/licentivo-launch/blob/main/docs/logout-retry-fix-evidence-2026-10-24.json).