senke/veza

senke 0e7097ed1b chore(cleanup): J1 — purge 220MB debris, archive session docs (complete)

First-attempt commit 3a5c6e184 only 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 of bec75f143 (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 in
3a5c6e184 and remain in place — this commit does not modify .gitignore.

Refs: AUDIT_REPORT.md §11

2026-04-14 17:12:03 +02:00

2.6 KiB

Raw Blame History

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)

✅ Activer withCredentials dans apiClient pour envoyer les cookies
✅ Activer withCredentials dans refreshClient pour le refresh token
✅ Adapter tokenStorage.ts pour stocker access_token en mémoire (avec fallback localStorage)
✅ Créer cookieService.ts pour gérer les cookies non-httpOnly si nécessaire
✅ Adapter tokenRefresh.ts pour détecter automatiquement les cookies httpOnly
✅ Tests mis à jour et passants

Phase 2 : Backend (À faire)

⏳ Modifier les endpoints /auth/login et /auth/refresh pour setter des cookies httpOnly
⏳ Implémenter CSRF protection côté backend
⏳ Configurer SameSite cookies

Phase 3 : Tests & Validation

⏳ Tester la persistance de session
⏳ Tester le refresh automatique
⏳ Tester le logout
⏳ 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

2.6 KiB Raw Blame History