# 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

