Bug im Shop? Bestellungen werden dem falschen Kunden zugeordnet

[noRiddle (revilonetz)]

@Sergio Mueller
Vielen Dank für die Information. Ein wirklich böser Bug.
Man sollte dazu sagen, daß das nur zutrifft wenn man InnoDB als ENGINE verwendet.
Wieder ein Grund (habe ich bereits mehrfach versucht anzuregen), warum man bei Generierung der Datenbank für die jeweiligen Tabelle die ENGINE festlegen sollte (genauso wie auch bei neuen Tabellen die von Modulen angelegt werden).

Gruß,
noRiddle

[karsta.de]

Das Problem wird wie immer sein, dass der Shopbetreiber oder ein Kunde einen Link mit SessionID in den sozialen Medien oder Newsletter veröffentlicht hat. Dadurch bekommen alle die gleiche SessionID und dadurch kommt es zur Vermischung.

Abhilfe schafft die Session Einstellungen zu ändern.

Cookie Benutzung bevorzugen auf Ja/True stellen.
[...]

Das ist bei uns nicht das Problem. (Shop-Version 2.0.7.2)
Es hängt anscheinend wirklich mit den Einstellungen für Gastkonten zusammen wie von Sergio Mueller herausgefunden wurde:

[...] Hat man Gastkonten und "automatisches löschen" der Gastkonten nach erfolgter Bestellung aktiviert, ist der nächste AUTOINCREMENT Wert dann viel zu niedrig. Dann gibt es die beschriebenen Problem mit den Kundenkonten und falsch zugeordneten Bestellungen.

Das ist wirklich fatal, weil es so zu massiven Verletzungen des Datenschutzes kommt.

BG Karsta

[noRiddle (revilonetz)]

Der Bug ist so unglaublich, daß man auf so etwas nicht kommen würde.
Kannst du denn bestätigen, daß im betroffenen Shop die betroffene Tabelle, also die customers, auf ENGINE InnoDB läuft ?
Ich konvertiere grundsätzlich immer alle Tabellen nach MyISAM, wenn die Default-Engine InnoDB ist und folglich bei Installation des Shops alle Tabellen auf InnoDB angelegt werden..

Ich sage nochmals:

[...]
Wieder ein Grund (habe ich bereits mehrfach versucht anzuregen), warum man bei Generierung der Datenbank für die jeweiligen Tabelle die ENGINE festlegen sollte (genauso wie auch bei neuen Tabellen die von Modulen angelegt werden).
[..]

Das darf auf keinen Fall untergehen und wir sollten dazu ein wenig Nachdruck bei modified erwirken. Dazu müssten wir allerdings die Bestätigung von allen haben, die das Problem nachstellen konnten, oder besser, die auf das Problem gestossen sind, daß die DB-Tabellen auf InnoDB laufen, insbesondere die Tabelle customers.
Auch auf andere Tabellen trifft das Problem allerdings zu, wenn auch nicht mit so gravierenden Folgen.

Ab MySQL 8.0 und MariaDB 10.2.4 scheint das Problem übrigens gefixt worden zu sein.

Gruß,
noRiddle

[Sergio Mueller]

Also bei mir läuft die ganze DB auf InnoDB. War mir ja auch bei der Einrichtung nicht bewusst, dass es diesen üblen Fehler gibt. Ich kann den Fehler forcieren, weil ich keine Möglichkeit habe meinen DB Server (Shared Hosting bei IONOS) selber neu zu starten. Mir ist immer nur aufgefallen, dass es oft eine ganze Zeit lang gut lief. Jedenfalls ist der mir der Fehler nicht aufgefallen, bis mich ein Kunde darauf aufmerksam machte, dass er fremde Bestellungen sieht. Mann müsste irgendwie ein Workaround programmieren, wo die letzte customers_id zwischengespeichert wird. Am besten nicht in der DB sondern vielleicht in einer separaten Datei. Diese müsste dann immer vor dem Anlegen eine neue Kunden geprüft werden. Macht natürlich die ganze AUTO_INCREMENT Sache irgendwie sinnlos. IONOS möchte noch nicht auf MySQL 8 updaten. Wenn ich das möchte muss ich einen eigenen Server mieten.
PS:
Was mir gerade noch eingefallen ist: Wie wäre es denn, wenn man Gastkonten nicht sofort nach der Bestellung löschen würde sondern immer erst dann, wenn ein neues erstellt wird? Quasi immer das vorletzte löschen.

