AntoineVe/college-infos
1
0
Fork 0
Code Issues 16 Pull Requests Actions Packages Projects Releases 3 Wiki Activity

Triple authentification pronotepy (double INIT + refresh) lors d'un run #20

New Issue
Open
opened 2026-09-10 13:58:58 +02:00 by AntoineVe · 1 comment
AntoineVe commented 2026-09-10 13:58:58 +02:00
Owner
Copy Link

Symptôme

Lors de chaque run du pipeline, on observe 3 authentifications pronotepy successives dans les logs :

INFO | pronotepy.pronoteAPI | INIT
INFO | pronotepy.pronoteAPI | successfully logged in as avanelstraete1
INFO | pronotepy.pronoteAPI | got onglets data.
INFO | pronotepy.pronoteAPI | INIT
INFO | pronotepy.pronoteAPI | successfully logged in as avanelstraete1
INFO | pronotepy.pronoteAPI | got onglets data.
INFO | pronotepy.pronoteAPI | Have you tried turning it off on again? ERROR: 20 | La page a expiré ! (11)
INFO | pronotepy.pronoteAPI | successfully logged in as avanelstraete1
INFO | pronotepy.pronoteAPI | got onglets data.

Analyse préliminaire

  1. Premier INIT : login initial via qrcode_login ou token_login dans PronoteClient._connect().
  2. Deuxième INIT : pronotepy.ParentClient.post() appelle refresh() qui re-login en mode token — ce refresh est interne à pronotepy, déclenché par une PronoteAPIError.
  3. Troisième INIT : un second refresh() se produit, probablement lors de l'appel à get_informations() qui échoue avec l'erreur 20 (voir issue dédiée #21).

Ce comportement n'est pas bloquant (le pipeline fonctionne), mais il indique que le client pronotepy est rafraîchi plusieurs fois inutilement, ce qui :

  • ralentit l'exécution (3 authentifications réseau par run),
  • augmente le risque de rotation de token inutile,
  • pollue les logs.

Hypothèses à investiguer

  • PronoteClient._connect() est-il appelé plusieurs fois ? Le _client est-il mis en cache correctement (if self._client is not None: return self._client) ?
  • PronoteFetcher crée-t-il plusieurs instances de PronoteClient (une pour l'agenda, une pour les devoirs, une pour les messages) ?
  • Le fetch_step appelle-t-il fetch_agenda() et fetch_homework() séparément, chacun déclenchant un _connect() ?
  • Le double INIT initial (avant l'erreur 20) suggère que le client est créé deux fois volontairement ou que le caching ne fonctionne pas.

Log DEBUG

Un log complet en niveau DEBUG est disponible dans /tmp/opencode/20260910135000-pronote-debug.log.

Contexte

  • Mode qr_token activé
  • Instance : 0640036s.index-education.net (Bordeaux, HubEduConnect)
  • pronotepy 2.15.7
  • L'authentification par mot de passe EduConnect échoue ; le QR code/token est le seul chemin fonctionnel

Attendu

Investiguer pourquoi le client pronotepy s'authentifie 3 fois par run et réduire à 1 authentification (login initial) + au maximum 1 refresh interne si le serveur l'exige.

## Symptôme Lors de chaque run du pipeline, on observe **3 authentifications pronotepy successives** dans les logs : ``` INFO | pronotepy.pronoteAPI | INIT INFO | pronotepy.pronoteAPI | successfully logged in as avanelstraete1 INFO | pronotepy.pronoteAPI | got onglets data. INFO | pronotepy.pronoteAPI | INIT INFO | pronotepy.pronoteAPI | successfully logged in as avanelstraete1 INFO | pronotepy.pronoteAPI | got onglets data. INFO | pronotepy.pronoteAPI | Have you tried turning it off on again? ERROR: 20 | La page a expiré ! (11) INFO | pronotepy.pronoteAPI | successfully logged in as avanelstraete1 INFO | pronotepy.pronoteAPI | got onglets data. ``` ## Analyse préliminaire 1. **Premier INIT** : login initial via `qrcode_login` ou `token_login` dans `PronoteClient._connect()`. 2. **Deuxième INIT** : `pronotepy.ParentClient.post()` appelle `refresh()` qui re-login en mode token — ce refresh est interne à pronotepy, déclenché par une `PronoteAPIError`. 3. **Troisième INIT** : un second `refresh()` se produit, probablement lors de l'appel à `get_informations()` qui échoue avec l'erreur 20 (voir issue dédiée #21). Ce comportement n'est pas bloquant (le pipeline fonctionne), mais il indique que le client pronotepy est rafraîchi plusieurs fois inutilement, ce qui : - ralentit l'exécution (3 authentifications réseau par run), - augmente le risque de rotation de token inutile, - pollue les logs. ## Hypothèses à investiguer - `PronoteClient._connect()` est-il appelé plusieurs fois ? Le `_client` est-il mis en cache correctement (`if self._client is not None: return self._client`) ? - `PronoteFetcher` crée-t-il plusieurs instances de `PronoteClient` (une pour l'agenda, une pour les devoirs, une pour les messages) ? - Le `fetch_step` appelle-t-il `fetch_agenda()` et `fetch_homework()` séparément, chacun déclenchant un `_connect()` ? - Le double INIT initial (avant l'erreur 20) suggère que le client est créé deux fois volontairement ou que le caching ne fonctionne pas. ## Log DEBUG Un log complet en niveau DEBUG est disponible dans `/tmp/opencode/20260910135000-pronote-debug.log`. ## Contexte - Mode `qr_token` activé - Instance : `0640036s.index-education.net` (Bordeaux, HubEduConnect) - pronotepy 2.15.7 - L'authentification par mot de passe EduConnect échoue ; le QR code/token est le seul chemin fonctionnel ## Attendu Investiguer pourquoi le client pronotepy s'authentifie 3 fois par run et réduire à 1 authentification (login initial) + au maximum 1 refresh interne si le serveur l'exige.
AntoineVe added the buginvestigation labels 2026-09-10 13:58:58 +02:00
AntoineVe commented 2026-09-10 14:09:32 +02:00
Author
Owner
Copy Link

Issue GitHub pronotepy liée

L'issue upstream bain3/pronotepy#344 (« HTTP sessions are leaked: no way to close a client, and failed inits abandon their session ») documente le mécanisme derrière les multiples authentifications :

  • _Communication ouvre une requests.Session qui n'est jamais fermée
  • qrcode_login crée un premier client temporaire, fait un POST, puis retourne un second client via token_login() — ce qui explique le double INIT initial
  • Les retry/refresh abandonnent ou fuient des sessions, déclenchant des phases d'initialisation supplémentaires

L'issue propose d'ajouter une méthode .close(), le support de context manager (__enter__/__exit__), et de nettoyer les échecs d'initialisation client.

Statut upstream : ouvert (août 2026), non corrigé dans la 2.15.7.

## Issue GitHub pronotepy liée L'issue upstream [bain3/pronotepy#344](https://github.com/bain3/pronotepy/issues/344) (*« HTTP sessions are leaked: no way to close a client, and failed inits abandon their session »*) documente le mécanisme derrière les multiples authentifications : - `_Communication` ouvre une `requests.Session` qui n'est jamais fermée - `qrcode_login` crée un premier client temporaire, fait un POST, puis retourne un second client via `token_login()` — ce qui explique le **double INIT initial** - Les retry/refresh abandonnent ou fuient des sessions, déclenchant des phases d'initialisation supplémentaires L'issue propose d'ajouter une méthode `.close()`, le support de context manager (`__enter__`/`__exit__`), et de nettoyer les échecs d'initialisation client. **Statut upstream** : ouvert (août 2026), non corrigé dans la 2.15.7.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Anomalie ou comportement incorrect
 investigation
Investigation ou analyse de cause racine
No Label bug investigation
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Codex OpenCode AntoineVe
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: AntoineVe/college-infos#20
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?