nicht angemeldet
Moin!
Um ein versehentlichen Eintrag in den Warenkorb durch den Back- oder Reloadbutton zu verhindern, gebe ich einen Counter an jede Seite und an die Datenbank weiter. Der aktuelle Counter-Wert wird anschließend bei jedem Aufruf einer Seite mit dem Wert in der Datenbank verglichen und dann um eins erhöht. Ist der Aktuelle Wert kleiner oder gleich werden alle Shop relaventen Funktionen ignoriert.
Dabei verhinderst du möglicherweise, dass der Besucher parallel in mehreren Browserfenstern in deinem Shop surft und einkauft - nicht unbedingt die beste Lösung, denn es gibt bessere.
Gibt es eine andere Lösung Reloads und HistoryBacks abzufangen?
Die Sache ist recht simpel, ich möchte aber etwas ausholen:
Die erste Feststellung: Ob POST oder GET ist vollkommen egal. Beide Arten senden (teilweise individuell vom Benutzer eingegebene) Formular- oder Linkparameterdaten an den Server, und dieser arbeitet dann ein Skript ab, welches Dinge tut, und erstellt eine Seite als Antwort.
Logische Konsequenz: Werden dieselben Daten nochmal an den Server gesendet, wird natürlich dasselbe Skript mit denselben Aktionen nochmal ausgeführt.
Wenn also ein Shop eine Grafik mit "1x kaufen" verlinkt hat (GET-Request), und die Ergebnisseite die URL mit dem Parameter "?kaufe=produkt01" hat und ein "Danke für ihren Kauf" ausgibt, und diese Seite vom Besucher neu geladen wird, dann kauft er das Produkt mehrfach. Dabei ist aber nicht unterscheidbar, ob er
a) absichtlich oder unabsichtlich die Reloadtaste gedrückt hat, oder
b) die Back-Taste gedrückt und den Kaufen-Link erneut geklickt hat, oder
c) über die normale Shop-Navigation zum Kaufen-Link weitergegangen und ihn erneut geklickt hat (wenn man voraussetzt, dass alle dabei besuchten Seiten schon im Browsercache sind, und nicht neu vom Server angefordert werden, merkt der Server davon nichts.
Um zu verhindern, dass sich die Kaufen-Aktion neuladbar im Browser hinterläßt, ist meine schon seit langer Zeit geäußerte Empfehlung: Der Skriptaufruf, der den Kauf veranlaßt (oder den Mailversand, oder sonst irgendeine Aktion, die wirklich nur einmal ablaufen soll), darf als Antwort an den Besucher KEINE vollständige HTML-Seite liefern, sondern NUR eine Weiterleitung auf eine andere Seite. Beispielsweise auf eine allgemeine "Danke für ihren Kauf"-Seite, die im Zweifel (egal ob über URL-Parameter, oder vom Kaufen-Skript in der Session gespeichert) irgendwie die Information erhält, was denn tatsächlich die letzte Aktion war, für die man sich bedanken soll, oder deren korrekte Ausführung dem Besucher zu bestätigen ist.
Mit dem Redirect schlägt man zwei Fliegen mit einer Klappe: Erstens bleibt im Browser nur eine Seite stehen, die man problemlos neu laden kann, ohne die eigentliche Aktion doppelt auszuführen.
Zweitens bleibt auch in der History keine Seite stehen, die die Aktion erneut ausführt - die Benutzung des Back-Buttons führt von der "Danke"-Seite direkt zurück zu der Seite, die VOR dem Aktionsstart aufgerufen wurde. Von dort aus kann man natürlich das ganze nochmal aufrufen - aber nicht unabsichtlich.
- Sven Rautenberg
My sssignature, my preciousssss!