Ergebnis dieses Guides
Ein Formularvertrag mit serverseitiger Prüfung
Arbeitsumgebung
App Router, React und die im Projekt festgehaltene Next.js-Version
Wann ist diese Entscheidung wichtig?
Browserprüfungen verbessern die Bedienung, schützen aber den Schreibzugriff nicht. Jede Anfrage kann auch ohne die sichtbare Oberfläche gesendet werden.
Ordnen Sie die betroffene Route ihrer page-, layout- oder route-Datei zu. Markieren Sie die Grenze zu Client Components ausdrücklich; Schreibzugriffe und vertrauliche Konfiguration bleiben auf dem Server.
Formulare: Schritt für Schritt.
- 01
Vorbereiten
Definieren Sie Pflichtfelder, maximale Längen, erlaubte Werte und das Verhalten bei wiederholtem Absenden.
- 02
In Next.js umsetzen
Prüfen Sie die Daten auf dem Server, begrenzen Sie Missbrauch und zeigen Sie feldbezogene Fehler. Schützen Sie private Vorgänge zusätzlich durch Berechtigungen.
- 03
Im tatsächlichen Projekt prüfen
Prüfen Sie neben dem Entwicklungsserver einen Produktionsbuild und einen direkten Routenaufruf. Cache-Verhalten und dynamische APIs müssen zur installierten Version passen.
Beispiel zur Überprüfung
So lässt sich das Ergebnis prüfen.
Als Projektkontext dient eine Website mit Leistungsseiten und einem Anfrageformular. Der folgende Prüffall ist eine Vorlage für diese Aufgabe und kein Bericht über eine Kundenmessung.
- Eingabe / Auslöser
- Eine Anfrage mit gültiger E-Mail sowie eine Anfrage mit leerem Pflichtfeld
- Erwartetes Ergebnis
- Nur die gültige Anfrage wird verarbeitet; beim Fehler bleiben die anderen Eingaben erhalten.
- Fehler- oder Grenzfall
- Ein Doppelklick oder wiederholter Netzwerkversuch erzeugt keinen ungewollten zweiten Auftrag.
TypeScript · Server Action · begrenztes Beispiel
export async function validateContact(data: FormData) {
'use server';
const email = String(data.get('email') ?? '').trim();
if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)) {
return { ok: false, error: 'E-Mail prüfen' };
}
return { ok: true, email };
}Dieses begrenzte Beispiel validiert einen Wert und speichert noch nichts. Eine echte Anfrage benötigt zusätzlich passende Längenbegrenzung, Missbrauchsschutz und je nach Vorgang eine Berechtigungsprüfung.
Abnahme und typische Fehler.
- Tastatur, ungültige Werte und Serverfehler funktionieren ohne Datenverlust.
- Ein Doppelklick oder wiederholter Netzwerkversuch erzeugt keinen ungewollten zweiten Auftrag.
- Client- und Servercode brauchen eine klare Grenze; vertrauliche Daten gehören auf den Server.
Typischer Fehler
Nur clientseitige Validierung schützt keinen Schreibvorgang.
Quellen und Versionshinweis
Die Anleitung beschreibt das Vorgehen; konkrete APIs, Produktfunktionen und Laufzeitgrenzen müssen zur eingesetzten Version passen. Halten Sie Version, Konfiguration und Prüfergebnis im Projekt fest und vergleichen Sie die verlinkte Dokumentation bei Änderungen.
