Kundenkonto wird über 1.300mal angelegt bei manchen Kunden nach Update auf 5.2.6

Seit dem Update auf 5.2.6 wurden jetzt schon 2 Kunden mit einem Schnellbestellungskonto 1.300x vom System angelegt. Beide Kunden sind Stammkunden und haben schon Konten bei uns. Sie wollten neu bestellen und wurden vom System abgelehnt. Trotzdem existieren jetzt diese 1.300 Konten von jedem der beiden Kunden. Woran kann dies liegen???

Hallo wir haben das gleiche Verhalten auch nach dem Update 5.2.5. Auf der DB sieht man, dass die Kundenkonten im Sekundenabstand angelegt werden. Tritt nicht bei allen Kunden auf. Aber alle Paar Tage. Und dann werden Mal 150 Konten, mal 500 zur selben Bestellung erstellt. Alle Gastkonten und alle in 1-2 Sekunden Takt. Laut Shopware ist dieses Problem nicht bekannt, und es hat kein anderer außer uns. Schön, dass es nicht wahr ist.

Was bei allen solchen Bestellungen immer gleich ist: Zahlung mit Paypal. 

Nutzt Ihr Paypal Plus? Shopware hat mir empfohlen Paypal Plus zum Test abzuschulten. Das haben wir noch nicht ausprobiert.

Hallo,

also wir nutzen kein PayPal Plus und die eine Kundin konnte auch gar nicht bestellen. Trotzdem wurde Sie innerhalb von ein paar Sekunden 1.300x angelegt.

Somit ist dies ja für Shopware kein einmaliges Problem. Es gibt wahrscheinlich noch viel mehr Kunden die betroffen sind, aber es fällt nicht immer gleich auf.

Es gibt auch sehr viele Kunden die nicht betroffen sind  Wink

Ihr solltet mal prüfen, welche Plugins ihr ggf. beide im Einsatz habt und diese dahingehend überprüfen.

@Moritz Naczenski schrieb:

Es gibt auch sehr viele Kunden die nicht betroffen sind  Wink

 

Tolle Aussage. Das man sich nach einem Update überhaupt mit so etwas rumschlagen muss reicht wohl nicht. Alles wird immer auf die PlugIn´s geschoben. Wir haben 33 PlugIn´s installiert. Sollen wir jetzt jedes einzelne PlugIn ausschalten und darauf warten, bis dieses Phänomen mal wieder vorkommt? Innerhalb von 3 Tagen war es jetzt bei nur 2 Kunden. Wann und wodurch es auftritt kann zur Zeit wohl niemand sagen.

Naja es ist auch grundsätzlich falsch alles auf die Software zu schieben. Kritische Probleme fallen in der Regel deutlich schneller auf, gerade bei der Menge an Wartungsverträgen die aktiv sind. Da gibt es sehr viele Große Shops die auch eine 5.2.6 online haben und hier keine Probleme haben. Mit jedem Update gibt es Änderungen am Core, die potentiell dazu führen können, dass durch Plugins seiteneffekte entstehen, die es vorher nicht gab. Damit wirst du bei jedem Update rechnen müssen. Natürlich ist soetwas ärgerlich, vermeiden lässt sich das aber generell nicht. 

Natürlich muss man dann individuell debuggen.

  • Gibt es gemeinsamkeiten bei den Kunden? (Kundengruppe, Kundentyp, Klickweg,…)
  • Gibt es Fehlermeldungen im Log zum Zeitpunkt der Registrierung?
  • Was sagt das Access-Log zur Zeit des Problemes?
  • Was sagt das PHP-Errorlog zur Zeit des Problemes?
  • Welche Plugins sind aktiv die in die Registrierung eingreifen?
  • Gibt es Gemeinsamkeiten zu anderen Shops mit diesem Problem?
  • …uvm.

Hier sagt niemand, dass man dir nicht helfen möchte. Das ganze Pauschal aber abzuschieben und zu sagen “Ist ein generelles Problem” halte ich allerdings für falsch. Es kann natürlich immer noch ein Core-Problem sein, ohne Möglichkeit zur Reproduktion lässt sich das aber auch nicht fixen. Insofern solltest du schon deine Zeit investieren und prüfen, ob es die Möglichkeit zum Nachstellen gibt - Wenn es nachstellbar ist, kann man bspw. gezielt Plugins deaktivieren und genauer debuggen.

5 Likes

Hallo baender24, schicke mir bitte eine Liste (oder Screenshot von installierten Plugins per pn). Ich schaue, was wir gemeinsamt haben, was evtl. im Abschlußprozess eine Rolle spielen kann. Alternativ kann ich Dir auch unsere Liste schicken

Hallo Moritz,

auffällig ist, das die Konten alle mit Schnellbesteller erstellt wurden mit der Zahlart PayPal.
Das deutet darauf hin, das der/die Kunden mit PayPal Express bezahlt haben.

In der Datenbank fällt auf, das alle Einträge, von den mehrfach generierten, keine SessionID bekommen haben und im Sek. takt oder 2 Einträge in einer Sek. angelegt wurden.
Zudem hatten die Kunden vorher schon ein Reguläres Kunde als auch eine Schnellbestellkonto. Also bereits 2 Accounts.

