senke/veza
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
veza/docs/archive/backend-sessions-2026/MIGRATION_HTTPONLY_COOKIES_STATUS.md
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

3.4 KiB
Raw Blame History

Migration httpOnly Cookies - Statut d'Implémentation

✅ Modifications Complétées

1. Handler Login ✅

  • Fichier: internal/handlers/auth.go
  • Ligne: ~121-133
  • Changements:
    • ✅ Cookie httpOnly setter avec http.Cookie et http.SetCookie
    • ✅ SameSite=Strict configuré
    • ✅ Secure=true (HTTPS only)
    • ✅ RefreshToken retiré du body JSON
    • ✅ Durée: 30 jours (90 jours si remember_me)

2. Handler Refresh ✅

  • Fichier: internal/handlers/auth.go
  • Ligne: ~295-384
  • Changements:
    • ✅ Lecture du refresh token depuis cookie (priorité) ou body JSON (fallback)
    • ✅ Cookie httpOnly setter avec nouveau refresh token
    • ✅ SameSite=Strict configuré
    • ✅ Secure=true (HTTPS only)
    • ✅ RefreshToken retiré du body JSON
    • ✅ Durée: 30 jours

3. Handler Register ✅

  • Fichier: internal/handlers/auth.go
  • Ligne: ~231-279
  • Changements:
    • ✅ Cookie httpOnly setter avec http.Cookie et http.SetCookie
    • ✅ SameSite=Strict configuré
    • ✅ Secure=true (HTTPS only)
    • ✅ RefreshToken retiré du body JSON
    • ✅ Durée: 30 jours

4. Handler Logout ✅

  • Fichier: internal/handlers/auth.go
  • Ligne: ~350-390
  • Changements:
    • ✅ Cookie refresh_token supprimé (MaxAge=-1)
    • ✅ SameSite=Strict configuré
    • ✅ Secure=true (HTTPS only)

🔄 Compatibilité

Mode Hybride

Le système fonctionne en mode hybride pour assurer la compatibilité :

  • Refresh Token: Peut venir du cookie httpOnly (nouveau) ou du body JSON (legacy)
  • Frontend: Détecte automatiquement les cookies httpOnly
  • Backend: Accepte les deux formats pendant la transition

Frontend Prêt

  • ✅ withCredentials: true activé dans apiClient
  • ✅ tokenRefresh.ts détecte automatiquement les cookies httpOnly
  • ✅ Mode hybride fonctionnel

⚠️ Notes Importantes

  1. Secure Flag: Actuellement true (HTTPS only). En développement local, peut nécessiter false si HTTP utilisé.
  2. SameSite: Configuré à Strict pour sécurité maximale. Peut nécessiter Lax si cross-domain.
  3. Domain: Laissé vide (domaine actuel). À configurer si cross-domain nécessaire.

🧪 Tests à Créer

Tests Unitaires

  • Test Login avec cookie httpOnly
  • Test Refresh avec cookie httpOnly
  • Test Register avec cookie httpOnly
  • Test Logout supprime cookie
  • Test Refresh avec fallback body JSON (legacy)

Tests d'Intégration

  • Test persistance de session avec cookies
  • Test refresh automatique avec cookies
  • Test logout supprime cookie
  • Test compatibilité avec frontend

Tests E2E

  • Test login → refresh → logout flow complet
  • Test persistance de session après refresh navigateur
  • Test logout supprime cookie et invalide session

📝 Prochaines Étapes

  1. Tests: Créer les tests unitaires et d'intégration
  2. Configuration: Ajouter variables d'environnement pour Secure/SameSite si nécessaire
  3. Documentation: Mettre à jour la documentation API
  4. Déploiement: Tester en staging avant production

🔧 Configuration Environnement (Optionnel)

Pour permettre la configuration via variables d'environnement :

// Dans config ou env
cookieSecure := os.Getenv("COOKIE_SECURE") == "true"
cookieSameSite := http.SameSiteStrictMode
if os.Getenv("COOKIE_SAME_SITE") == "lax" {
    cookieSameSite = http.SameSiteLaxMode
}