Gå til indholdet

ADR 0001 — Fjern legacy-JWT-resterne efter Better Auth-migreringen

Status: Besluttet (juni 2026) Kontekst: docs/STATUS-AUDIT.md §5 punkt 6

Kontekst

Platformen migrerede fra egen JWT-auth til Better Auth (cookie-baserede sessions). Migreringen efterlod:

  • services/auth.service.ts + controllers/auth.controller.ts + routes/auth.routes.ts — hele den gamle auth-kæde. Router-filen var ikke mountet i routes/index.ts, så koden var død.
  • Schema-felter på users: verificationToken, resetPasswordToken, resetPasswordExpires, refreshToken.
  • Dobbelt-secret: BETTER_AUTH_SECRET || JWT_SECRET || '' i config/auth.ts, og JWT_SECRET som påkrævet env-var.

Verifikation før fjernelse (hvad bruger faktisk hvad?)

Forbruger Bruger legacy-JWT? Faktisk mekanisme
HTTP-API Nej authenticate-middleware kalder auth.api.getSession() med request-cookies (Better Auth)
Socket.io Nej config/socket.ts læser Better Auth-session fra handshake-cookies (fromNodeHeaders) — ingen token i query/headers
OnlyOffice Nej — egen, separat secret workroom.controller.ts signerer/verificerer med ONLYOFFICE_JWT_SECRET via jsonwebtoken. Dette er Document Server-protokollens JWT og er uafhængig af bruger-auth. Beholdes.
Frontend Nej axios med withCredentials (cookies); ingen Bearer-tokens (utils/api.ts)

Konklusion: Intet i den kørende app brugte JWT_SECRET eller de fire schema-felter. jsonwebtoken-pakken beholdes alene til OnlyOffice-protokollen.

Beslutning

  1. Slet den døde auth-kæde (auth.service.ts, auth.controller.ts, auth.routes.ts; types/auth.ts reduceret til det der faktisk bruges).
  2. Migration 20260610120000_remove_legacy_jwt_fields dropper verificationToken, resetPasswordToken, resetPasswordExpires og refreshToken på users. (Better Auths egne Account.refreshToken- felter er urørte.) Migrationen er testet mod en kopi af produktionsdata.
  3. BETTER_AUTH_SECRET er nu påkrævet ved boot; koden læser ikke længere JWT_SECRET. docker-compose beholder BETTER_AUTH_SECRET=${BETTER_AUTH_SECRET:-${JWT_SECRET}} så eksisterende deployments, der kun har sat JWT_SECRET, beholder deres effektive session-secret uden geninstallation.

Konsekvenser

  • Ingen sessions invalideres: den effektive secret er uændret i alle miljøer (CI/prod har BETTER_AUTH_SECRET sat; compose-fallback dækker resten).
  • email.service.ts (verifikations-/reset-mails) har ikke længere nogen kaldere — den beholdes som grundlag for en kommende Better Auth emailVerification-opkobling, men kan slettes hvis den ikke tages i brug.
  • Nye instanser skal sætte BETTER_AUTH_SECRET (fail-fast ellers).