Télécharger le MarkdownDocument original sur GitHub
Correctifs de déconnexion et d’instances multiples du SDK Launch, et vérification intégrée des deux systèmes
Date : 2026-10-24. Les correctifs relevant du SDK Launch dans les points 1 et 3 autorisés par l’utilisateur sont terminés ; ils correspondent à la persistance des comptes d’AUTH-08 et à AUTH-10. Les mises à jour fournies par Licentivo sont synchronisées et la vérification intégrée locale est achevée. Aucune mise en production, aucune publication de SDK, aucun commit ni push Git pour cette tâche.
Résultats des correctifs
La déconnexion en attente et la connexion actuellement restaurable utilisent des clés distinctes dans le stockage sécurisé. Si l’écriture du marqueur de déconnexion échoue, seule l’ancienne connexion de cette instance est nettoyée, sans supprimer d’autres sessions. Une intention locale supplémentaire de déconnexion est consignée sous forme de condensat du périmètre et des identifiants de session ; elle est vérifiée avant toute restauration du compte, y compris après redémarrage consécutif à un échec d’écriture ou de suppression du stockage sécurisé ou à l’expiration d’un verrou. Elle ne conserve ni bearer, ni assertion d’identité, ni licence et ne décide d’aucune permission de fonctionnalité.
Les opérations du cycle de vie des comptes sur un même utilisateur système et un même appareil sont coordonnées entre instances et processus. La déconnexion tardive d’une ancienne instance, le nettoyage après HTTP 401, la retransmission après échec et une nouvelle déconnexion après réussite ne peuvent ni écraser ni supprimer une connexion enregistrée plus récemment. Les éléments en attente d’une ancienne session peuvent retransmettre indépendamment sa révocation, sans reconstruire le moteur d’autorisation des autres sessions actuelles.
Les points d’entrée du cycle de vie Application, les exemples natifs et les instructions d’intégration ont été synchronisés pour Go, JavaScript, Python, C#, Java, Ruby, Rust et C/C++. Les signatures publiques des méthodes du Store sécurisé restent inchangées ; le stockage doit correctement prendre en charge plusieurs clés opaques et des enregistrements atomiques. Les identifiants de compte du MemoryStore par défaut restent uniquement en mémoire. Si ni le Store sécurisé ni le marqueur local de déconnexion ne peuvent persister, le SDK renvoie explicitement une erreur et arrête cette instance, sans prétendre avoir achevé une déconnexion résistant au redémarrage.
Mises à jour Licentivo
Les tests d’exécution de cette série utilisent le SDK officiel 0.11.1, avec l’instantané fixé à local-20261024-5d74ba5ea131. La synchronisation utilise le script d’importation préexistant du dépôt. Le manifeste contient 115 fichiers : 23 réellement modifiés, 92 inchangés, aucun nouveau fichier. Ces changements correspondent à 17 fichiers source amont ; le cœur C est réintégré dans les paquets natifs, Ruby et Rust. Les empreintes des fichiers cibles et de l’instantané amont de cet import testé ont été vérifiées à la fin des tests.
Le code source serveur Licentivo n’a pas été modifié par cette tâche ; l’implémentation des autorisations du SDK utilise la version fournie par l’autre responsable. Les tests locaux ont été adaptés à son nouveau contrat : la déconnexion conserve les identifiants machine et fichiers d’autorisation partagés, et le journal de déconnexion du SDK bloque l’ancienne session ; le second accusé d’une dissociation répétée peut être stale. Le refus réel d’exécution, la restauration d’une nouvelle liaison et le quota en libre-service restent vérifiés, sans assouplissement de ces exigences métier.
À la clôture, l’espace de travail a été mis à jour séparément vers le SDK Licentivo 0.11.2 (licentivo-sdk-v0.11.2-release-20261024). Les empreintes des 115 fichiers cibles actuels concordent avec le manifeste et les sources amont. Par rapport à l’instantané testé lors de cette série, seuls VERSION, la constante Ruby VERSION et le numéro de version CMake ont changé dans les sources amont ; l’implémentation d’autorisation est identique. Le script d’importation actuel ajoute aussi la recherche des bibliothèques natives dans le répertoire d’extension de la gem Ruby. Les résultats d’exécution ci-dessus concernent l’instantané fixe 0.11.1 ; ce rapport ne constitue pas une validation du paquet publié 0.11.2.
Vérification
| Périmètre | Résultat |
|---|---|
| HTTP des comptes Go Launch, DPAPI, pannes de stockage de déconnexion et verrous entre processus | 26 réussites enregistrées, sous-tests inclus ; aucun échec ni test ignoré |
| Régressions Go des comptes et du SDK signé après synchronisation du SDK officiel | 21 contrôles réussis ; deux tests HTTP nécessitant une base isolée sont ignorés, mais ont été vérifiés à la ligne précédente et lors de l’intégration réelle des deux systèmes |
| Régressions HTTP des autorisations Licentivo courantes et contrôles ciblés | Deux exécutions regroupées par cas de test donnent 62 réussites finales, dont la nouvelle vérification après correction de l’assertion d’accusé répété |
| SDK Go officiel courant | 67 réussites enregistrées, aucun échec |
| JavaScript / Python | 14 / 12 contrôles réussis, avec le véritable moteur d’exécution signé |
| C# / Java | Cycle de vie et moteur officiel validés ; 9 groupes de tests de compte et de sécurité Java réussis |
| Ruby / Rust | 17 contrôles Ruby de la couche d’adaptation et du véritable SDK natif réussis ; 16 contrôles Rust réussis |
| C / C++ | Les deux pilotes de cycle de vie du véritable SDK signé réussissent, avec couverture de DPAPI, des coupures réseau, des pannes de stockage et de la déconnexion d’anciennes instances |
La vérification intégrée réelle utilise Launch, Licentivo courant, MySQL, le SDK Go Launch, le SDK officiel d’autorisation et DPAPI. Elle produit 18 réussites d’étapes enregistrées (17 étapes de vérification et un enregistrement d’achèvement). Elle couvre la synchronisation des périodes achetées, les véritables fonctionnalités protégées, la restauration après fermeture ordinaire, l’échec d’écriture du stockage de déconnexion ou les échecs conjoints d’écriture et de suppression combinés à une coupure réseau des deux systèmes, le refus de restaurer l’ancien compte après redémarrage, la retransmission de révocation après rétablissement, une nouvelle connexion, la perte de réponse, la dissociation distante, les renouvellements et remboursements ainsi que le refus d’autorisation après contestation.
Les vérifications ciblées sur les services réels confirment également que plusieurs ID d’opération sur une même génération de liaison consomment un seul quota en libre-service ; une ancienne déconnexion ne supprime pas les identifiants et autorisations d’une nouvelle liaison, qui reste restaurable hors ligne ; réémettre un JWT pour le même ancien sid ne restaure pas une liaison déconnectée, mais une nouvelle connexion réelle permet l’activation ; les anciens tickets de déconnexion n’affectent pas la nouvelle liaison ; l’exécution hors ligne ne dépasse pas la limite signée connue.
Aucun nouveau problème métier bloquant n’a été détecté lors de cette série. Les tests d’exécution ont été effectués sur Windows ; le parcours réel entre les deux systèmes utilise Go et les autres langages ont passé les tests locaux du SDK signé. Les services de paiement et de traduction sont des simulateurs isolés, sans débit, remboursement ni déploiement réels ; 192.168.2.177 n’a pas été consulté. L’arrêt du service Licentivo temporaire et de MySQL a été confirmé ; les services préexistants et les autres changements de l’espace de travail sont conservés.
Les journaux d’origine, l’instantané des sources testées et les sondes sont dans le répertoire ignoré .local/account-store-fix-20261024/. Un résumé partageable figure dans les preuves de vérification.