PHP Warenkorb am besten realisieren?

[volcem]

Guten,

derzeit Arbeite ich an einem Projekt und muss ein Warenkorb entwickeln.
Da ich dies noch nie gemacht habe wollte ich mal fragen welche Probleme ich bekommen kann?

Wie sollte man einen Warenkorb absichern etc?

Welche Methode ist am besten?

Session.
Session + cookie?
Session + db ?

Ich danke

 

[Maik1]

Ich hab auch einmal einen Warenkorb entwickelt, und habe Sessions genommen. Cookies wollte ich nicht nehmen, weil diese sich manipulieren lassen und damit event. ein Sicherheitsrisiko darstellen und außerdem Cookies nicht bei jedem Browser aktiviert sind. Session + DB fiel für mich auch weg, weil man dadurch auch noch ein kleines Script hätte entwickeln müssen, dass die DB pflegt, und "alte" Warenkörbe wieder löscht,... . Außerdem ist es aufwendiger wenn man zusätzlich zum Session auslesen noch eine DB-Abfrage tätigen müsste.

Deswegen hab ich damals einfach nur Sessions genommen. Den Warenkorb hatte ich in einem Array gespeichert und diesen mit den Funktionen serialize und unserialize in einen String umgewandelt und in einer Session abgespeichert/ wieder ausgelesen.

 

[volcem]

Danke für deine schnelle Antwort.

Die Funktionen werde ich mir mal genauer ansehen, danke dafür.

Gut, das mit der Db pflegen ist kein Problem, die Funktion dazu hatte ich schon für ein anderen bereich geschrieben.

Sonst noch was, was man beachten müsste?

 

[Surviv0r]

Naja,

Tabelle

product
productid|title|price|etc

cartitem
sessionid|productid|amount|userid

session
sessionid|userid|etc

user
userid|username|email|password

product enthült die Produkte, wenn der User ein Produkt in den Warenkorb legt, wird ein Eintrag in der Tabelle cartitem erzeugt, die Produkt + User verknüpft, also productid und sessionid.

session enthält dann halt die Session an sich, kann man aber auch mit PHP Standard-Mitteln lösen.

Man kann überlegen, der Tabelle cartitem noch eine Spalte userid hinzuzufügen, dann kann der Warenkorb für Eingeloggte User auch länger gespeichert werden.

Wenn man eine eigene Session Tabelle/ein Login System erstellt, muss eh sessionid, passwort etc in Cookies gespeichert werden.

Wichtig ist, dass in den Cookies IMMER nur Verweise auf Daten gespeichert werden, NICHT ABER die Daten selbst.

Also der Warenkorb wird auf dem Server gespeichert, das Cookie enthält hat nur einen Verweise auf diesen.

Dann noch einen Cronjob, der regelmäßige Aufräumarbeiten durchführt - fertig. (Es gibt auch mittel, dies ohne echte Server Cronjobs zu lösen).

Das sollte die sauberste/sicherste Lösung sein ...

 

[volcem]

Danke für deine Antwort sehr hilfreiche Informationen.

Danke dir.

 

[Fatal Error]

auch sessions funktionieren nur durch cookies, er wird jedoch nur die session id in einem cookie abgelegt.
wenn du es wirklich darauf anlegst, dass auch benutzer mit deaktivierten cookies deine seite benutzen können, kannst du die session id immer als get parameter (so wie man es häufig bei foren sieht, wo am link immer noch sid=... steht) mitgeben

 

[Surviv0r]

Man kann es auch an die IP binden, nur für AOL User ist das natürlich schlecht, da die immer eine andere IP haben ...

 

[volcem]

Mal sehen ob sich daraus eine nette kleine Funktion schreiben lässt, also irgend wie prüfen ob der Besucher Cookies akzeptiert.

So in etwa:

<?php 
if ($_GET['pruefe'] != 'yes') { 
     	setcookie ('enabled', 'enabled', get_date_time(time()) + 60); 
     	header ("Location: cookies.php?pruefe=yes"); 
} else { 
     	if (!empty($_COOKIE['enabled'])) { 
       	 header ("Location: index.php");
    	} else { 
       	 // Hier irgend wie ne andere Funktion die sagt das er bei einer URL oder beim Formular halt sid dran hängen soll..  
    	} 
} 
?>

Werde das ganze erst erstellen können wenn ich die Artikel-Seite und das drum herum entwickelt habe, sonst macht das irgend wie keinen sinn, es später wieder auf die anderen Seiten umzuschreiben.

Ich danke für eure Antworten.

 

[Kantholy]

php ist im normalfall btw selbst so schlau und setzt die sessionid als get parameter an die url hin sollte das cookie setzen nicht funktioniert haben... ich mein ja bloß

ich würds per session regeln, vorteil ist: du kannst in einer session wunderbar arrays abspeichern, dann hast du da eben deinen "warenkorb" array, in dem du dann wieder wunderbar arrays ablegen kannst nach dem motto

array_push($_SESSION['warenkorb'], array($ArtikelNr, $Menge));

so würds ich jedenfalls machen

 

[Eagle-PsyX-]