Im fraglichen Zeitraum steht in der Core-Logfile nur mehrfach

core.ERROR: exception 'Shopware\Components\CSRFTokenValidationException' with message 'The provided X-CSRF-Token is invalid. Please go back, reload the page and try again.' in

Aber diese Meldung gab es auch schon vorher mal und danach auch.

In den Server Logfiles, deutet es wieder auf PayPal Express hin:

2016/09/11 09:23:14 [error] 19906#0: *6321 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 46. ***.***. ***, server:******.de, request: "GET /payment_paypal/return?token=

Die Zugriffe auf den Server von der IP Adresse zu dem Zeitpunkten deuten ebenfalls auf PayPal Express hin:
 

46. ***.***.***- - [11/Sep/2016:09:09:48 +0200] "GET /payment_paypal/express HTTP/1.0" 200 13468 "https://www.***.de/account/login" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/601.7.7 (KHTML, like Gecko) Version/9.1.2 Safari/601.7.7"
46. ***.***.***- - [11/Sep/2016:09:09:50 +0200] "GET /widgets/index/refreshStatistic?requestPage=/payment_paypal/express&requestController=payment_paypal&callback=jQuery2140******3604163602_ *******&_=******* HTTP/1.0" 200 757 "https://www. ****.de/payment_paypal/express" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/601.7.7 (KHTML, like Gecko) Version/9.1.2 Safari/601.7.7"

 

Die Paypal-Version ist bei euch auch aktuell?
Der CSRF-Token wird ja glaube nur angetriggert bei einem POST-Aufruf. In deinem Logauszug sehe ich nur GET aufrufe. Sehe da so jetzt erstmal keinen direkten Zusammenhang zwischen Fehlermeldung und Access-Log Auszug.

PayPal liegt in der Version 3.4.2 vor.

Ob das nun wirklich der Zusammenhang ist, kann ich nicht direkt sagen. Es fällt nur alles in den selben Zeitraum und deckt sich mit der IP Adresse des Kunden.

Ist jetzt nur eine Vermutung;
GGf. ist es jetzt auch möglich, da die Tabelle s_user nun ein weiteres Feld (customernumber) hat, doppelte Einträge zu generieren?
Also eine Prüfung ob ein Kunde bereits im System ist, fehlschlägt?

Ps.:

Was mir gerade noch auffällt, in der Datenbank sind alle Schnellbestellungs-Accounts als “active = 1” markiert. Einträge aus früheren Schnellbestellungen hingegen nicht. Diese mit mit active = 0

gut, die Anzahl der Betroffenen wächst also.

Ich habe unsere Plugin mit denen von Baender24 verglichen. Wir haben folgende gemeinsam:

  • Paypal
  • Packstation von VIISION
  • Individuelles Dropdown-Menü von Dreischild
  • SOFORT AG
  • Lizenz-Manager
  • CronSrock
  • Cron
  • LastArticles
  • Statistics
  • InputFilter

Da die betroffenen Bestellungen bei uns nicht an die Packstation gingen und alle mit Paypal bezahlt wurden, vermute ich stark, dass es entweder an Paypal oder am Core liegt.

Mal folgende Gedanke: wenn ein Kunde eine Bestellung abbricht, dann wird für ihn ein Gast-Konto ohne Bestellung erstellt. Das ist ein gewolltes Feature von Shopware, damit man abgebrochene Warenkörbe evtl. in Bestellungen umwandeln kann. Weiterhin weiß ich von einem Kunden, für den fast 400 Accounts erstellt wurden, dass er sehr lange auf Paypal weiterleitung gewartet hat. Er meinte am Telefon, das Rädchen dreht sich und dreht sich… Wie schon oben erwähnt, sieht man in der Datenbank, dass die Konten in Sekundentakt erstellt werden. Das ganze mehrere Minuten lang, ohne Unterbrechnung. Das letzte erstellte Konto ist dann eine mit der Bestellung. Ich kenne mich mit dem Core nicht aus, aber diese beiden Tatsachen: lange Wartezeit + ein Gastkonto wird für abgebrochene Bestellunge erstellt, lässt mich vermuten, dass das Problem irgendwo im Core ist, und zwar denkt der Core ab einem gewissen Timeout, dass die Bestellung abgebrochen wurde, wenn nach einer gewisser Zeit keine Rückmeldung vom Paypal kommt. Und das wird dann mehrfacht gemacht. Oder Paypal schickt falsche Rückmeldung (Abbruch). Aber irgendwie diese Ecke.

Übrigens, ich habe die Problem-Kunden mir genauer angeschaut. Viele solche Problem-Fälle hatten kein Account-Konto davor. Entweder hatten sie schon als Gast bestellt, oder als Account oder gar nicht. D.h. mit der Überprüfung ob ein Account schon gibt, sollte es nicht zusammenhängen.

 

@gintes schrieb:

