_Assistant_Lead_Tech/knowledge/frontend/risques/auth.md

# Frontend — Risques & vigilance : Auth

> Extrait de la base de connaissance Lead_tech. Voir `knowledge/frontend/risques/README.md` pour l'index complet.

---

<a id="risque-auth-cote-client"></a>
## Auth côté client (mauvaise séparation des responsabilités)

### Risques

- Le front "décide" des permissions au lieu d'appliquer un contrat backend
- Affichage d'actions interdites / fuite d'informations dans l'UI
- Tokens stockés de façon dangereuse (XSS)

### Symptômes

- Différences entre "ce que l'UI permet" et "ce que l'API accepte"
- Bugs "ça marche chez moi" selon sessions/rôles
- Incohérences sur refresh / multi-tab

### Bonnes pratiques / mitigations

- Le backend reste source de vérité (authz)
- Cacher l'UI ≠ sécuriser : toujours sécuriser côté API
- Stockage tokens : privilégier cookies httpOnly si modèle adapté
- Gérer proprement expiration/refresh + révocation

### Contexte technique

- Observé : (à compléter)
- Stack : (à préciser)

---

<a id="risque-loading-infini-ecran-gated"></a>
## Loading infini sur écran gated par droits distants

### Risques

- Un écran protégé reste bloqué dans un faux `loading` après une erreur de chargement des entitlements
- Un effet relance automatiquement la récupération en boucle sans action utilisateur
- L'utilisateur ne voit ni état d'erreur ni issue de sortie claire

### Symptômes

- Spinner infini sur un écran soumis à permissions distantes
- `entitlements` ou autorisations laissés à `null` après erreur
- `useEffect` ou logique d'entrée qui retrigger le fetch à chaque rendu

### Bonnes pratiques / mitigations

- Distinguer explicitement `loading`, `error`, `ready`
- Ne pas réutiliser `null` comme état ambigu "pas encore chargé" et "chargement en erreur"
- Bloquer les retries automatiques en boucle après erreur
- Réautoriser un retry seulement via action utilisateur explicite ou nouvelle condition d'entrée
- Contexte technique : React Native / Expo / store d'entitlements — 10-03-2026

---

<a id="risque-oauth-handler-vide"></a>
## Bouton OAuth présent mais handler vide après refacto UI

### Risques

- L'OAuth est silencieusement cassé sur le nouvel écran — zéro erreur au démarrage, zéro crash
- L'AC "toutes les fonctionnalités préservées" peut être coché alors que le bouton est mort

### Symptômes

- `<Button title="Google" onPress={() => {}} />` — handler vide après copie depuis un ancien écran
- OAuth fonctionnel sur l'écran précédent (`welcome.tsx`) mais absent sur le nouvel écran refactorisé

### Bonnes pratiques / mitigations

- Toute refacto UI qui introduit un bouton OAuth doit brancher le hook existant (`useGoogleAuth(onSuccess)`)
- Si la story exclut explicitement la fonctionnalité : soit le bouton n'apparaît pas, soit `disabled` avec un label explicite ("bientôt disponible")
- **Checklist review** : chercher `onPress={() => {}}` sur tous les boutons OAuth dans les écrans refactorisés
- Contexte technique : Expo Router / React Native — app-alexandrie story 0.3, 19-03-2026

---

<a id="risque-guard-role-return-conditionnel"></a>
## Guard de rôle via return conditionnel dans le render (flash UX)

### Risques

- `if (user?.role !== 'ADMIN') return <AccessDenied />` directement dans le corps du composant : pendant le chargement du store auth, `user` est `null`, ce qui déclenche un affichage momentané de l'écran "Accès refusé" avant le re-render
- UX instable : flash visible, potentiellement suivi d'une boucle de re-render

### Symptômes

- L'écran "Accès refusé" clignote brièvement au montage avant d'afficher le bon contenu
- Bug reproductible uniquement au chargement initial ou après un reload

### Bonnes pratiques / mitigations

```typescript
// ❌ Anti-pattern — flash si user === null au montage
if (user?.role !== 'ADMIN') return <AccessDenied />;

// ✅ Pattern correct — useEffect + rendu vide pendant chargement
useEffect(() => {
  if (user !== null && user.role !== 'ADMIN') {
    router.replace('/(tabs)');
  }
}, [user, router]);

if (user === null || user.role !== 'ADMIN') return <View />;
```

- **Règle** : tout guard de rôle dans un composant React Native doit utiliser `useEffect` + redirect + rendu vide, jamais un return conditionnel direct

- Contexte technique : React Native / Expo Router / Zustand auth — app-alexandrie 24-03-2026

---

<a id="risque-tests-structurels-obsoletes-migration-auth"></a>
## Tests structurels obsolètes après migration du mécanisme d'auth

### Risques

- Lors de la migration d'un pattern `Authorization: Bearer` vers des cookies httpOnly, les tests structurels (qui mocquent `getSession()` et assertent sur les headers) deviennent tous faux sans que TypeScript ne détecte rien
- Les mocks ne matchent plus le code réel, les tests passent ou échouent silencieusement

### Symptômes

- Tests frontend qui mocquent `getSession()` et assertent `Authorization: Bearer` sur les appels `fetch`, alors que le code utilise désormais `apiFetch` avec cookies (`credentials: 'include'`)
- Faux positifs : les tests ne testent plus rien de réel

### Bonnes pratiques / mitigations

- Après toute migration d'un mécanisme d'auth frontend, auditer systématiquement les tests de services pour vérifier que les assertions portent sur le bon mécanisme (cookies vs headers)
- Adapter les mocks pour patcher `apiFetch` au lieu de `getSession` + `fetch` brut
- **Signal review** : `Authorization: Bearer` dans les tests alors que le code production utilise `credentials: 'include'`

- Contexte technique : Vue 3 / auth migration — RL799_V2 08-04-2026

---

<a id="risque-auth-me-fallback-localstorage"></a>
## Migration vers `/auth/me` — fallback localStorage réintroduit une confiance client

### Risques
- Un blocage réseau ciblé peut forcer un fallback sur des données locales falsifiables.

### Symptômes
- Rôle/grade consommés depuis localStorage en cas d'erreur endpoint d'autorité.

### Bonnes pratiques / mitigations
- Si l'endpoint d'autorité échoue, conserver un état non authentifié/dégradé, pas un fallback de privilèges.
- Garder localStorage strictement pour métadonnées UX non sensibles.

- Contexte technique : auth frontend / source d'autorité — RL799_V2 18-04-2026

---

<a id="risque-auth-store-source-verite-bypass-service"></a>
## Source de vérité auth déplacée vers store, appels directs service laissés en place

### Risques
- Guards/router lisent un état store non synchronisé après login/logout.

### Symptômes
- Login réussi puis redirection immédiate vers `/login`.

### Bonnes pratiques / mitigations
- Interdire les appels directs au service auth depuis les pages une fois le store source de vérité.
- Centraliser login/logout/change-password via actions store.

- Contexte technique : auth frontend / Pinia store — RL799_V2 18-04-2026

---