Bug im Shop? Bestellungen werden dem falschen Kunden zugeordnet

[isd17]

Der Shop wurde mit Version 2.0.x (weiss ich jetzt nicht ganz genau, welche Version) aufgesetzt und dann auf 2.0.4.2. aktiualisiert. Es wurden Module für Versand und Zahlung aktiviert und das Modul "Neue Rechnungsnummer".
Es ist das responsive Template von modified, bei dem die CSS-Styles angepasst wurden. Sonst eigentlich nichts.

[...]

[...]

• [...] (weil der auto-increment-Wert in der customers-Tabelle noch auf 1040 steht) [...]

[...]

ist unmöglich (woher weißt du das eigentlich ?).
[...]

Das sieht man doch in phpmyadmin. Oder habe ich die Frage jetzt wieder nicht verstanden?!

Das Problem liegt wohl wirklich in der customers_id in der Tabelle orders.
Ich habe den Shop parallel auch nochmal lokal hier installiert mit einem Dump der Datenbank vom Webserver.
So wie es aussieht, tritt da der Fehler nicht auf (ist aber schon zu spät, muss ich morgen nochmal genau schauen). Das würde ja dann das Session-Problem als mögliche Ursache bekräftigen, oder?

Der Shop liegt (leider) bei Domainfactory. Hat da jemand anderes ebenfalls Erfahrungen in dieser Art?

[webald]

[...]
Ich habe den Shop parallel auch nochmal lokal hier installiert mit einem Dump der Datenbank vom Webserver.
[...]

Ist das jetzt ein Klon des Live-Shops oder nur die DB des Shops? Hast du mal einen Dateivergleich mit einem jungfräulichen 2.0.4.2 gemacht?

[...]
Das Problem liegt wohl wirklich in der customers_id in der Tabelle orders.
[...]

In der Tabelle orders wird die customers_id nicht hochgezählt, das passiert nur in der Tabelle customers automatisch beim Anlegen eines neuen Datensatzes.

Hängt da noch eine Wawi mit dran, die reinpfuschen könnte? Wo wird die Session gespeichert?

[isd17]

@webald: Es ist der Klon des Live-Shops, also Dateien und DB-Dump. Ich habe lediglich die Config-Datei angepasst, damit der Shop lokal funktioniert.
Den Dateivergleich mit einer neuen 2.0.4.2. Installation habe ich gemacht. Dabei sind mir ja die Unterschiede in der checkout_success.php aufgefallen. Laut Tomcraft ist das aber nicht die Ursache des Problems.

[...]
In der Tabelle orders wird die customers_id nicht hochgezählt, das passiert nur in der Tabelle customers automatisch beim Anlegen eines neuen Datensatzes.
[...]

Ja, das ist mir bewusst. Vielleicht habe ich mich da blöd ausgedrückt.

[...]
Hängt da noch eine Wawi mit dran, die reinpfuschen könnte? Wo wird die Session gespeichert?

Nein, keine Wawi. Die Session wird in der Datenbank gespeichert.

Was mir noch aufgefallen ist:
Ich habe - wie gesagt - den Shop (Dateien und DB) lokal zum testen installiert. Dort habe ich dann die Zuweisungen der customers_id in der orders-Tabelle und der customers_id in der customers-Tabelle soweit alle korrigiert.
Wenn ich jetzt im lokalen Shop zunächst mehrere neue Bestellungen als Gast tätige und danach eine neue Bestellung mit neuem Kundenkonto, funktioniert das. Also in der orders-Tabelle tauchen in der customers_id keine identischen Werte auf - alle sind unterschiedlich.
In der Version auf dem Webserver, gibt es mehrere gleiche customers_id in der Tabelle, obwohl unterschiedliche Gastbestellungen ausgeführt wurden. Wenn dann ein Kunde mit neuem Kundenkonto bestellt, hat dieser auch die customers_id wie die ganzen Gastbestellungen davor.

[webald]

Du hast die Frage nach Cluster oder Cache noch nicht beantwortet.

Was ist mit der Einstellung Gastkonten zu löschen? Ist die aktiv?

Wie alt ist der Shop? Gab es vorher bereits einen Shop unter der gleichen Domain? Welchen in welcher Version?

[isd17]

Du hast die Frage nach Cluster oder Cache noch nicht beantwortet.
[...]

Welche Frage? Wo?

Gastkonten löschen ist aktiv.
Der Shop wurde im November 2017 aufgesetzt und lokal eingerichtet. Umgezogen auf den Webserver und offiziell online ging er aber erst im Nov. 2018. Es ist jetzt die aktuellste Version installiert. Gestartet sind wir meine ich mit Version 2.0.3.0

[webald]

Das mit dem cluster/cahce hatte ich weiter oben schon gefragt. Doppelte Nummer könnten bei nicht korrekt configurierten DB-Cluster auftreten, wenn Daten auf einem Node geänderte werden und gleichzeitig auf einem anderen Node noch der alte Stand abgerufen wird. Hatte ich erst kürzlich, da waren gelöschte Artikel plötzlich wieder da.

