Registrierte Benutzer können sich eine Zeit lang ganz normal einloggen und bestellen. Irgendwann (nach unbestimmter Zeit) läuft das zuvor funktionierende Login dann auf einen nicht näher bestimmten 500er Fehler:
Request URL: https://www.unsershop.de/account/login
Request Method: POST
Status Code: 500
Referrer Policy: strict-origin-when-cross-origin
Der Fehler ist ab dann dauerhaft vorhanden, ein Zugang zum Kundenkonto oder Bestellungen sind dann nicht mehr möglich. Einzige „Lösung“ ist momentan, den betreffenden Kundenaccount neu anzulegen.
Das wirklich nervige an diesem Phänomen ist:
Es wurde bei den betreffenden Kunden zwischendurch nichts an irgendwelchen Kundendaten geändert.
Es betrifft sowohl Kunden die länger nicht aktiv waren als auch Dauerbesteller gleichermaßen.
Das Problem tritt teilweise sogar bei frisch registrierten Kunden beim ersten Loginversuch auf.
Das Live-Debugging (Xdebug) hat bisher keine weiteren Details hierzu ergeben.
Ich weiß, dass mit so einer Fehlerbeschreibung ohne jegliche Details nur schwer zu helfen ist, aber vielleicht hat ja jemand exakt das gleich Phänomen festgestellt und eine Lösung dafür gefunden.
Unsere Infrastruktur sieht wie folgt aus:
1x Datenbank Server
1x Server für diverse Microservices
2x Shopware Front- und Backend Server
1x Loadbalancer (HAProxy) der immer zwischen beiden Front- und Backend Servern wechselt
Shopware 6.4.4.1
Eigenes Theme
Am HAProxy bzw. Loadbalancing kann es eigentlich nicht liegen, da der Fehler auch dann vorliegt, wenn einer der beiden Shopware-Knoten deaktiviert wird. Am Theme liegt es ebenso nicht, wir haben natürlich testweise das Standard-Theme aktiviert.
Ich bin weiter am Debuggen, wäre aber wie gesagt dankbar über jeden Hinweis von anderen, die dieses Problem auch haben. Falls weitere Infos hilfreich wären, lasst es mich bitte wissen.
Ich hätte jetzt auch gesagt das es ein URL Problem ist, guck mal in den Verkaufskanälen, welche Domains dort hinterlegt sind, und versuche es zu lösen indem du alle Varianten mit und ohne www, sowie mit http und https hinterlegst.
[04/Mar/2022:14:56:28 +0100] „POST /account/login HTTP/1.1“ 500 179552 „https://www.xxx.de/account/login“ „Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.109 Safari/537.36“
Die Weiterleitung findet über das Formular statt: frontend.account.home.page. Aber das ist ja für alle Accounts identisch…
Hmm, das könnte ich tatsächlich mal noch probieren. Allerdings wäre das schon sehr seltsam, weil bei unveränderter Konfiguration die Logins ja quasi über Nacht nicht mehr funktionieren. Aber schonmal lieben Dank für den Tip
Das kann mit einer nicht mehr zur Verfügung stehenden Zahlart auftreten. Habt ihr eventuell den Zahlungsanbieter gewechselt und im Verkaufskanal Zahlungsarten entfernt?
In diesem Fall direkt über die Datenbank die default_paymentId (oder ähnlicher Name) in der Customer Tabelle ändern.
Ja, das ist das access.log. Es gibt leider in keinem weiteren log einen Eintrag zu diesem Fehler. Laut unserem Sysadmin sind alle Möglichkeiten des Loggings ausgeschöpft…
Nein, wir haben keinen Zahlungsanbieter gewechselt und es wurden auch keine Zahlungsarten geändert oder entfernt. Es wird lediglich eine Bonitätsprüfung vor Bestellabschluß durchgeführt mittels derer dann gewissse Zahlungsarten für den betreffenden Kunden gesperrt werden. Ich habe aber testweise die Zahlungsart auf Vorkasse eingestellt, die für alle Kunden verfügbar ist. Der Fehler tritt leider immer noch auf
Okay, die Ursache ist gefunden. Bei den betreffenden Kunden lagen Artikel im Warenkorb bzw. in der cart-Tabelle der Shopware Datenbank, die zwischenzeitlich aus dem Sortiment genommen wurden. Sobald der Eintrag in der cart-Tabelle entfernt wird, funktioniert das Login wieder ganz normal.
Ich muss jetzt nur noch herausfinden, wieso bei manchen Kunden der Warenkorb dauerhaft in der Datenbank persistiert wird. Wahrscheinlich hängt das mit fehlgeschlagener Bezahlung etc. zusammen.
Ich danke allen Beteiligten für die Ratschläge
