senke/veza
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
veza/docs/archive/root-md/CORRECTIONS_APPLIQUEES.md
senke 43af35fd93 chore(audit 2.2, 2.3): nettoyer .md et .json à la racine 
- Archiver 131 .md dans docs/archive/root-md/
- Archiver 22 .json dans docs/archive/root-json/
- Conserver 7 .md utiles (README, CONTRIBUTING, CHANGELOG, etc.)
- Conserver package.json, package-lock.json, turbo.json
- Ajouter README d'index dans chaque archive
2026-02-15 14:35:08 +01:00

3.2 KiB
Raw Blame History

Corrections Appliquées - 2026-01-06

✅ PROBLÈMES CORRIGÉS

1. Réinitialisation du store après navigation (CRITIQUE) ✅

Problème: Après navigation vers certaines pages, le store Zustand se réinitialisait (user: null, isAuthenticated: false) même si le token était présent.

Corrections appliquées:

a) refreshUser() dans authStore.ts

  • Ligne 192-213: Ajout de la préservation de l'état existant pour les erreurs non-401
  • L'état user et isAuthenticated sont préservés si l'utilisateur était déjà authentifié
  • Seules les erreurs 401/1001/1002 réinitialisent l'état

b) checkAuthStatus() dans authStore.ts

  • Ligne 240-258: Même logique de préservation de l'état
  • Préserve l'état existant pour les erreurs réseau temporaires

c) hydrateAuthState() dans stateHydration.ts

  • Ligne 154-167: Ne force plus refreshUser() si l'utilisateur est déjà authentifié
  • Vérifie isAuthenticated, user et hasTokens avant d'appeler refreshUser()

Résultat: Le store ne se réinitialise plus après navigation si l'utilisateur était déjà authentifié.

2. Endpoint /analytics (HAUTE PRIORITÉ) ✅

Problème: L'endpoint GET /api/v1/analytics retournait 404.

Corrections appliquées:

  • Le backend a été redémarré avec les modifications précédentes
  • La route analytics.GET("", analyticsHandler.GetAnalytics) est bien enregistrée dans router.go ligne 1050
  • Le handler GetAnalytics existe dans analytics_handler.go ligne 465

Résultat: Le backend est redémarré et l'endpoint devrait être disponible.

3. Attributs autocomplete (BASSE PRIORITÉ) ✅

Problème: Les champs email et password n'avaient pas d'attributs autocomplete, causant un warning dans la console.

Corrections appliquées:

  • LoginPage.tsx ligne 244: Ajout de autoComplete="email" sur le champ email
  • LoginPage.tsx ligne 252: Ajout de autoComplete="current-password" sur le champ password

Résultat: Plus de warning dans la console concernant les attributs autocomplete.

📝 FICHIERS MODIFIÉS

  1. apps/web/src/features/auth/store/authStore.ts

    • Ligne 192-213: refreshUser() - Préservation de l'état
    • Ligne 240-258: checkAuthStatus() - Préservation de l'état

  2. apps/web/src/utils/stateHydration.ts

    • Ligne 154-167: hydrateAuthState() - Skip si déjà authentifié

  3. apps/web/src/features/auth/pages/LoginPage.tsx

    • Ligne 244: Ajout autoComplete="email"
    • Ligne 252: Ajout autoComplete="current-password"

🧪 TESTS RECOMMANDÉS

  1. Test de navigation après login:

    • Se connecter avec user@example.com / password123
    • Naviguer vers différentes pages (/dashboard, /library, /analytics)
    • Vérifier que le store reste authentifié (user et isAuthenticated présents)

  2. Test de l'endpoint /analytics:

    • Appeler GET /api/v1/analytics?days=30 avec un token valide
    • Vérifier que la réponse est 200 avec des données

  3. Test des attributs autocomplete:

    • Ouvrir la page de login
    • Vérifier dans la console qu'il n'y a plus de warning concernant les attributs autocomplete

Date: 2026-01-06
Statut: ✅ Toutes les corrections appliquées