Ich habe unsere Plugin mit denen von Baender24 verglichen. Wir haben folgende gemeinsam:

  • SOFORT AG
  • … 

Hier kann ich erstmal nur sagen, dass das Plugin nicht kompatibel ist. Ich kann es auch in einer aktuellen 5.2 nicht installieren. Es wird also auch mit der neuen Registrierung von 5.2 erstmal nicht kompatibel sein. Das wäre für mich zunächst eine Potentielle Ursache.

 

@gintes schrieb:

Mal folgende Gedanke: wenn ein Kunde eine Bestellung abbricht, dann wird für ihn ein Gast-Konto ohne Bestellung erstellt. Das ist ein gewolltes Feature von Shopware, damit man abgebrochene Warenkörbe evtl. in Bestellungen umwandeln kann. Weiterhin weiß ich von einem Kunden, für den fast 400 Accounts erstellt wurden, dass er sehr lange auf Paypal weiterleitung gewartet hat. Er meinte am Telefon, das Rädchen dreht sich und dreht sich… Wie schon oben erwähnt, sieht man in der Datenbank, dass die Konten in Sekundentakt erstellt werden. Das ganze mehrere Minuten lang, ohne Unterbrechnung. Das letzte erstellte Konto ist dann eine mit der Bestellung. Ich kenne mich mit dem Core nicht aus, aber diese beiden Tatsachen: lange Wartezeit + ein Gastkonto wird für abgebrochene Bestellunge erstellt, lässt mich vermuten, dass das Problem irgendwo im Core ist, und zwar denkt der Core ab einem gewissen Timeout, dass die Bestellung abgebrochen wurde, wenn nach einer gewisser Zeit keine Rückmeldung vom Paypal kommt. Und das wird dann mehrfacht gemacht. Oder Paypal schickt falsche Rückmeldung (Abbruch). Aber irgendwie diese Ecke. 

Der Kundenaccount wird erst angelegt, wenn der Kunde von Paypal zurück in den Shop kommt. Bei der Weiterleitung zu Paypal passiert noch garnichts. Auch das ist also nicht die Ursache für das Problem. Kommen wir aber zum eigentlichen Problem: Reproduzierbarkeit. Ich habe gestern und heute ca. 100 Express Checkouts getestet, in allen Kombinationen die mir eingefallen sind und hatte das Problem so nicht. 

Es muss also irgendwie ein Weg gefunden werden, das Problem einzugrenzen. Konntet ihr es denn bisher selbst nachstellen?
Hat Paypal hier ggf. ein Log und kann das weiter aufschlüsseln?

 

Das Sofort AG PlugIn funktioniert aber einwandfrei und es wurden nach dem Update auch schon viele Bestellungen darüber bezahlt.

Weiterhin haben wir in den letzten Tagen keinen Kunden mehr gehabt, der in dieser Menge angelegt wurde. Somit können wir das Problem auch nicht nachvollziehen bzw. eingrenzen.

Hallo zusammen,

ich habe das selbe Problem - eine Mailadresse, 2123 mal angelegt, 4246 failedlogins

Hier ist nur Paypal als gemeinsamer Nenner

Ein Gast-Konto fällt schon mal raus, da sich die failedlogins nicht häufen würden

Gerade haben wir auch wieder eine Kundin die bereits ein Konto hat und sich einloggen wollte. Das Kundenkonto wurde 500 mal angelegt und sie konnte sich trotzdem nicht einloggen. Bezahlen wollte Sie mir Amazon Payments. Also alles sehr verwunderlich.

Hallo Moritz, Du fragst „Hat Paypal hier ggf. ein Log und kann das weiter aufschlüsseln?“.

Woher sollen wir das wissen, der Hersteller des Plugins ist doch Shopware. 

Reproduzieren kann ich das Problem auch nicht. Es kommt auch nicht bei jeder Paypal-Bestellung vor. D.h. es müssen unterschiedliche Bedingungen gleichzeitig erfüllt sein. Leider weiß man nicht welche. 

Ihr könnt gerne bei uns irgendwelche traces einbauen. Wann der Fall eintritt ist sehr enfach festzustellen. Es werden >1 Gastkonten mit gleicher Email innerhalb kurzer Zeit (z.B. 5 Sekunden) erstellt. 

Auchso, am Paypal Plus liegt es nicht. Hatte es bei uns 3 Tage ausgeschaltet gehabt, trotzdem das alte Problem. 

Habe jetzt SOFORT AG abgeschaltet und werden beobachten

@gintes‍ Moritz meint Logs von Paypal. Also nicht was der Shop bzw. unser Plugih macht, sondern was Paypal auf deren Platform macht.

Die können da ggf. weitere Details zum Kunden/Besrellung/Transaktion ermitteln. Das können wir ja nicht. Da müsstest du mal bei Paypal direkt nachhaken.

Evtl. sehen die das direkt in deren Logs, das Besonderheiten zu deinem Shop bei besagten Kunden gepusht werden

Sebastian

Mit Paydirekt wär das nicht passiert. :wink:
*duckundwech*

Ich bin auf jeden Fall gespanntauf die Ursache.