feat: ICS-Kalendereinträge, Rate-Limiting und erweiterte E-Mail-Validierung
- ICS-Dateianhänge in Bestätigungsmails mit Europe/Berlin Zeitzone - Rate-Limiting: IP-basiert (5/10min) und E-Mail-basiert (3/1h) - Mehrschichtige E-Mail-Validierung mit Rapid Email Validator API - Disposable Email Detection (blockiert Wegwerf-Adressen) - MX Record Verification - Domain Verification - Typo-Erkennung mit Vorschlägen - Zod-Schema-Validierung für Name, E-Mail und Telefonnummer - Dokumentation für Rate-Limiting und E-Mail-Validierung - README mit neuen Features aktualisiert - Backlog aktualisiert
This commit is contained in:
@@ -1,15 +1,14 @@
|
||||
## Backlog – Terminplanung & Infrastruktur
|
||||
|
||||
### Kalender & Workflow
|
||||
- ICS-Anhang/Link in E‑Mails (Kalendereintrag)
|
||||
- ~~ICS-Anhang/Link in E‑Mails (Kalendereintrag)~~
|
||||
- Erinnerungsmails (24h/3h vor Termin)
|
||||
- ~~Umbuchen/Stornieren per sicherem Kundenlink (Token)~~
|
||||
- Pufferzeiten und Sperrtage/Feiertage konfigurierbar
|
||||
- ~~Slots dynamisch an Behandlungsdauer anpassen; Überschneidungen verhindern~~
|
||||
|
||||
### Sicherheit & Qualität
|
||||
- Rate‑Limiting (IP/E‑Mail) für Formularspam
|
||||
- CAPTCHA im Buchungsformular
|
||||
- ~~Rate‑Limiting (IP/E‑Mail) für Formularspam~~
|
||||
- E‑Mail‑Verifizierung (Double‑Opt‑In) optional
|
||||
- Audit‑Log (wer/was/wann)
|
||||
- DSGVO: Einwilligungstexte, Löschkonzept
|
||||
|
93
docs/rate-limiting.md
Normal file
93
docs/rate-limiting.md
Normal file
@@ -0,0 +1,93 @@
|
||||
# Rate Limiting & E-Mail-Validierung
|
||||
|
||||
Das System verwendet ein mehrstufiges Sicherheitssystem, um Spam und Missbrauch des Buchungsformulars zu verhindern.
|
||||
|
||||
## E-Mail-Validierung
|
||||
|
||||
Neben der Zod-Schema-Validierung wird jede E-Mail-Adresse durch die [Rapid Email Validator API](https://rapid-email-verifier.fly.dev/) geprüft:
|
||||
|
||||
### Geprüfte Kriterien
|
||||
- ✅ **Syntax-Validierung:** Korrekte E-Mail-Format-Prüfung
|
||||
- ✅ **Disposable Email Detection:** Wegwerf-E-Mail-Adressen werden blockiert
|
||||
- ✅ **MX Record Verification:** Prüft, ob die Domain E-Mails empfangen kann
|
||||
- ✅ **Domain Verification:** Validiert die Existenz der Domain
|
||||
- ✅ **Typo-Erkennung:** Schlägt Korrekturen bei häufigen Tippfehlern vor
|
||||
|
||||
### Datenschutz
|
||||
Die verwendete API speichert **keine Daten** und ist GDPR/CCPA/PIPEDA-konform. Alle E-Mail-Adressen werden nur im Speicher verarbeitet und sofort verworfen.
|
||||
|
||||
### Fallback-Verhalten
|
||||
Falls die Validierungs-API nicht erreichbar ist, fällt das System auf die Zod-Validierung zurück, um die Funktionalität zu gewährleisten.
|
||||
|
||||
---
|
||||
|
||||
## Rate Limiting
|
||||
|
||||
Das System verwendet ein Rate-Limiting, um Spam und Missbrauch des Buchungsformulars zu verhindern.
|
||||
|
||||
## Aktuelle Konfiguration
|
||||
|
||||
### Buchungen (E-Mail-basiert)
|
||||
- **Limit:** 3 Buchungsanfragen pro E-Mail-Adresse
|
||||
- **Zeitfenster:** 1 Stunde
|
||||
- **Verhalten:** Nach 3 Anfragen muss der Nutzer 1 Stunde warten
|
||||
|
||||
### Buchungen (IP-basiert)
|
||||
- **Limit:** 5 Buchungsanfragen pro IP-Adresse
|
||||
- **Zeitfenster:** 10 Minuten
|
||||
- **Verhalten:** Nach 5 Anfragen muss der Nutzer 10 Minuten warten
|
||||
|
||||
## Wie es funktioniert
|
||||
|
||||
Das Rate-Limiting prüft **beide** Kriterien:
|
||||
1. **E-Mail-Adresse:** Verhindert, dass dieselbe Person mit derselben E-Mail zu viele Anfragen stellt
|
||||
2. **IP-Adresse:** Verhindert, dass jemand mit verschiedenen E-Mail-Adressen von derselben IP aus spammt
|
||||
|
||||
Wenn eines der Limits überschritten wird, erhält der Nutzer eine Fehlermeldung mit Angabe der Wartezeit.
|
||||
|
||||
## IP-Erkennung
|
||||
|
||||
Das System erkennt die Client-IP auch hinter Proxies und Load Balancern durch folgende Headers:
|
||||
- `x-forwarded-for`
|
||||
- `x-real-ip`
|
||||
- `cf-connecting-ip` (Cloudflare)
|
||||
|
||||
## Implementierung
|
||||
|
||||
- **Speicherung:** In-Memory (Map)
|
||||
- **Cleanup:** Automatisches Aufräumen alter Einträge alle 10 Minuten
|
||||
- **Skalierung:** Für Produktionsumgebungen mit mehreren Server-Instanzen sollte Redis o.ä. verwendet werden
|
||||
|
||||
## Anpassung
|
||||
|
||||
Die Limits können in `src/server/lib/rate-limiter.ts` in der Funktion `checkBookingRateLimit()` angepasst werden:
|
||||
|
||||
```typescript
|
||||
// E-Mail-Limit anpassen
|
||||
const emailConfig: RateLimitConfig = {
|
||||
maxRequests: 3, // Anzahl der Anfragen
|
||||
windowMs: 60 * 60 * 1000, // Zeitfenster in Millisekunden
|
||||
};
|
||||
|
||||
// IP-Limit anpassen
|
||||
const ipConfig: RateLimitConfig = {
|
||||
maxRequests: 5, // Anzahl der Anfragen
|
||||
windowMs: 10 * 60 * 1000, // Zeitfenster in Millisekunden
|
||||
};
|
||||
```
|
||||
|
||||
## Fehlermeldungen
|
||||
|
||||
Bei Überschreitung des Limits erhält der Nutzer folgende Meldung:
|
||||
```
|
||||
Zu viele Buchungsanfragen. Bitte versuche es in X Minuten erneut.
|
||||
```
|
||||
|
||||
## Produktions-Empfehlungen
|
||||
|
||||
Für Produktionsumgebungen empfehlen sich:
|
||||
- ✅ Redis als verteilter Speicher für Rate-Limit-Daten
|
||||
- ✅ Überwachung der Rate-Limit-Trigger (Logging/Monitoring)
|
||||
- ✅ Whitelist für vertrauenswürdige IPs (z.B. Admin-Zugang)
|
||||
- ✅ Anpassung der Limits basierend auf tatsächlichem Nutzungsverhalten
|
||||
|
Reference in New Issue
Block a user