zurückspringen auf Bestellseite verhindern

[Karin]

Hallo,
ich brauche mal einen Hinweis bzgl. folgendes:

ich arbeite an einem Bestellvorgang in einem online-shop.
sobald der Kunde auf "Bestellung" klickt, werden alle Produkte in der DB gespeichert und der Kunde wird auf eine Seite verlinkt, auf der ihm seine Bestellung nochmals aufgelistet wird mir der INFO, dass die Bestellung erfolgreich ausgeführt wurde.

Wenn nun aber der Kunde mit dem zurückbutton des browsers wieder eine Seite zurückgeht, und wieder vor, landet er wieder auf der Bestellübersicht, nur wurden seine produkte zweimal berechnet und dementsprechend auch zweimal angezeigt.

was für Möglichkeiten habe ich, um das zurückspringen auf die Bestellseite zu verhindern?
Kann mir jemand Ratschläge geben?

viele Grüße Karin

[Ludger]

Hi,

Wenn nun aber der Kunde mit dem zurückbutton des browsers wieder eine Seite zurückgeht, und wieder vor, landet er wieder auf der Bestellübersicht, nur wurden seine produkte zweimal berechnet und dementsprechend auch zweimal angezeigt.

das ist nicht gut.   :-)

was für Möglichkeiten habe ich, um das zurückspringen auf die Bestellseite zu verhindern?

Nein.

Kann mir jemand Ratschläge geben?

Nein.

Gruss,
Ludger

[Daniel]

Hi,

Wenn nun aber der Kunde mit dem zurückbutton des browsers wieder eine Seite zurückgeht, und wieder vor, landet er wieder auf der Bestellübersicht, nur wurden seine produkte zweimal berechnet und dementsprechend auch zweimal angezeigt.

das ist nicht gut.   :-)

Das hat sie auch gemerkt.
Überprüfe doch vor dem eintrag in die DB ob der gleiche eintrag schon
exestiert und mach vor einem neuen eintrag evt eine abfrage o.ä.

MfG

[Daniel]

Nachtrag,

Überprüfe doch vor dem eintrag in die DB ob der gleiche eintrag schon
exestiert und mach vor einem neuen eintrag evt eine abfrage o.ä.

damit kannst du das zurückspringen zwar nicht verhindern, aber den
doppelten eintrag, die doppelte bestellung.

MfG

[Karin]

so jungs,
vielen Dank für die Infos.
habe den fall dank des Hinweises:

Überprüfe doch vor dem eintrag in die DB ob der gleiche eintrag schon

gelöst:

wenn der Kunde auf der Bestellübersicht landet, wird eine $_SESSION-variable (habe bisher nicht erwähnt das der Shop nur unter register_globals=on läuft)anhand der in der DB generierten id für diese Bestellung, gesetzt

$_SESSION['schonbestellt']=$bestell_id;

auf der Seite auf der die Bestellung stattfindet, findet die DB-Abfrage (ob diese $bestell_id schon vorhanden ist statt).

wenn sie schon vorhanden ist, wird der Kunde auf die "Ihr Warenkorb ist leer" Seite verlinkt.

vielen Dank und viele Grüße
Karin

[Klawischnigg]

Hi there,

wenn sie schon vorhanden ist, wird der Kunde auf die "Ihr Warenkorb ist leer" Seite verlinkt.

Wenn Du es so gemacht hast, daß der Kunde halbwegs versteht, warum er jetzt dort gelandet ist, hast Du das Problem elegant gelöst...

[Cheatah]

Hi,

Wenn nun aber der Kunde mit dem zurückbutton des browsers wieder eine Seite zurückgeht, und wieder vor, landet er wieder auf der Bestellübersicht, nur wurden seine produkte zweimal berechnet und dementsprechend auch zweimal angezeigt.

was für Möglichkeiten habe ich, um das zurückspringen auf die Bestellseite zu verhindern?

gar keine.

Kann mir jemand Ratschläge geben?

Der Vorgang wird stattfinden. Erkenne ihn als bereits geschehen, indem Du beispielsweise für eine Identifizierbarkeit eines Vorgangs sorgst und eine vollständige Abarbeitung serverseitig notierst.

Cheatah

[Ludger]

Hi,

Der Vorgang wird stattfinden. Erkenne ihn als bereits geschehen, indem Du beispielsweise für eine Identifizierbarkeit eines Vorgangs sorgst und eine vollständige Abarbeitung serverseitig notierst.

es ist aber gar kein Vorgang, da keine Datenaenderungen dabei stattfinden duerfen. Das ist ja genau das Problem.

Gruss,
Ludger

[Cheatah]

Hi,