Nahja, die SessID als GET-Parameter wäre für jede Art eines OnlineShops ein Tabu. Laut meiner Statistik von Besuchern (sind ings. > 47'000 ) haben 100 % Cookies aktiviert und 98 % JavaScript

Aus Performance-Gründen würde ich Maiks Methode vorziehen, doch die von Surviv0r ist deutlich übersichtlicher. Und kleine CronJobs schaden nicht. Ein einfacher Verweise auf eine SessID in der DB. Später wird abgefrag ob diese noch exisitiert, falls ja löschen - ansonsten nix.

Ahja, deine Funktion:

		ini_set('session.use_cookies', '0');
		ini_set('session.use_only_cookies', '0');
		ini_set('session.use_trans_sid', '1');

 

[volcem]

Jops, hatte ich jetzt auch mehrmals gelesen, ist leider erst mein "erster" Shop den ich Programmiere.
Da muss ich leider viel zu lesen, worauf man achten muss etc, und alle Bestimmungen einhalten(Datenspeicherung, Rechtliches etc)

Hab leider keine Ahnung auf was für einer Maschine der Shop später laufen wird, die Firma will sich einen neuen zulegen...

Deswegen hab ich derzeit folgende Funktion drin:

//Warenkorb nach X löschen
$secs = $sec;
$dt = sqlesc(get_date_time(time() - $secs));
$sql =("DELETE FROM cartitem WHERE added <= $dt AND save_cart =no"); 
mysql_query($sql) or die('Error[SELECT|cartitem->delete->header]: <br /><pre>' . $sql . '</pre><br />MySQL-Error: ' . mysql_error());

Danke @Eagle-PsyX-

Ich bin echt über jede Hilfestellung dankbar, nur so lerne ich auch was draus

 

[Eagle-PsyX-]

Du kannst die CronJob auf jeden PHP Server ausführen. Zum Beispiel bloß durch das Aufrufen von "www.blala.de/cronjob.php".
Mit Diensten wie www.cron-job.org kannst du festlegen, wann diese Aktionen ausgeführt werden sollen, regelmässige, wie oft etc.
Es wäre sinnvoll, die cronjob.php-Datei auch überprüfen zu lassen, ob der letzte CronJob schon lange genug her ist (damit nicht den Server somit gezielt überlasten könnte). Ich baue gerade eine zweite Version einer "Protokoll-Klasse". Du kannst dich bei mir per IM hier melden, in so ca. 2-3 Wochen sollte die fertig sein (komm letzter Zeit nicht mehr dazu).

 

[Destruction]

Nimm einfach Sessions und gut ist.
Mach dir da keinen Stress mit Cookies. Entweder ich bestelle etwas sofort, und wenn ich die Seite schließe dann bin ich selbst schuld

Tschö
MfG
Destruction

 

[SoundSelection]

13 Jahre später, registrierte sich ein Spinner extra um in diesem fünf-tägigen Brainstorming seinen Senf dazu geben zu können!

Bei meinem Warenkorbsystem wird ein 7-Tage-Cookie gesetzt, wenn der Nutzer Cookies akzeptiert und die Warenkorbfunktionen nutzt. Wenn nicht, dann:

selbst schuld

Ich empfehle bei der Erstellung eines neuen Warenkorbsystemes auch an dessen Volumen, verhältnismäßig zum entsprechenden Shop, zu denken. Wenn der Warenkorb mehr verschiedene Artikel beinhaltet als der Shop anbietet, is klarerweise ohnehin was am Code falsch. Aber ein Warenkorb mit 1.200 verschienden Artikeln eines Endverbrauchers klingt genau so merkwürdig wie ein 30MB Warenkorb-Array und das kostet natürlich am Ende etwas Rechenzeit. Blöd, wenn Angreifer mit extremen Warenkörben die Site zuspamen und dabei letztendlich nicht bestellen. Ich wäre verzweifelt, wenn ein Endverbraucher 1.200 Sachen bestellt, die er anschließend innerhalb 14 Tagen wieder zurück sendet. Widerrufsrecht lässt grüßen.
Daher denke ich, dass ein Limit für Anzahl, wie auch für

$size=mb_strlen(serialize((array)$array),'8bit');

eine einfache, zusätzliche Sicherheit darstellt.

 

[sandreas]

Totengräber :-)

und habe Sessions genommen. Cookies wollte ich nicht nehmen,

Sessions funktionieren meist über Cookies und Cookies können durchaus halbwegs sicher konfiguriert werden.

mit den Funktionen serialize und unserialize in einen String umgewandelt und in einer Session abgespeichert/ wieder ausgelesen.

Das würde ich nicht machen. Mit serialize und unserialize Daten in der Session zu speichern sorgt meistens dafür, dass die Daten bei jedem Seitenaufruf in eine Datei auf dem Server geschrieben werden, und zwar mit LOCK. Das ist superlangsam und verhindert z.B. parallele AJAX-Abfragen und Dateien viel langsamer sind als Arbeitsspeicher oder Opcache. Mal ganz davon abgesehen sind serialize und unserialize UNSICHER. json_encode / decode tut ganz genauso gut für reine Daten.

Mein Rat wäre:

• Generiere dir eine kryptografisch sichere Warenkorb-ID (bin2hex(random_bytes(64)), nicht mit uniqid oder sowas)
• Schreibe diesen Warenkorb-ID in einen Cookie (z.B. mit http only und secure flag) mit sehr langer Laufzeit
• Schreibe die Warenkorbinhalte mit Warenkorb-ID, ArtikelID, Titel und Preis in eine Datenbanktabelle
  • Eigentlich reicht erstmal die ArtikelID, aber Titel und Preis sind nützlich, wenn sich der Preis seit dem letzten Aufruf der Seite geändert hat oder der Artikel nicht mehr verfügbar ist (Neuer Preis: 32,39 Euro - oder Der Artikel Clean Code von Robert C. Martin ist nicht mehr verfügbar).
• Ist der Benutzer schon eingeloggt, ordne die Warenkorb-ID der User-ID zu (in einer Tabelle user_baskets)
• Bereinige diese Tabelle regelmäßig