docs(auth): rendre la référence Pronote vérifiable et cohérente avec le client #10

New Issue

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

AntoineVe commented

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

Constat

docs/pronote-auth.md est utile comme document de recherche, mais ne permet pas encore de distinguer les faits vérifiés, les hypothèses de rétro-ingénierie et le périmètre réellement livré par pronote-sync.

Écarts observables dans l'état actuel :

les annexes A et B sont présentes deux fois, à partir de la ligne 541 puis à nouveau après le premier tableau ;
le scénario QR indique que le QR est généré dans l'interface web puis scanné par l'application, tandis que .env.example et la note de PR #6 demandent un JSON QR « généré depuis l'application mobile » ;
le document expose sept familles d'authentification, alors que le client du projet propose concrètement seulement :
- URL iCal ;
- connexion pronotepy par mot de passe, éventuellement via l'un des slugs ENT fermés ;
- QR/token via qrcode_login puis token_login.
des valeurs précises (durée de sessions, validité de dix minutes, persistance des anciens tokens, statut « officiel ») sont formulées comme des faits, sans source ni version de bibliothèque associée.

Le contrat local vérifiable est pronotepy 2.15.7 : ses méthodes qrcode_login, token_login et export_credentials définissent les paramètres réellement disponibles pour cette intégration.

Proposition

Refondre ce document en référence traçable et orientée exploitation :

supprimer les annexes dupliquées ;
ajouter des liens/citations datés vers chaque source primaire ou communautaire utilisée ;
qualifier explicitement chaque affirmation : documentée officiellement, observée dans une version de bibliothèque, ou hypothèse à valider ;
ajouter un tableau « pris en charge par pronote-sync / délégable à pronotepy / non implémenté » ;
remplacer le parcours QR ambigu par une procédure unique, reproductible et alignée sur les variables PRONOTE_QR_CODE_FILE, PRONOTE_QR_PIN et la version épinglée/testée de pronotepy ;
indiquer que les expirations et comportements de rotation sont propres à l'instance et nécessitent un essai réel avant une promesse de support.

Critères d'acceptation

Une seule occurrence de chaque annexe et tableau récapitulatif.
Chaque délai, statut ou détail de protocole non garanti par le projet a une source, une date de consultation et un niveau de confiance.
Le tableau de compatibilité reflète le code et les tests actuels, sans suggérer qu'une implémentation CAS/SAML/EduConnect générique est incluse.
La procédure QR ne contredit ni .env.example, ni la documentation d'exploitation, ni la signature de pronotepy effectivement installée.
Le document rappelle que le premier essai sur l'instance Pronote concernée est nécessaire et qu'aucun secret/QR/token ne doit être copié dans les exemples.

Périmètre

Documentation uniquement ; ce ticket ne demande pas de modifier le protocole Pronote ni de contourner un mécanisme d'authentification.

## Constat `docs/pronote-auth.md` est utile comme document de recherche, mais ne permet pas encore de distinguer les faits vérifiés, les hypothèses de rétro-ingénierie et le périmètre réellement livré par `pronote-sync`. Écarts observables dans l'état actuel : - les annexes A et B sont présentes deux fois, à partir de la ligne 541 puis à nouveau après le premier tableau ; - le scénario QR indique que le QR est généré dans l'interface web puis scanné par l'application, tandis que `.env.example` et la note de PR #6 demandent un JSON QR « généré depuis l'application mobile » ; - le document expose sept familles d'authentification, alors que le client du projet propose concrètement seulement : - URL iCal ; - connexion `pronotepy` par mot de passe, éventuellement via l'un des slugs ENT fermés ; - QR/token via `qrcode_login` puis `token_login`. - des valeurs précises (durée de sessions, validité de dix minutes, persistance des anciens tokens, statut « officiel ») sont formulées comme des faits, sans source ni version de bibliothèque associée. Le contrat local vérifiable est `pronotepy 2.15.7` : ses méthodes `qrcode_login`, `token_login` et `export_credentials` définissent les paramètres réellement disponibles pour cette intégration. ## Proposition Refondre ce document en référence traçable et orientée exploitation : 1. supprimer les annexes dupliquées ; 2. ajouter des liens/citations datés vers chaque source primaire ou communautaire utilisée ; 3. qualifier explicitement chaque affirmation : documentée officiellement, observée dans une version de bibliothèque, ou hypothèse à valider ; 4. ajouter un tableau « pris en charge par `pronote-sync` / délégable à `pronotepy` / non implémenté » ; 5. remplacer le parcours QR ambigu par une procédure unique, reproductible et alignée sur les variables `PRONOTE_QR_CODE_FILE`, `PRONOTE_QR_PIN` et la version épinglée/testée de `pronotepy` ; 6. indiquer que les expirations et comportements de rotation sont propres à l'instance et nécessitent un essai réel avant une promesse de support. ## Critères d'acceptation - Une seule occurrence de chaque annexe et tableau récapitulatif. - Chaque délai, statut ou détail de protocole non garanti par le projet a une source, une date de consultation et un niveau de confiance. - Le tableau de compatibilité reflète le code et les tests actuels, sans suggérer qu'une implémentation CAS/SAML/EduConnect générique est incluse. - La procédure QR ne contredit ni `.env.example`, ni la documentation d'exploitation, ni la signature de `pronotepy` effectivement installée. - Le document rappelle que le premier essai sur l'instance Pronote concernée est nécessaire et qu'aucun secret/QR/token ne doit être copié dans les exemples. ## Périmètre Documentation uniquement ; ce ticket ne demande pas de modifier le protocole Pronote ni de contourner un mécanisme d'authentification.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: AntoineVe/college-infos#10