Der Vorgang wird stattfinden. Erkenne ihn als bereits geschehen, indem Du beispielsweise für eine Identifizierbarkeit eines Vorgangs sorgst und eine vollständige Abarbeitung serverseitig notierst.
es ist aber gar kein Vorgang,

es geht etwas vor. Das mag aus kaufmännischer Sicht (oder aus welcher auch immer) nicht als Vorgang bezeichnet werden, der Begriff ist aber trotzdem nutzbar. Ansonsten: Mach einen Gegenvorschlag ;-)

Cheatah

[Ludger]

Hi,

es geht etwas vor. Das mag aus kaufmännischer Sicht (oder aus welcher auch immer) nicht als Vorgang bezeichnet werden, der Begriff ist aber trotzdem nutzbar. Ansonsten: Mach einen Gegenvorschlag ;-)

ein Blick in den Einkaufskorb, nennen wirs mal Bestelluebersicht, ist fuer mich kein Vorgang. Und da man das ja alles nachgiesst in IT, darf das auch in IT kein manipulierender Datenzugriff sein.

Wir haben ja hier ganz offenkundig eine (fehlerhafte :-) Implementierung, also, dass (die falschen Daten geaendert werden, nichts gegen einen kleinen Zaehler :-) Daten geaendert werden, wenn die Bestelluebersicht angefordert worden ist.

(Ich raeume ja gerne ein, dass Dein Vorschlag hier zielfuehrender ist, als meine kleine Analyse. Aber sowas muss auch sein.)

Gruss,
Ludger

[Cheatah]

Hi,

ein Blick in den Einkaufskorb, nennen wirs mal Bestelluebersicht, ist fuer mich kein Vorgang.

durch Benutzerinteraktion wird durch den Browser ein Request an den Server gesendet, welcher ihn bearbeiten muss, Daten ermitteln, einen Response zusammenbasteln, diesen zurück zum Browser schicken, welcher das Ergebnis dann darzustellen hat. Aus meiner Sicht geht da eine Menge vor. Und um eben diesen Vorgang geht es hier.

Und da man das ja alles nachgiesst in IT, darf das auch in IT kein manipulierender Datenzugriff sein.

Richtig. Bei diesem Vorgang dürfen keine Daten manipuliert werden ;-)

(Ich raeume ja gerne ein, dass Dein Vorschlag hier zielfuehrender ist, als meine kleine Analyse. Aber sowas muss auch sein.)

Volle Zustimmung. Gleichzeitig merken wir, dass Sprache kein eindeutiges Werkzeug ist, sondern insbesondere von der Vielzahl möglicher semantischer Ebenen abhängt.

Cheatah

[Klawischnigg]

Hi there,

das "Zurückspringen" kannst Du ebensowenig verhindern wie die "doppelte Bestellung". Es ist aber zB möglich, aus SessionId und ArtikelIds und Menge der georderten Artikel eine Art Prüfziffer zu bilden, die Du beim ersten Sichern der Bestellung mitspeicherst. Wird die Bestellung nun ein zweitesmal (und zwar identisch) eingegeben, erkennt das Skript am Server die Doublette.
Wenn natürlich der surfende Kunde zurückgeht und dann an seiner Bestellung noch etwas ändern kann und nocheinaml abschickt, dann lieferst Du ihm entweder den Krempel doppelt oder aber Du mußt zu gefinkelteren Plausibilitätsabfragen greifen. Was zwar noch möglich wäre (wie groß ist die Wahrscheinlichkeit, daß ein und derselbe Kunde in best. Zeitraum ähnliches bestellt etc...) aber nur beschränkt möglich und auch nur beschränkt sinnvoll.
Auch eine Abfrage (Wollen Sie wirklich blablabla ?...) kann im schlimmsten Fall den Kunden einfach verwirren und ihn den Einkauf ganz sein lassen.
Auf der ganz sicheren Seite bist Du, wenn Du pro SessionID nur eine Bestellung zulässt, das kann aber ebenfalls verkaufshemmend wirken, auch wenn Du den Kunden bittest, für eine neue Bestellung neu einzuloggen, da fühlen sich dann sicher wieder ein paar gefrotzelt ;)

[Ludger]

Hi,

Auf der ganz sicheren Seite bist Du, wenn Du pro SessionID nur eine Bestellung zulässt, das kann aber ebenfalls verkaufshemmend wirken, auch wenn Du den Kunden bittest, für eine neue Bestellung neu einzuloggen, da fühlen sich dann sicher wieder ein paar gefrotzelt ;)

nun, in der Realitaet haben wir den Sachverhalt "Mensch geht in Geschaeft, fuellt Einkaufswagen und schaut in diesen", dieser Sachverhalt wird doch intuitiv nachgebaut, wenn ein Einkaufsvorgang zugelassen wird. Wenn abgerechnet wird, ist der Einkaufswagen wieder leer.

