Formulare mit Validierung, Einwilligung und Spamschutz (Arbeitspaket D)

Migration 20260912000700 legt form und form_submission an. Der
Formularblock im Seiteninhalt enthält nur die Adresse: Felder,
Empfänger und Einwilligungstext liegen in der Datenbank, damit ein
gespeichertes Dokument nicht ändern kann, wonach gefragt wird oder
wohin eine Anfrage geht.

Serverseitige Validierung mit einer Meldung je Feld über
aria-describedby und aria-invalid; eine Ablehnung rendert die Seite
mit HTTP 422 und allen Eingaben neu, eine gültige Absendung wird mit
HTTP 303 zurückgeleitet. Alles ohne JavaScript.

Spamschutz ohne Dienst Dritter: Honeypot, signierter Zeitstempel
gegen zu schnelle und zu alte Absendungen, fünf Absendungen je
Absender und Stunde. Ein erkannter Bot bekommt dieselbe Antwort wie
ein Erfolg. Die Absenderadresse wird nie gespeichert, nur ein Hash.

Gespeichert wird vor dem Versand, damit ein kaputter Mailversand
keine Anfrage verliert. Kein CSRF-Token auf dem öffentlichen Weg,
weil das eine Sitzung und damit ein Cookie auf jeder öffentlichen
Seite bedeuten würde; Begründung in ADR 017. Dateiuploads fehlen
bewusst.

Ein echter Fehler von den Tests gefunden: das Stundenfenster des
Limits entstand aus lokaler Zeit, die Zeitstempel aber aus UTC - auf
einer Uhr vor UTC hätte das Limit nie gegriffen.

Geprüft: 117 PHP-Tests / 450 Assertions unter PHP 8.2.12 und 8.4.22,
14 JavaScript-Modelltests, Lint/Format/Container, composer audit.
Der E-Mail-Versand wurde nie wirklich ausgeführt; keine Browser- oder
Lighthouse-Läufe.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
kantarciandClaude Opus 5 committed 2026-09-12 11:51:07 +02:00
1 parent c6ec00a906
commit d43bd91069
31 files changed
+1445 -26

No files matched your search

+12
View File
@@ -1,5 +1,17 @@
# Qualitätsbericht – erster ausführbarer Prototyp
## Ergänzung: Formulare, 12.09.2026
- **117 PHP-Tests / 450 Assertions** unter PHP 8.2.12 und PHP 8.4.22 erfolgreich, dazu **14 JavaScript-Modelltests**. `composer audit` meldet keine bekannten Advisories, auch nach Aufnahme von `symfony/mailer`.
- Vollständiger Ablauf geprüft: Ausgabe ohne Skript, gültige Absendung wird gespeichert und mit HTTP 303 zurückgeleitet, damit ein Neuladen nichts doppelt sendet, und die Erfolgsmeldung erscheint auf der Zielseite.
- **Datenschutz gezielt geprüft:** in der gespeicherten Zeile steht keine Absenderadresse, sondern ein 64-stelliger Hash; der Zeitpunkt der Einwilligung wird getrennt festgehalten.
- Fehlerhafte Absendung: HTTP 422, **nichts gespeichert und nichts gesendet**, vier Meldungen an den richtigen Feldern, verbunden über `aria-describedby` und `aria-invalid`, genau eine Zusammenfassung mit `role=alert`, und sämtliche Eingaben bleiben erhalten.
- Vier Spamfälle werden still verworfen, ohne zu speichern, und wie ein Erfolg beantwortet: gefüllter Honeypot, Absendung innerhalb der Mindestzeit, gefälschte Zeitstempelsignatur und ein zu alter Zeitstempel. Das Limit stoppt die sechste Absendung innerhalb einer Stunde.
- Die Formularverwaltung verlangt Anmeldung, Editorrolle und CSRF-Token; eine ungültige Empfängeradresse wird mit einer Meldung abgewiesen statt gespeichert.
- **Ein echter Fehler wurde dabei gefunden und behoben:** das Stundenfenster des Limits entstand aus der lokalen Uhrzeit, die Zeitstempel der Einsendungen aber aus UTC. Auf einer Uhr vor UTC – etwa in Deutschland – hätte das Limit nie gegriffen und der Spamschutz wäre an dieser Stelle wirkungslos gewesen. Beide Seiten rechnen jetzt in UTC; der Test deckt genau diesen Fall ab.
- **Der E-Mail-Versand wurde nie wirklich ausgeführt.** Die Tests nutzen einen Transport, der nichts sendet. Ob `sendmail` auf dem Zielhosting funktioniert, ob Nachrichten zugestellt werden und ob sie im Spamordner landen, ist damit vollständig offen und gehört zu Arbeitspaket J.
- **Auch für diesen Schritt wurden auf Wunsch des Nutzers keine Browser-, axe- und Lighthouse-Läufe ausgeführt.** Formularausgabe und Verwaltung sind nicht visuell und nicht mit einem Screenreader geprüft. Gerade bei Formularen ist das ein erheblicher Vorbehalt: die Fehlerauszeichnung ist im Markup korrekt gesetzt, aber nicht in einer echten Hilfstechnik gehört worden.
## Ergänzung: Tabs, 12.09.2026
- **109 PHP-Tests / 395 Assertions** unter PHP 8.2.12 und PHP 8.4.22 erfolgreich, dazu **14 JavaScript-Modelltests**.