Der Login auf der Instanz war vollständig kaputt: jede/api/auth/*-Route antwortete mit 500 {"message":"There was a problem with the server configuration."}. Im Browser äußerte sich das so, dass nach dem Absenden des Login-Formulars ohne jede Fehlermeldung wieder das Login-Formular erschien.
Ursache war ein Next.js-Dev-Server, der aus apps/web gestartet war. Next.js lädt in dem Fall nur apps/web/.env* — das Monorepo-Root-.env mit den Auth-Secrets wird nie gelesen. Der Prozess lief damit ganz ohneAUTH_SECRET/NEXTAUTH_SECRET. Ohne Secret kann Auth.js keine Session-JWTs signieren, also scheitert jede Auth-Route.
Auffallen konnte das nicht: getRuntimeEnvViolations() stieg bei jedem NODE_ENV !== "production" sofort mit return [] aus. Der Server startete also sauber und lieferte erst zur Laufzeit undurchsichtige 500er, deren Meldung nicht im Entferntesten auf die Ursache zeigt.
Änderungen
Zwei Prüfungen laufen jetzt unabhängig von NODE_ENV:
1. Ein Auth-Secret muss vorhanden sein. Sein Fehlen ist überall fatal, weil ohne Secret nichts an Auth funktioniert. Der Start bricht mit einer lesbaren Zeile ab, statt still eine kaputte Instanz zu servieren.
Die produktionsspezifischen Härtungsregeln bleiben unverändert: Mindestlänge, Shannon-Entropie und die Platzhalter-Blockliste greifen weiterhin nur in Production. Ein kurzes Dev-Secret ist also weiter erlaubt — nur gar keins nicht mehr.
2. E2E_TEST_MODE=true ist bei https-Deployment verboten. Eine https-URL bedeutet, dass die Instanz von außen erreichbar ist, unabhängig davon was NODE_ENV behauptet. Das Flag schaltet laut auth.ts das Login-Rate-Limiting und die active_sessions-Registrierung inklusive Limit für parallele Sessions ab. Der Production-Fall bleibt bei getDevBypassViolations().
assertSecureRuntimeEnv() kann nun auch außerhalb von Production auslösen, daher entfällt das irreführende "production" in der Fehlermeldung.
Tests
Vier neue Fälle, darunter ein Regressionstest, der exakt den aufgetretenen Fehler festhält (Development ohne Secret muss eine Violation liefern), sowie die Absicherung, dass die Stärke-Regeln in Dev nicht greifen.
Verifiziert wurde zusätzlich end-to-end per Playwright gegen die laufende Instanz: POST /api/auth/callback/credentials liefert wieder 200 mit gesetztem __Host-authjs.session-token, /api/auth/session gibt den User zurück, und der Browser landet auf /dashboard.
Nicht Teil dieses PRs
Die konkrete Instanz hatte E2E_TEST_MODE=true im gitignorierten Root-.env stehen; das wurde lokal auf false gesetzt. Auf anderen Maschinen und beim Deployment muss das separat geprüft werden. Der Default in docker-compose.yml:71 ist bereits korrekt false. Dank Änderung 2 verweigert die App dort jetzt aber sichtbar den Start, statt still ohne Rate-Limiting zu laufen.
## Problem
Der Login auf der Instanz war vollständig kaputt: **jede** `/api/auth/*`-Route antwortete mit `500 {"message":"There was a problem with the server configuration."}`. Im Browser äußerte sich das so, dass nach dem Absenden des Login-Formulars ohne jede Fehlermeldung wieder das Login-Formular erschien.
Ursache war ein Next.js-Dev-Server, der aus `apps/web` gestartet war. Next.js lädt in dem Fall nur `apps/web/.env*` — das Monorepo-Root-`.env` mit den Auth-Secrets wird nie gelesen. Der Prozess lief damit **ganz ohne** `AUTH_SECRET`/`NEXTAUTH_SECRET`. Ohne Secret kann Auth.js keine Session-JWTs signieren, also scheitert jede Auth-Route.
Auffallen konnte das nicht: `getRuntimeEnvViolations()` stieg bei jedem `NODE_ENV !== "production"` sofort mit `return []` aus. Der Server startete also sauber und lieferte erst zur Laufzeit undurchsichtige 500er, deren Meldung nicht im Entferntesten auf die Ursache zeigt.
## Änderungen
Zwei Prüfungen laufen jetzt unabhängig von `NODE_ENV`:
**1. Ein Auth-Secret muss vorhanden sein.** Sein Fehlen ist überall fatal, weil ohne Secret nichts an Auth funktioniert. Der Start bricht mit einer lesbaren Zeile ab, statt still eine kaputte Instanz zu servieren.
Die produktionsspezifischen Härtungsregeln bleiben unverändert: Mindestlänge, Shannon-Entropie und die Platzhalter-Blockliste greifen weiterhin **nur** in Production. Ein kurzes Dev-Secret ist also weiter erlaubt — nur gar keins nicht mehr.
**2. `E2E_TEST_MODE=true` ist bei https-Deployment verboten.** Eine https-URL bedeutet, dass die Instanz von außen erreichbar ist, unabhängig davon was `NODE_ENV` behauptet. Das Flag schaltet laut `auth.ts` das Login-Rate-Limiting und die `active_sessions`-Registrierung inklusive Limit für parallele Sessions ab. Der Production-Fall bleibt bei `getDevBypassViolations()`.
`assertSecureRuntimeEnv()` kann nun auch außerhalb von Production auslösen, daher entfällt das irreführende "production" in der Fehlermeldung.
## Tests
Vier neue Fälle, darunter ein Regressionstest, der exakt den aufgetretenen Fehler festhält (Development ohne Secret muss eine Violation liefern), sowie die Absicherung, dass die Stärke-Regeln in Dev *nicht* greifen.
```
pnpm test:unit 7/7 Tasks, 1945 Tests ok
tsc --noEmit exit 0
pnpm lint 0 errors
```
Verifiziert wurde zusätzlich end-to-end per Playwright gegen die laufende Instanz: `POST /api/auth/callback/credentials` liefert wieder 200 mit gesetztem `__Host-authjs.session-token`, `/api/auth/session` gibt den User zurück, und der Browser landet auf `/dashboard`.
## Nicht Teil dieses PRs
Die konkrete Instanz hatte `E2E_TEST_MODE=true` im gitignorierten Root-`.env` stehen; das wurde lokal auf `false` gesetzt. **Auf anderen Maschinen und beim Deployment muss das separat geprüft werden.** Der Default in `docker-compose.yml:71` ist bereits korrekt `false`. Dank Änderung 2 verweigert die App dort jetzt aber sichtbar den Start, statt still ohne Rate-Limiting zu laufen.
🤖 Generated with [claude-flow](https://github.com/ruvnet/claude-flow)
A dev server started from apps/web never loads the monorepo root .env, so it
came up with no AUTH_SECRET/NEXTAUTH_SECRET at all. getRuntimeEnvViolations()
returned early for every non-production NODE_ENV, so nothing complained —
Auth.js then answered *every* /api/auth/* route with an opaque 500 ("problem
with the server configuration"). The login form swallowed that silently and
bounced the user back to itself with no error, pointing nowhere near the cause.
Two checks now run regardless of NODE_ENV:
- An auth secret must be present. Its absence is fatal everywhere, because
without it Auth.js cannot sign session JWTs and nothing about auth works.
The production-only strength rules (length, entropy, known placeholders)
are unchanged — a weak secret still only fails production.
- E2E_TEST_MODE must not be "true" when the deployment URL is https. An https
URL means the instance is reachable off the machine whatever NODE_ENV says,
and that flag disables login rate limiting and the concurrent-session
registry. The production case stays with getDevBypassViolations().
assertSecureRuntimeEnv() can now fire outside production, so its message drops
the inaccurate "production".
Co-Authored-By: claude-flow <ruv@ruv.net>
.gitignore matched .env and .env.*.local but not the copies people and tools
actually leave behind — .env.bak-20260911, .env.save, .env.orig. Those carry
the identical secrets and showed up as untracked, one `git add .` away from
being committed. Patterns verified with git check-ignore.
The .claude/settings.json entry stops Claude Code prompting for confirmation
on every docker/docker compose invocation during local debugging.
Co-Authored-By: claude-flow <ruv@ruv.net>
Some required checks failed
CI / Architecture Guardrails (pull_request) Failing after 4m37s
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
Der Login auf der Instanz war vollständig kaputt: jede
/api/auth/*-Route antwortete mit500 {"message":"There was a problem with the server configuration."}. Im Browser äußerte sich das so, dass nach dem Absenden des Login-Formulars ohne jede Fehlermeldung wieder das Login-Formular erschien.Ursache war ein Next.js-Dev-Server, der aus
apps/webgestartet war. Next.js lädt in dem Fall nurapps/web/.env*— das Monorepo-Root-.envmit den Auth-Secrets wird nie gelesen. Der Prozess lief damit ganz ohneAUTH_SECRET/NEXTAUTH_SECRET. Ohne Secret kann Auth.js keine Session-JWTs signieren, also scheitert jede Auth-Route.Auffallen konnte das nicht:
getRuntimeEnvViolations()stieg bei jedemNODE_ENV !== "production"sofort mitreturn []aus. Der Server startete also sauber und lieferte erst zur Laufzeit undurchsichtige 500er, deren Meldung nicht im Entferntesten auf die Ursache zeigt.Änderungen
Zwei Prüfungen laufen jetzt unabhängig von
NODE_ENV:1. Ein Auth-Secret muss vorhanden sein. Sein Fehlen ist überall fatal, weil ohne Secret nichts an Auth funktioniert. Der Start bricht mit einer lesbaren Zeile ab, statt still eine kaputte Instanz zu servieren.
Die produktionsspezifischen Härtungsregeln bleiben unverändert: Mindestlänge, Shannon-Entropie und die Platzhalter-Blockliste greifen weiterhin nur in Production. Ein kurzes Dev-Secret ist also weiter erlaubt — nur gar keins nicht mehr.
2.
E2E_TEST_MODE=trueist bei https-Deployment verboten. Eine https-URL bedeutet, dass die Instanz von außen erreichbar ist, unabhängig davon wasNODE_ENVbehauptet. Das Flag schaltet lautauth.tsdas Login-Rate-Limiting und dieactive_sessions-Registrierung inklusive Limit für parallele Sessions ab. Der Production-Fall bleibt beigetDevBypassViolations().assertSecureRuntimeEnv()kann nun auch außerhalb von Production auslösen, daher entfällt das irreführende "production" in der Fehlermeldung.Tests
Vier neue Fälle, darunter ein Regressionstest, der exakt den aufgetretenen Fehler festhält (Development ohne Secret muss eine Violation liefern), sowie die Absicherung, dass die Stärke-Regeln in Dev nicht greifen.
Verifiziert wurde zusätzlich end-to-end per Playwright gegen die laufende Instanz:
POST /api/auth/callback/credentialsliefert wieder 200 mit gesetztem__Host-authjs.session-token,/api/auth/sessiongibt den User zurück, und der Browser landet auf/dashboard.Nicht Teil dieses PRs
Die konkrete Instanz hatte
E2E_TEST_MODE=trueim gitignorierten Root-.envstehen; das wurde lokal auffalsegesetzt. Auf anderen Maschinen und beim Deployment muss das separat geprüft werden. Der Default indocker-compose.yml:71ist bereits korrektfalse. Dank Änderung 2 verweigert die App dort jetzt aber sichtbar den Start, statt still ohne Rate-Limiting zu laufen.🤖 Generated with claude-flow
1df208d) f80808482dA dev server started from apps/web never loads the monorepo root .env, so it came up with no AUTH_SECRET/NEXTAUTH_SECRET at all. getRuntimeEnvViolations() returned early for every non-production NODE_ENV, so nothing complained — Auth.js then answered *every* /api/auth/* route with an opaque 500 ("problem with the server configuration"). The login form swallowed that silently and bounced the user back to itself with no error, pointing nowhere near the cause. Two checks now run regardless of NODE_ENV: - An auth secret must be present. Its absence is fatal everywhere, because without it Auth.js cannot sign session JWTs and nothing about auth works. The production-only strength rules (length, entropy, known placeholders) are unchanged — a weak secret still only fails production. - E2E_TEST_MODE must not be "true" when the deployment URL is https. An https URL means the instance is reachable off the machine whatever NODE_ENV says, and that flag disables login rate limiting and the concurrent-session registry. The production case stays with getDevBypassViolations(). assertSecureRuntimeEnv() can now fire outside production, so its message drops the inaccurate "production". Co-Authored-By: claude-flow <ruv@ruv.net>View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.