feat(auth): prendre en charge le PIN de compte Pronote pour le flux QR/token #8

New Issue

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

AntoineVe commented

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

Constat

La branche contient déjà le mode PRONOTE_AUTH_MODE=qr_token (PR #6), mais le wrapper ne transmet à pronotepy que qr_code, pin et uuid.

Or la version installée pronotepy 2.15.7 expose le paramètre optionnel account_pin dans :

ParentClient.qrcode_login(..., account_pin=None, ...) ;
ParentClient.token_login(..., account_pin=None, ...).

Ce paramètre est utilisé par la bibliothèque lorsque le compte Pronote exige un second facteur. Dans son état actuel, un compte activant cette protection ne peut pas terminer l'enrôlement QR ni renouveler son jeton via pronote-sync.

Proposition

Ajouter un réglage dédié, par exemple PRONOTE_ACCOUNT_PIN :

type SecretStr | None dans PronoteSettings ;
transmis à qrcode_login et token_login uniquement en mode qr_token ;
jamais ajouté au fichier .pronote_auth_state.json ni journalisé ;
expurgé par Settings.redaction_secrets() et _collect_auth_secrets().

Documenter clairement qu'il s'agit du PIN de second facteur du compte, distinct du PRONOTE_QR_PIN à quatre chiffres qui déchiffre le QR code.

Critères d'acceptation

Les deux appels pronotepy reçoivent account_pin lorsqu'il est configuré, et None sinon.
Le secret est masqué dans les représentations Pydantic, journaux, erreurs, causes, contextes et tracebacks.
Le secret n'est ni écrit dans l'état persistant, ni dans .env.example sous forme de valeur réelle.
Des tests utilisent les signatures réelles de pronotepy 2.15.7 (fake/signature-faithful) pour l'enrôlement et le renouvellement.
La documentation d'exploitation indique le comportement attendu si le fournisseur exige ce second facteur.

Périmètre

À traiter après ou avec l'intégration de PR #6 ; aucun changement au mode password n'est requis.

## Constat La branche contient déjà le mode `PRONOTE_AUTH_MODE=qr_token` (PR #6), mais le wrapper ne transmet à `pronotepy` que `qr_code`, `pin` et `uuid`. Or la version installée `pronotepy 2.15.7` expose le paramètre optionnel `account_pin` dans : - `ParentClient.qrcode_login(..., account_pin=None, ...)` ; - `ParentClient.token_login(..., account_pin=None, ...)`. Ce paramètre est utilisé par la bibliothèque lorsque le compte Pronote exige un second facteur. Dans son état actuel, un compte activant cette protection ne peut pas terminer l'enrôlement QR ni renouveler son jeton via `pronote-sync`. ## Proposition Ajouter un réglage dédié, par exemple `PRONOTE_ACCOUNT_PIN` : - type `SecretStr | None` dans `PronoteSettings` ; - transmis à `qrcode_login` et `token_login` uniquement en mode `qr_token` ; - jamais ajouté au fichier `.pronote_auth_state.json` ni journalisé ; - expurgé par `Settings.redaction_secrets()` et `_collect_auth_secrets()`. Documenter clairement qu'il s'agit du PIN de second facteur du compte, distinct du `PRONOTE_QR_PIN` à quatre chiffres qui déchiffre le QR code. ## Critères d'acceptation - Les deux appels `pronotepy` reçoivent `account_pin` lorsqu'il est configuré, et `None` sinon. - Le secret est masqué dans les représentations Pydantic, journaux, erreurs, causes, contextes et tracebacks. - Le secret n'est ni écrit dans l'état persistant, ni dans `.env.example` sous forme de valeur réelle. - Des tests utilisent les signatures réelles de `pronotepy 2.15.7` (fake/signature-faithful) pour l'enrôlement et le renouvellement. - La documentation d'exploitation indique le comportement attendu si le fournisseur exige ce second facteur. ## Périmètre À traiter après ou avec l'intégration de PR #6 ; aucun changement au mode `password` n'est requis.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: AntoineVe/college-infos#8