Johnny/WGSecure
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

fix(ui): ne plus réclamer un code déjà validé après une reconnexion (v0.8.6)

Browse Source 
Le client tenait pour acquis que l'autorisation ne survivait pas à la chute
du tunnel — un commentaire l'affirmait noir sur blanc. C'est l'inverse : le
serveur autorise l'adresse de tunnel du pair jusqu'à l'échéance enregistrée,
et cette adresse ne change pas d'une reconnexion à l'autre. Se reconnecter
ne révoque rien ; seul le client oubliait, et redemandait un code que le
serveur avait déjà accepté.

Il pose maintenant la question au lieu de la supposer, via GET /api/session
(serveur >= 0.3.0), dès que le tunnel monte : démarrage sur un tunnel déjà
actif, reconnexion automatique, ou avant toute invite de saisie. Le serveur
identifie l'appelant à l'IP source, aucun identifiant ne circule.

Serveur injoignable, réponse illisible ou serveur antérieur à la 0.3.0 ne
valent pas « accès ouvert » : sans information, le client ne conclut rien et
laisse le bouton disponible — le sens sûr, et le comportement de la 0.8.5.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tuxgyver
2026-09-07 18:27:32 +02:00
co-authored by Claude Opus 5
parent 4cf3e26dff
commit 306e512aab
7 changed files with 127 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CHANGELOG.md
+12
View File
@@ -6,6 +6,18 @@ Ce projet suit le [Versionnage Sémantique](https://semver.org/lang/fr/).
---
## [0.8.6] — 2026-09-07
### Corrigé
- **Le bouton « Saisir le code d'accès » réclamait un code déjà validé après une reconnexion.** L'application tenait pour acquis que l'autorisation obtenue ne survivait pas à la chute du tunnel — un commentaire du code l'affirmait même explicitement. C'est l'inverse : le serveur autorise l'adresse de tunnel du pair jusqu'à l'échéance enregistrée, et cette adresse ne change pas d'une reconnexion à l'autre. Une déconnexion/reconnexion ne révoque donc rien, mais le client oubliait tout et repartait de zéro. Il interroge désormais le serveur — nouvelle route `GET /api/session`, disponible à partir de la v0.3.0 du serveur — dès que le tunnel monte : au démarrage de l'application sur un tunnel déjà actif, après une reconnexion automatique, et avant toute invite de saisie. Quand l'accès est encore ouvert, aucune fenêtre ne s'ouvre et l'échéance réelle est reprise telle quelle.
### Modifié
- Le sondage n'envoie aucun identifiant : le serveur reconnaît l'appelant à l'IP source de son tunnel, et ne renseigne donc jamais sur un autre compte que celui qui parle.
- **Un serveur injoignable, une réponse illisible ou une version de serveur antérieure à la 0.3.0 ne valent pas « accès ouvert »** : dans ces trois cas le client ne conclut rien et laisse le bouton disponible. Avec un serveur ancien, le comportement est exactement celui de la 0.8.5 — la route manquante est traitée comme une absence d'information, pas comme un refus.
- Le commentaire de `main_window.py` qui affirmait le contraire de la réalité (« elle ne vaut que pour l'adresse du pair, elle ne survit pas à la déconnexion ») est corrigé : elle survit précisément *parce qu'*elle vaut pour l'adresse du pair.
---
## [0.8.5] — 2026-09-07
### Corrigé