Sicherheit: SMTP-Timeout (Hänge-Fall) kann Konten-Seitenkanal öffnen, Gateway-Timeouts festlegen #46

New issue

Open

opened 2026-11-03 11:22:09 +00:00 by cschlaefke · 0 comments

cschlaefke commented

2026-11-03 11:22:09 +00:00

Owner

Kontext

Folge aus Review von PR zu #37 (F13, Spec R17). Refs #1.

Die App behandelt bei recover, resend und signUp jede Antwort mit HTTP-Status >= 500 wie Erfolg. Offen ist der Hänge-Fall: SMTP-Server nimmt die Verbindung an, antwortet aber nicht. Dann hängt die Anfrage nur für bekannte Adressen.

Problem

Bricht die Verbindung ohne HTTP-Status ab (Timeout im Client, ClientException), mappt die App auf network und zeigt das sichtbare Offline-Banner. Das wäre ein Seitenkanal in der App (nur bei bekannten Adressen).
Die Dauer des Spinners ist zusätzlich ein Zeitkanal.
Ein Proxy-504 wäre dank „alle 5xx neutral“ unkritisch.

Zu tun

Spike: GOTRUE_SMTP_HOST=10.255.255.1 (nicht routbar), Verhalten von /recover, /resend, /signup für bekannte vs. unbekannte Adresse (Status, Dauer, Abbruch)
GoTrue-SMTP-Timeout und Gateway-/Proxy-Timeout so festlegen, dass bei Hänger ein 504 (mit Status) vor dem Client-Timeout kommt, dokumentieren (docs/auth-konfiguration.md)
Optional: Client-Timeout bei diesen drei Aufrufen ebenfalls neutral behandeln
Monitoring-Punkt in der Release-Checkliste erweitern: Gateway-5xx/504 für /recover, /resend, /signup, nicht nur unexpected_failure/500

Priorität

Release-Blocker, kein Merge-Blocker für #37. Bezug #37, #1.

## Kontext Folge aus Review von PR zu #37 (F13, Spec R17). Refs #1. Die App behandelt bei `recover`, `resend` und `signUp` jede Antwort mit HTTP-Status >= 500 wie Erfolg. Offen ist der **Hänge-Fall**: SMTP-Server nimmt die Verbindung an, antwortet aber nicht. Dann hängt die Anfrage nur für bekannte Adressen. ## Problem - Bricht die Verbindung ohne HTTP-Status ab (Timeout im Client, `ClientException`), mappt die App auf `network` und zeigt das sichtbare Offline-Banner. Das wäre ein Seitenkanal in der App (nur bei bekannten Adressen). - Die Dauer des Spinners ist zusätzlich ein Zeitkanal. - Ein Proxy-504 wäre dank „alle 5xx neutral“ unkritisch. ## Zu tun - [ ] Spike: `GOTRUE_SMTP_HOST=10.255.255.1` (nicht routbar), Verhalten von `/recover`, `/resend`, `/signup` für bekannte vs. unbekannte Adresse (Status, Dauer, Abbruch) - [ ] GoTrue-SMTP-Timeout und Gateway-/Proxy-Timeout so festlegen, dass bei Hänger ein 504 (mit Status) vor dem Client-Timeout kommt, dokumentieren (`docs/auth-konfiguration.md`) - [ ] Optional: Client-Timeout bei diesen drei Aufrufen ebenfalls neutral behandeln - [ ] Monitoring-Punkt in der Release-Checkliste erweitern: Gateway-5xx/504 für `/recover`, `/resend`, `/signup`, nicht nur `unexpected_failure`/500 ## Priorität Release-Blocker, kein Merge-Blocker für #37. Bezug #37, #1.