Manipulationen am Warenkorb verhindern - Token?

[Truncate]

Hallo,

aktuell wird per HTML ein Artikel so an die warenkorb.php geschickt:

<form action="warenkorb.php" method="post">
<input type="hidden" name="artikelnummer" value="12345">
<input type="hidden" name="preis" value="49.00">
<select name="size"><option>S<option>M<option>L</select>
<select name="farbe"><option>weiß<option>schwarz</select>
<input type="submit" value="In den Warenkorb legen">
</form>

Problem 1:

Nachdem der Artikel in den Warenkorb gelegt wurde, kann man mittels F5 den Vorgang nochmal wiederholen.

Problem 2:

Jemand könnte die Datei lokal speichern und z.B. den Preis manipulieren und das Formular dann an http://www.domainname.de/warenkorb.php senden.

Ich hab mich bisher immer so beholfen, dass ich in der warenkorb.php alle übertragenen Daten mit der Datenbank abgeglichen habe, also ob z.B. wirklich der Artikel 12345 in Farbe weiß existiert usw.

Kann man das nicht irgendwie mittels eines sog. "Token" einfacher lösen?

Danke!

[h3ll]

Warum nicht einfach eine Session verwenden?

[Kropff]

Problem 1:

Nachdem der Artikel in den Warenkorb gelegt wurde, kann man mittels F5 den Vorgang nochmal wiederholen.

Artikel in Warenkorb legen und dann per header auf dieselbe Seite weiterleiten.

Problem 2:

Jemand könnte die Datei lokal speichern und z.B. den Preis manipulieren und das Formular dann an http://www.domainname.de/warenkorb.php senden.

ID des Artikels (nicht die Artikelnummer) übergeben und anhand dessen den Preis auslesen.

Gruß
Peter

[Truncate]

Warum nicht einfach eine Session verwenden?

Was soll da dann rein?

Es gibt ja auch nicht nur einzelne Artikelseiten, sondern auch diese typischen Artikellisten die man auch alle direkt in den WK schieben kann.

Artikel in Warenkorb legen und dann per header auf dieselbe Seite weiterleiten.

ID des Artikels (nicht die Artikelnummer) übergeben und anhand dessen den Preis auslesen.

Was für eine ID???

Das mit der Artikelnummer funktioniert ja, macht aber massig Arbeit beim validieren...

[h3ll]

Was soll da dann rein?

Alles, was du für die Sitzung benötigst.

Das mit der Artikelnummer funktioniert ja, macht aber massig Arbeit beim validieren...

Validieren musst du so oder so. Du ersparst dir nichts.

[Truncate]

Validieren musst du so oder so. Du ersparst dir nichts.

Gibt's wirklich keine Möglichkeit die Validierung *sämtlicher* Formularfelder zu vermeiden?

Wie machen denn das die "großen" Onlineshops?

Wird da auch jedes Artikelmerkmal (Farbe, Größe, Variante, ...) nach der "Warenkorblegung" einzeln in der DB überprüft ob es existiert und gültig ist?

[h3ll]

Gibt's wirklich keine Möglichkeit die Validierung *sämtlicher* Formularfelder zu vermeiden?

Nein. Alles, was vom Client kommt, ist als unsicher einzustufen und muss überprüft werden.

Wie machen denn das die "großen" Onlineshops?

So wie es erklärt wurde.

Wird da auch jedes Artikelmerkmal (Farbe, Größe, Variante, ...) nach der "Warenkorblegung" einzeln in der DB überprüft ob es existiert und gültig ist?

Ja.

[goth]

Wird da auch jedes Artikelmerkmal (Farbe, Größe, Variante, ...) nach der "Warenkorblegung" einzeln in der DB überprüft ob es existiert und gültig ist?

Ja klar, allerdings wir im Normalfall ja auch nicht alles im Formular mit übertragen.

Die Formularfelder sollten eigentlich nur die Daten enthalten, die der Benutzer bearbeiten (manipulieren) können soll. Also Id's für Artikel, Farbe, Größe, Variante uns meinetwegen. Aber der Preis, es sei denn der Kunden soll diesen selbst festlegen können, auf gar keinen Falle. Der Steht doch eh in der Datenbank, oder wo auch immer dein Stammdaten liegen hast.