fix(auth): sérialiser le cycle lecture-login-écriture du jeton QR #9

New Issue

AntoineVe · 2026-09-08T23:57:16+02:00

AntoineVe commented

2026-09-08 23:57:16 +02:00

Constat

Le mode qr_token persiste correctement les credentials par écriture atomique, mais aucune exclusion mutuelle ne protège la séquence complète :

lecture de .pronote_auth_state.json ;
token_login(**credentials) ;
export_credentials() ;
remplacement du fichier d'état.

Le document docs/pronote-auth.md et l'implémentation indiquent que le token mobile est renouvelé après une connexion réussie. Deux lancements concurrents (appel manuel pendant le timer, seconde machine partageant l'état, double invocation de service) peuvent donc partir du même token : l'un obtient un token plus récent, l'autre échoue ou écrase l'état avec un résultat devenu obsolète. L'atomicité du seul remplacement de fichier évite un JSON tronqué, mais pas cette course logique.

Proposition

Introduire un verrou inter-processus associé au fichier d'état, couvrant toute la séquence de renouvellement, et non seulement save().

Le comportement attendu lorsque le verrou est déjà détenu doit être explicite et actionnable :

soit attente bornée puis réutilisation de l'état fraîchement écrit ;
soit échec expurgé distinct de PronoteAuthRotationError, afin de ne pas demander à tort un nouveau QR code.

Conserver la règle actuelle : un vrai token refusé ne déclenche pas automatiquement d'enrôlement QR.

Critères d'acceptation

Deux processus ne peuvent pas appeler token_login simultanément avec le même état.
Après libération du verrou, le second processus relit les credentials et utilise la version renouvelée.
Timeout, fichier de verrou et erreurs d'E/S sont expurgés ; aucun token, PIN, QR JSON ni contenu d'état ne fuit.
Les tests couvrent au moins une collision reproductible entre deux gestionnaires d'état et vérifient l'absence de corruption ou de régression du token.
La configuration systemd et la documentation précisent que l'état QR/token ne doit pas être partagé entre hôtes sans mécanisme de verrouillage compatible.

Périmètre

À réaliser avec la persistance QR/token de PR #6 ou juste après. Le mode password et le cache iCal restent hors périmètre.

## Constat Le mode `qr_token` persiste correctement les credentials par écriture atomique, mais aucune exclusion mutuelle ne protège la séquence complète : 1. lecture de `.pronote_auth_state.json` ; 2. `token_login(**credentials)` ; 3. `export_credentials()` ; 4. remplacement du fichier d'état. Le document `docs/pronote-auth.md` et l'implémentation indiquent que le token mobile est renouvelé après une connexion réussie. Deux lancements concurrents (appel manuel pendant le timer, seconde machine partageant l'état, double invocation de service) peuvent donc partir du même token : l'un obtient un token plus récent, l'autre échoue ou écrase l'état avec un résultat devenu obsolète. L'atomicité du seul remplacement de fichier évite un JSON tronqué, mais pas cette course logique. ## Proposition Introduire un verrou inter-processus associé au fichier d'état, couvrant **toute** la séquence de renouvellement, et non seulement `save()`. Le comportement attendu lorsque le verrou est déjà détenu doit être explicite et actionnable : - soit attente bornée puis réutilisation de l'état fraîchement écrit ; - soit échec expurgé distinct de `PronoteAuthRotationError`, afin de ne pas demander à tort un nouveau QR code. Conserver la règle actuelle : un vrai token refusé ne déclenche pas automatiquement d'enrôlement QR. ## Critères d'acceptation - Deux processus ne peuvent pas appeler `token_login` simultanément avec le même état. - Après libération du verrou, le second processus relit les credentials et utilise la version renouvelée. - Timeout, fichier de verrou et erreurs d'E/S sont expurgés ; aucun token, PIN, QR JSON ni contenu d'état ne fuit. - Les tests couvrent au moins une collision reproductible entre deux gestionnaires d'état et vérifient l'absence de corruption ou de régression du token. - La configuration systemd et la documentation précisent que l'état QR/token ne doit pas être partagé entre hôtes sans mécanisme de verrouillage compatible. ## Périmètre À réaliser avec la persistance QR/token de PR #6 ou juste après. Le mode `password` et le cache iCal restent hors périmètre.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: AntoineVe/college-infos#9