Florian Wilde
2e8681abf5
/api/gesundheit steht in der Allowlist des Proxys, damit ein Healthcheck kein
Cookie braucht. Eine Meldung von Prisma oder pg nennt aber Host, Port,
Benutzernamen und Datenbanknamen -- fuer einen Pfad, der ohne Anmeldung
antwortet, ist das zu viel.
Nach aussen bleibt {"status":"fehler"} mit 503, damit Docker und der Reverse
Proxy weiter richtig entscheiden. Die Begruendung geht ins Protokoll des
Prozesses, nach demselben Muster wie in src/server/actions/verzeichnis.ts.
Fuenf Tests, darunter einer fuer die andere Haelfte der Zusage: dass die
Begruendung wirklich geschrieben und nicht verschluckt wird. Gegenprobe
gefahren -- mit der alten Fassung werden drei davon rot.
Closes #39
1.3 KiB
1.3 KiB
#025 Healthcheck gibt die rohe Datenbankfehlermeldung heraus
Status: erledigt Im Tracker: #39 Meilenstein: v0.2.0 Labels: phase-2, backend Geschätzt: 1 h Tatsächlich: 25 min
Ziel
src/app/api/gesundheit/route.ts antwortet im Fehlerfall mit
{ "status": "fehler", "meldung": "<fehler.message>" }
Der Pfad ist absichtlich ohne Anmeldung erreichbar — er steht in der Allowlist des Proxys, und
tests/sicherheitsrichtlinie.test.ts hält das fest. Eine Fehlermeldung von Prisma oder pg nennt
typischerweise Host, Port, Benutzername und Datenbanknamen. Das ist für einen öffentlich erreichbaren
Endpunkt zu viel: er soll sagen, ob es geht, nicht warum nicht.
Aufgefallen beim Abnahme-Review zu #019.
Aufgaben
- Nach außen nur
{ "status": "fehler" }mit Status 503 - Die Begründung serverseitig protokollieren, damit sie beim Suchen nicht fehlt
- Prüfen, ob
docs/betrieb/irgendwo die Meldung als Diagnosehilfe nennt — dann auf das Log verweisen
Akzeptanzkriterien
- Test: bei nicht erreichbarer Datenbank enthält die Antwort weder Host noch Port noch Benutzernamen
- Test: der Statuscode bleibt 503, damit Docker und der Reverse Proxy weiter richtig entscheiden