Gruss,
Ludger

[Klawischnigg]

Hi there,

nun, in der Realitaet haben wir den Sachverhalt "Mensch geht in Geschaeft, fuellt Einkaufswagen und schaut in diesen", dieser Sachverhalt wird doch intuitiv nachgebaut, wenn ein Einkaufsvorgang zugelassen wird. Wenn abgerechnet wird, ist der Einkaufswagen wieder leer.

Stimmt ja, nur was hab ich als Webshopbetreiber vo dieser Erkenntnis?
Viele Leute treiben im Internet Geschichten, die sie im "normalen" Leben so nie machen würden. Als Programmierer eines Webshops (eigentlich bei jedem Programm, das die Bastelstube verläßt) muß man immer mit dem Schlimmsten rechnen, das einzige, worauf Du Dich verlassen kannst ist die eigene Fähigkeit, genau dieses Schlimmste vorherzusehen und entsprechend danach zu handeln. Alles andere, darunter fallen auch Anlehnungen an das Verhalten der Menschen in der sogenannten Realität, ist imho grob fahrlässig...

[Ludger]

Hi,

Als Programmierer eines Webshops (eigentlich bei jedem Programm, das die Bastelstube verläßt) muß man immer mit dem Schlimmsten rechnen,

da duerfte wohl defensives Programmieren der Extraklasse erforderlich sein, Du sitzt ja zwischen den Fronten "Kunden" udn "Kaufleute".

Alles andere, darunter fallen auch Anlehnungen an das Verhalten der Menschen in der sogenannten Realität, ist imho grob fahrlässig...

Ich habs noch nicht ganz gefressen, hast Du wirklich angeregt zwei Bestellvorgaenge in _einer_ Einkaufssitzung zu unterstuetzen?

Gruss,
Ludger

[Klawischnigg]

Hi there,

Ich habs noch nicht ganz gefressen, hast Du wirklich angeregt zwei Bestellvorgaenge in _einer_ Einkaufssitzung zu unterstuetzen?

Erstens genügt "lesen", "fressen" ist nicht notwendig, zweitens vermag ich eine Anregung meinem Posting mitnichten zu entnehmen und drittens wäre es zwar ungewöhnlich, aber durchaus möglich. Die Sitzung in dem Sinne bildet ja keine notwendige Realität ab. Das tut einzig und alleine die Identität des Kunden. Und die bleibt ja in jedem Fall gleich, auch wenn er sich nach Bestellung neu einlogged.
Nocheinmal: Ich rede hier einem solchen Vorgehen keineswegs das Wort. Aber datentechnisch wäre es kein Problem. Man darf das nicht aus der Sicht irgendwelcher PHP-Sessions oder Sessionvariablen sehen; wer die verwendet, macht in einem shop ohnehin einen großen Fehler...

[Ludger]

Hi,

na gut, ich habs gefressen. Dann waere da allerdings noch die Sache mit der Doppelbestellung und der Pruefsumme, also, das habe ich auch noch nicht ganz verstanden.

Nach meiner Ansicht ist der Einkaufskorb ja leer beim zweiten Bestellvorgang. Oder hast Du das anders geloest?

Gruss,
Ludger

[Klawischnigg]

Hi there,

na gut, ich habs gefressen. Dann waere da allerdings noch die Sache mit der Doppelbestellung und der Pruefsumme, also, das habe ich auch noch nicht ganz verstanden.

Nach meiner Ansicht ist der Einkaufskorb ja leer beim zweiten Bestellvorgang. Oder hast Du das anders geloest?

Da müssen wir zwei Vorgänge (auch wenn Du darunter uU etwas anderes verstehen magst) unterscheiden:

1. die Doublette beim "put into basket"-Vorgang.

Da kann ich sehr wohl abchecken, ob ich jetzt im Korb etwas doppelt habe, und kann darauf zumindest so reagieren, daß ich beim Kunden eine Rückfrage mache, ob das so gewollt ist. (Was ja gut möglich wäre..)

2. eine Doublette beim eigentlich bestellvorgang. Kann es dann nicht geben, wenn der Warenkorb durch eine table repräsentiert wird, da ja, wie Du richtig erkannt hast, der Warenkorb nach dem ersten Bestellvorgang leer ist. Nichtsdestotrotz spräche datentechnisch nichts dagegen, ihn wieder "zu befüllen", auch mit der selben ID.
Gelegentlich wird aber der Warenkorb durch irgendwelche Cookies oder Hidden-Inputs gelöst, und da kann es dann zumindest bei letzterem nach dem Zurückblätter Probleme geben; die man mit Prüfsummen oä. in den Griff bekommen könnte, Tatsache aber bleibt, daß das ohnehin keine wirklich brauchbaren Warenkorb-Implementierungen sind...