[karsta.de]

[...] Kannst du denn bestätigen, daß im betroffenen Shop die betroffene Tabelle, also die customers, auf ENGINE InnoDB läuft ? [...]

Nein, habe das auch in einem Shop mit MyISAM vor längerer Zeit gehabt (war Shopversion 2.0.4.2). Habe den Shop inzwischen auf InnoDB und die Option Admin > Kunden Details > Löschen von Gast-Konten > NEIN gestellt und zuvor den TABLE customers AUTO_INCREMENT Wert angepasst und das scheint bisher das Problem übergangsweise behoben zu haben.

BG Karsta

[noRiddle (revilonetz)]

@Sergio Mueller
Mit einem Zwischenspeichern der customers_id wäre es ja nur bedingt getan. Wie ich bereits ausführte sind ja alle Tabellen die eine eindeutige ID mit AUTO_INCREMENT haben betroffen. Das macht ja alles inkonsistent.
Imo ist die Lösung alle Tabellen auf MyISAM umzustellen.

@Karsta
Mmh, dann denke ich, daß in dem Fall mit der Shopversion 2.0.4.2 doch GTBs Aussage zutraf. Jemand hat einen Link mit Session-ID irgendwo gepostet. In der genannten Shop-Version gab es ja noch die Einstellung "Session Cookie forcieren" und wenn die auf "Nein" stand konnte das passieren. Nach allem was man im I-Net finden kann hat MyISAM den Bug mit dem AUTO_INCREMENT nicht.
Ich sehe außer des Bugs in MySQL keine Möglichkeit wie das Problem ansonsten zustande gekommen sein kann.

Details > Löschen von Gast-Konten > NEIN ist imo lediglich ein Schein- und Behelfs-Fix.
Man denke daran, daß Kunden ja auch verlangen können, daß ihr Kundenkonto gelöscht wird. In einem solchen Fall hätten wir das Problem ja wieder.

Gruß,
noRiddle

[karsta.de]

[...]
Mmh, dann denke ich, daß in dem Fall mit der Shopversion 2.0.4.2 doch GTBs Aussage zutraf. [...]

Das denke ich nicht, da der Shop weder Links in Social media setzt noch per Newsletter versendet.

[...] lediglich ein Schein- und Behelfs-Fix.
[...]

Deshalb "das Problem übergangsweise behoben zu haben".

[noRiddle (revilonetz)]

Was vermutest du denn bei dem 2.0.4.2-Shop ?
Wie gesagt, MyISAM hat den Bug nicht.

Ich habe übrigens ein Ticket zu dem Problem angelegt: Ticket #2351

Gruß,
noRiddle

[Sergio Mueller]

Bei IONOS habe ich jetzt neuerdings die Möglichkeit eine DB in MySQL V8.0 anzulegen. Wäre es einfach so möglich, dass ich eine neue Datenbank anlege (in V8.0) und den Inhalt der "alten" DB (V5.7) einfach dort rein kopiere? Funktioniert der Shop dann noch normal oder sind Probleme mit MySQL 8.0 zu erwarten ? Die "configure.php" müsste ich natürlich entsprechend anpassen, da es dann ein anderer DB Name, Benutzer und ggf. Passwort ist.

[noRiddle (revilonetz)]

Ich denke das sollte problemlos gehen, insofern deine "alte" DB auf utf8 lief.
Evtl. muß in der configure.php auch DB_SERVER_CHARSET angepasst werden. Ich vermute, daß die neue DB als Default utf8mb4 als Charset hat, was man u.a. auch an der Collation (utf8mb4_general_ci) erkennen kann.
Kannst du aber auch einfach herausfinden, indem du schaust was nach diesem Befehl als "value" erscheint:

Code: SQL  [Auswählen]

SHOW VARIABLES LIKE 'character_set_database';

Gruß,
noRiddle