111 lines
4.6 KiB
Markdown
111 lines
4.6 KiB
Markdown
# Issue #34 – Kontaktformular: E-Mail-Versand via PHP
|
||
|
||
- **Repo:** `greggy/landingpage-haus-schleusingen`
|
||
- **Issue:** #34
|
||
- **Titel:** Kontaktformular: E-Mail-Versand via PHP
|
||
- **Komplexität:** **M**
|
||
- **Stand:** Analyse abgeschlossen
|
||
- **Datum:** 2026-05-14
|
||
|
||
## Kurzbewertung
|
||
|
||
Das Issue ist **Medium (M)**: Es ist kein großer Architekturumbau, aber es ist mehr als ein kleiner Bugfix, weil serverseitige PHP-Logik, Spam-Schutz, Validierung, sichere Header-Behandlung und UI-Feedback zusammen umgesetzt werden müssen.
|
||
|
||
## Abhängigkeiten
|
||
|
||
- **Keine blockierenden offenen Issues gefunden.**
|
||
- `index.php` existiert bereits auf `main` und ist die richtige Basis für die PHP-Umsetzung.
|
||
- Hinweis: Das bestehende Docker/Nginx-Setup dient weiter als statisches Preview, verarbeitet aber kein PHP-Mail-Handling. Für den echten Versand ist eine PHP-fähige Laufzeit nötig (Testumgebung: Apache/PHP).
|
||
|
||
## Anforderungen aus dem Issue
|
||
|
||
1. Kontaktformular verschickt E-Mails serverseitig via PHP.
|
||
2. Empfänger ist `mki@kies-media.de`.
|
||
3. Absender (`From`) ist die E-Mail-Adresse aus dem Formular.
|
||
4. Pflichtfeld-Validierung für Name, E-Mail und Nachricht.
|
||
5. Spam-Schutz via Honeypot und zusätzlicher Missbrauchsschutz.
|
||
6. Erfolgsmeldung nach erfolgreichem Versand.
|
||
7. Verständliche Fehlermeldungen bei ungültigen oder fehlenden Eingaben.
|
||
|
||
## Implizite Anforderungen / Edge Cases
|
||
|
||
- Header-Injection über Name/E-Mail darf nicht möglich sein.
|
||
- Ungültige E-Mail-Adressen müssen serverseitig abgelehnt werden.
|
||
- Leere oder nur aus Leerzeichen bestehende Nachrichten müssen abgelehnt werden.
|
||
- Bots sollen am Honeypot scheitern.
|
||
- Sehr schnelle Direkt-Submits sollen als verdächtig behandelt werden.
|
||
- Mehrfach-Submits in kurzer Zeit sollen begrenzt werden.
|
||
- Bei Mail-Fehlern darf kein falscher Erfolg angezeigt werden.
|
||
- Formulardaten sollen bei Validierungsfehlern im Formular erhalten bleiben.
|
||
|
||
## Technischer Plan
|
||
|
||
### Backend / PHP
|
||
|
||
- `index.php` bekommt einen serverseitigen POST-Handler.
|
||
- `session_start()` wird verwendet für:
|
||
- Formular-Timestamp
|
||
- einfaches Rate-Limit zwischen Submits
|
||
- Hilfsfunktionen:
|
||
- `normalizeContactValue()` für Trim/Sanitizing
|
||
- `escapeContactValue()` für sichere Ausgabe ins HTML
|
||
- `containsHeaderInjection()` für Header-Schutz
|
||
- Versand über `mail()` mit Headern:
|
||
- `From: <Formular-E-Mail>`
|
||
- `Reply-To: <Formular-E-Mail>`
|
||
- `Content-Type: text/plain; charset=UTF-8`
|
||
- Bei Erfolg: Formular leeren und Erfolgsmeldung rendern.
|
||
- Bei Fehlern: Fehlerliste oberhalb des Formulars rendern.
|
||
|
||
### Frontend / HTML
|
||
|
||
- Formular auf `method="post"` umstellen.
|
||
- Honeypot-Feld ergänzen (visuell versteckt, für Screenreader ebenfalls ausgeschlossen).
|
||
- Hidden-Feld für Formular-Token/Timestamp ergänzen.
|
||
- Bestehende Erfolgsmeldung auf serverseitig gesteuerten Zustand umbauen.
|
||
- Pflichtfelder klar markieren und `required` beibehalten.
|
||
|
||
### Frontend / JS
|
||
|
||
- Bestehende `mailto:`-Logik entfernen.
|
||
- Sonstige Interaktionen (Lightbox, Navigation, Scroll) unverändert lassen.
|
||
|
||
### Styling
|
||
|
||
- Styles für:
|
||
- Fehlermeldungsbox
|
||
- serverseitige Erfolgsmeldung
|
||
- Honeypot-Hilfsklasse
|
||
|
||
## Sicherheitsbetrachtung
|
||
|
||
- Pflicht: serverseitige Validierung, nicht nur HTML5.
|
||
- Pflicht: Schutz vor Header-Injection in Mail-Headern.
|
||
- Pflicht: Honeypot leer + Mindestzeit bis Submit + Session-Rate-Limit.
|
||
- Keine sensiblen Daten in Logs oder im Frontend ausgeben.
|
||
|
||
## Teilaufgaben
|
||
|
||
1. `main`-Stand prüfen und Feature-Branch anlegen.
|
||
2. `index.php` serverseitig auf POST/Mailversand umbauen.
|
||
3. Formular um Honeypot, Hidden-Felder, Fehler-/Erfolgsausgabe ergänzen.
|
||
4. `js/haus-schleusingen.js` von `mailto:`-Submit befreien.
|
||
5. CSS für Meldungszustände ergänzen.
|
||
6. Linting / Formatierung / PHP-Syntaxcheck ausführen.
|
||
7. Self-Review dokumentieren.
|
||
8. QA inkl. Happy Path, Validierungsfehler und Spam-Schutz dokumentieren.
|
||
9. PR erstellen und Martin zur Freigabe vorlegen.
|
||
|
||
## Akzeptanzkriterien
|
||
|
||
- [ ] Formular sendet serverseitig eine E-Mail an `mki@kies-media.de`.
|
||
- [ ] `From` verwendet die eingegebene Formular-E-Mail.
|
||
- [ ] E-Mail enthält Name, E-Mail, optional Telefon, Anliegen und Nachricht.
|
||
- [ ] Honeypot + zusätzlicher Missbrauchsschutz aktiv.
|
||
- [ ] Erfolgsmeldung nach erfolgreichem Versand sichtbar.
|
||
- [ ] Fehlermeldungen bei fehlenden/ungültigen Pflichtfeldern sichtbar.
|
||
|
||
## Architekturentscheidung
|
||
|
||
Es wird bewusst **kein** SMTP-Layer oder externer Mailer eingebaut, weil das Issue explizit `mail()` erlaubt und für dieses Projekt eine schlanke, servernahe Lösung genügt. Falls Zustellbarkeit oder Hosting-Limits später Probleme machen, wäre ein Folge-Issue für SMTP/PHPMailer sinnvoll.
|