Was hälst du davon das löschen der Gastkonten erst mal auszuschalten und zu sehen was dann passiert?

[isd17]

[...]
Wird evtl. ein DB-Cluster oder Caching-Server benutzt?

Sorry, nicht das ich wüsste? Ich habe nichts dergleichen aktiviert, also wird es wohl nicht genutzt. Wie finde ich das heraus?

Ist das löschen der Gastkonten zu deaktivieren dann nicht datenschutzrechtlich irgendwie problematisch?
Welche Auswirkungen hat das? Die Kundendaten bleiben dann alle in der customers Tabelle mit dem Status Gast bestehen. Stehen die dann auch in der Kundenübersicht im Admin-Shop-Bereich?

[webald]

Ob das datenschutzrechtlich problematisch ist kann Dir nur ein Anwalt sagen. Ich sehe das nicht so, da das Konto technisch notwendig ist um die Bestellung überhaupt zu erhalten.

Du kannst das aber mal nutzen um zu testen ob der Fehler dann immer noch auftritt oder ob verschiedene, aufeinander folgende Gäste dann eigene Kundennummern erhalten. Danach kannst Du ja wieder zurückstellen, wenn du ein Datenschutzproblem siehst. Machst Du nix, hast Du in jedem Fall ein Datenschutzproblem, da Du Bestellungen von Kunden Dritten offen legst.

[Tutti73]

In den letzten Tagen kommt dies in dem von mir betreuten Shop auch immer wieder vor, dass neu registrierte Kunden sich melden, dass sie Bestellungen andere Kunden unter Meine Bestellungen sehen können.
Das ist auch im Admin ersichtbar. Die customer_id, die ein Neukunde erhalten hat, wurde in der Vergangenheit bereits für Gäste in der Tabelle orders als customer_id gespeichert.
Warum bekommen Gäste eine customer_id, die in der Tab orders gespeichert wird? Schaue ich mir einen der Fälle an, hat ein und derselbe Gast neun mal bestellt und entsprechend neu verschiedenen (logisch) customer_ids in der Tab. orders erhalten.

modified eCommerce Shopssoftware v2.0.5.1 rev 12725 dated: 2020-04-22
Datenbank Version: "MOD_2.0.5.1"

Der Shop wurde in der Version 1.05 aufgesetzt und fortlaufend über 1.06.x auf die Version v2.0.5.1 upgedatet. Alle Updates erfolgten online in der Produktiv-Installation (kein Backup, Update und Restore).

Viele Grüße
Thorsten

[Tomcraft]

Das passiert, wenn man irgendwann mal der Meinung war Kunden über die Tabelle "customers" zu löschen ohne die Einträge aus der Tabelle "address_book" zu entfernen. Kannst ja mal vergleichen was die jeweils höchste "customers_id" in beiden Tabellen ist.

Grüße

Torsten

[Q]

Torsten, kannst Du das etwas genauer erläutern? Ich habe vermutlich wieder ein Verständnisproblem.

In der Regel macht das ja keiner und ich habe das im Live-Shop irgendwann auch schonmal gesehen - müsste ich mal bei Gelegenheit schauen, ob das immernoch der Fall ist. Von meinem Verständnis dürfte das nur passieren, wenn ich den letzten Eintrag* aus der "customers" lösche und der nächste der dann bestellt die gleiche customers_id bekommt und deshalb der Eintrag in der "address_book"/"orders" "matched". Ich dachte die "customers" hat für die customers_id ein AUTO INCREMENT, oder wird der beim Löschen wieder ein* zurückgesetzt? Und wie verhält sich das, wenn im Backend "Löschen von Gast-Konten" aktiv ist? Werden im letzten Fall dann auch die Einträge im "address_book" gelöscht?

* ein oder mehrere letzte Einträge

[noRiddle (revilonetz)]

Den Zusammenhang mit der DB-Tabelle address_book verstehe ich auch nicht.
Sicherlich sollten in der address_book keine toten Einträge zurückbleiben, aber Bestellungen von anderen Kunden kann man eigentlich nur dann sehen, wenn es Inkonsistenzen mit der Tabelle orders in Bezug auf customers_id gibt.

Gruß,
noRiddle

[Tomcraft]

Da hast du Recht noRiddle! Da habe ich mich mit den Tabellen vertan.

Der AUTO_INCREMENT wird nicht zurückgesetzt beim löschen eines Kunden über den Adminbereich!

Grüße

Torsten

[GTB]

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.

Gruß Gerhard

[Sergio Mueller]

Es ist vermutlich ein Problem mit einer veralteten MySQL Version. Ich habe das in diesem Thread auch mal erläutert: Doppelte Vergabe von customer_id bei Bestellungen? Probleme mit Lexware

Wird ein MySQL Server (vor V8.0) vom Hoster mal neu gestartet, wird der nächste zu vergebende AUTOINCREMENT Wert anhand des letzten vorhandenen höchsten Wertes der customer_id in der customers Tabelle ermittelt. 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.