0e7097ed1b
First-attempt commit3a5c6e184only captured the .gitignore change; the pre-commit hook silently dropped the 343 staged moves/deletes during lint-staged's "no matching task" path. This commit re-applies the intended J1 content on top ofbec75f143(which was pushed in parallel). Uses --no-verify because: - J1 only touches .md/.json/.log/.png/binaries — zero code that would benefit from lint-staged, typecheck, or vitest - The hook demonstrated it corrupts pure-rename commits in this repo - Explicitly authorized by user for this one commit Changes (343 total: 169 deletions + 174 renames): Binaries purged (~167 MB): - veza-backend-api/{server,modern-server,encrypt_oauth_tokens,seed,seed-v2} Generated reports purged: - 9 apps/web/lint_report*.json (~32 MB) - 8 apps/web/tsc_*.{log,txt} + ts_*.log (TS error snapshots) - 3 apps/web/storybook_*.json (1375+ stored errors) - apps/web/{build_errors*,build_output,final_errors}.txt - 70 veza-backend-api/coverage*.out + coverage_groups/ (~4 MB) - 3 veza-backend-api/internal/handlers/*.bak Root cleanup: - 54 audit-*.png (visual regression baselines, ~11 MB) - 9 stale MVP-era scripts (Jan 27, hardcoded v0.101): start_{iteration,mvp,recovery}.sh, test_{mvp_endpoints,protected_endpoints,user_journey}.sh, validate_v0101.sh, verify_logs_setup.sh, gen_hash.py Session docs archived (not deleted — preserved under docs/archive/): - 78 apps/web/*.md → docs/archive/frontend-sessions-2026/ - 43 veza-backend-api/*.md → docs/archive/backend-sessions-2026/ - 53 docs/{RETROSPECTIVE_V,SMOKE_TEST_V,PLAN_V0_,V0_*_RELEASE_SCOPE, AUDIT_,PLAN_ACTION_AUDIT,REMEDIATION_PROGRESS}*.md → docs/archive/v0-history/ README.md and CONTRIBUTING.md preserved in apps/web/ and veza-backend-api/. Note: The .gitignore rules preventing recurrence were already pushed in3a5c6e184and remain in place — this commit does not modify .gitignore. Refs: AUDIT_REPORT.md §11
61 lines
2.6 KiB
Markdown
61 lines
2.6 KiB
Markdown
# Migration vers Cookies httpOnly - Plan d'Action
|
|
|
|
## 🎯 Objectif
|
|
Migrer le stockage des tokens d'authentification de `localStorage` vers des cookies `httpOnly` pour améliorer la sécurité contre les attaques XSS.
|
|
|
|
## 📋 Architecture Cible
|
|
|
|
### Tokens
|
|
- **Access Token** : Stocké en mémoire uniquement (pas de localStorage, pas de cookie)
|
|
- **Refresh Token** : Stocké dans un cookie `httpOnly`, `secure`, `sameSite=strict`
|
|
|
|
### Sécurité
|
|
- ✅ Protection XSS : Les cookies httpOnly ne sont pas accessibles via JavaScript
|
|
- ✅ Protection CSRF : SameSite=strict empêche l'envoi cross-site
|
|
- ✅ HTTPS only : Secure flag force HTTPS en production
|
|
|
|
## 🔄 Plan de Migration
|
|
|
|
### Phase 1 : Préparation Frontend (✅ Complétée)
|
|
1. ✅ Activer `withCredentials` dans `apiClient` pour envoyer les cookies
|
|
2. ✅ Activer `withCredentials` dans `refreshClient` pour le refresh token
|
|
3. ✅ Adapter `tokenStorage.ts` pour stocker access_token en mémoire (avec fallback localStorage)
|
|
4. ✅ Créer `cookieService.ts` pour gérer les cookies non-httpOnly si nécessaire
|
|
5. ✅ Adapter `tokenRefresh.ts` pour détecter automatiquement les cookies httpOnly
|
|
6. ✅ Tests mis à jour et passants
|
|
|
|
### Phase 2 : Backend (À faire)
|
|
1. ⏳ Modifier les endpoints `/auth/login` et `/auth/refresh` pour setter des cookies httpOnly
|
|
2. ⏳ Implémenter CSRF protection côté backend
|
|
3. ⏳ Configurer SameSite cookies
|
|
|
|
### Phase 3 : Tests & Validation
|
|
1. ⏳ Tester la persistance de session
|
|
2. ⏳ Tester le refresh automatique
|
|
3. ⏳ Tester le logout
|
|
4. ⏳ Tester la compatibilité avec les tests E2E
|
|
|
|
## 🔧 Changements Techniques
|
|
|
|
### 1. Service de Gestion des Cookies
|
|
Créer `cookieService.ts` pour gérer les cookies côté client (uniquement pour les cookies non-httpOnly si nécessaire).
|
|
|
|
### 2. Modification de `tokenStorage.ts`
|
|
- Supprimer le stockage du refresh token dans localStorage
|
|
- Garder uniquement l'access token en mémoire
|
|
- Le refresh token sera géré automatiquement par le navigateur via cookies
|
|
|
|
### 3. Modification de `apiClient.ts`
|
|
- Activer `withCredentials: true` pour envoyer les cookies automatiquement
|
|
- Supprimer l'envoi manuel du refresh token dans les headers
|
|
|
|
### 4. Modification de `auth.ts`
|
|
- Ne plus stocker le refresh token dans localStorage après login
|
|
- Le backend settera le cookie automatiquement
|
|
|
|
## ⚠️ Notes Importantes
|
|
|
|
- **Compatibilité** : Le système actuel continuera de fonctionner jusqu'à ce que le backend soit prêt
|
|
- **Migration progressive** : On peut activer les cookies progressivement
|
|
- **Tests** : Tous les tests doivent être mis à jour pour gérer les cookies
|
|
|