@eqs/auth (délégué) : getAccessToken confond un consentement retiré et une panne du fournisseur, et email_does_not_match ne dit pas l'adresse vue #144

Closed
opened 2026-10-12 11:29:37 +00:00 by nicolas-fryder · 0 comments

Deux constats sur le fournisseur délégué (D-040), vus en branchant HQ dans ATLAS.

1. Deux échecs de rafraîchissement indiscernables

Commande : auth.api.getAccessToken sur un compte délégué dont le jeton d'accès a expiré, contre un point de jeton qui rend 401 {"error":"invalid_grant"}, puis contre un point de jeton qui rend 502.
Attendu : deux causes distinctes. Le consentement retiré appelle « délier » ; la panne appelle « garder la liaison et réessayer ».
Observé : la même APIError FAILED_TO_GET_ACCESS_TOKEN dans les deux cas (lu dans getValidAccessToken, better-auth 1.7.7). Un satellite qui délie sur cette erreur délie tout le monde pendant une panne ; un satellite qui ne délie pas garde des liaisons mortes.
Contournement : ATLAS rafraîchit lui-même par fournisseur.refreshAccessToken, lit l'erreur avant de ranger, et ne garde getAccessToken que pour la lecture.

2. Le refus d'adresse ne nomme pas l'adresse

Commande : lier un compte HQ alors que la session HQ ouverte est celle d'un collègue.
Attendu : le refus porte l'adresse que le fournisseur a rendue (« vous êtes connecté à HQ en tant que X »).
Observé : ?error=email_does_not_match seul — impossible à corriger sans savoir quel compte est ouvert.
Contournement : delegue/temoin.ts enveloppe getUserInfo du fournisseur monté (AsyncLocalStorage) ; fragile si better-auth clone ses fournisseurs.

Versions

@eqs/auth 0.20.0, better-auth 1.7.7.

Ouvert depuis le rejeu du rétrofit d'ATLAS (étape 5b).

Deux constats sur le fournisseur délégué (D-040), vus en branchant HQ dans ATLAS. ## 1. Deux échecs de rafraîchissement indiscernables **Commande** : `auth.api.getAccessToken` sur un compte délégué dont le jeton d'accès a expiré, contre un point de jeton qui rend `401 {"error":"invalid_grant"}`, puis contre un point de jeton qui rend `502`. **Attendu** : deux causes distinctes. Le consentement retiré appelle « délier » ; la panne appelle « garder la liaison et réessayer ». **Observé** : la même `APIError` `FAILED_TO_GET_ACCESS_TOKEN` dans les deux cas (lu dans `getValidAccessToken`, better-auth 1.7.7). Un satellite qui délie sur cette erreur délie tout le monde pendant une panne ; un satellite qui ne délie pas garde des liaisons mortes. **Contournement** : ATLAS rafraîchit lui-même par `fournisseur.refreshAccessToken`, lit l'erreur avant de ranger, et ne garde `getAccessToken` que pour la lecture. ## 2. Le refus d'adresse ne nomme pas l'adresse **Commande** : lier un compte HQ alors que la session HQ ouverte est celle d'un collègue. **Attendu** : le refus porte l'adresse que le fournisseur a rendue (« vous êtes connecté à HQ en tant que X »). **Observé** : `?error=email_does_not_match` seul — impossible à corriger sans savoir quel compte est ouvert. **Contournement** : `delegue/temoin.ts` enveloppe `getUserInfo` du fournisseur monté (`AsyncLocalStorage`) ; fragile si better-auth clone ses fournisseurs. ## Versions @eqs/auth 0.20.0, better-auth 1.7.7. *Ouvert depuis le rejeu du rétrofit d'ATLAS (étape 5b).*
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Infrastructure/eqs-platform#144
No description provided.