Mit der Version 1.1.29 des Security Plugins und mit 5.7.10 müssen sich die Kunden mit bestehender Session nicht erneut einloggen und bekommen auch keinen CSRF Token Fehler mehr angezeigt.
Mit 5.6.10 bleibt die Anzeige aber mit erneutem Login, richtig, bei alten Sessions? Also das ist dann eine einmalige Sache für Bestandskunden?
Ist ja nicht so ein Problem.
nicht, wenn du das Security Plugin 1.1.29 nutzt
Ja, ich meinte, es ist eine einmalige Geschichte, richtig? Das passiert jetzt jedem Bestandskunden nicht bei jedem Login?
@Steffffi das sollte mit dem neuen Update nicht mehr passieren, wenn eine neue Session gestartet wird. Wir aktualisieren jetzt initial den Cookie.
Es könnte nun noch mal einmalig für heute Sessions passieren.
1 „Gefällt mir“
Die Token Abfrage wird nach erneuten Leeren des Caches wieder vorgenommen.
Ich geb das jetzt im Security Plugin (26662+26666) raus und mache keine Updates mehr die naechsten 10 Jahre.
1 „Gefällt mir“
Update durchgeführt, config.php in den Originalzustand versetzt, Cache geleert, nach dem Abmelden und dem erneuten Anmelden kommt der Token-Fehler, nach dem Zurückgehen und der erneuten Anmeldung funktioniert die Anmeldung, jedoch erweckt der Text den Eindruck, dass es ein schwerwiegendes Sicherheitsproblem im Anmeldeprozess gibt und das schreckt Kunden massiv ab, ich werde also wieder die config.php editieren und hoffe, dass es irgendwann eine saubere Lösung gibt.
Ich habe auch das Plugin installiert, auch das neuste jetzt.
Wenn ich die 26662 auf JA stelle, kommt jedes Mal bei Variantenartikeln, wenn mal eine Variante auswählt Fehler 404 „Ups, etwas ist schiefgelaufen“… Wenn ich die 26662 auf Nein stelle geht es wieder. Sollte man die 26666 auch auf Nein stellen?
Hat das noch jemand, dass die Varianten nicht gehen?
Viele Grüsse
FYI - Habe bei mir die Varianten geprüft, die funktionieren einwandfrei.
1 „Gefällt mir“
ja, 26666 auch auf Nein, zumindest bei mir, 5.6.10
Das ist ein einmaliger Fehler, danach sollte alles ordnungsmäßig funktionieren.
Falls nicht, bitte erstelle ein Ticket mit einer genauen Beschreibung des Problems und wie Du es erzeugt hast oder bitte stelle ein Support Ticket ein.
Wir helfen Dir gerne dabei, das Problem genauer zu untersuchen!
FYI - @P.Thesing - noch mal die config.php zurückgesetzt, alles neu kompiliert und dann mit einem anderen Browser geprüft, der Fehler ist jetzt weg. Vielen Dank und schönes Wochenende
1 „Gefällt mir“
das Problem besteht weiterhin, wenn man schon einen __csrf_token-1 Cookie von dem Live-Shop hat. Das war aber schon „immer“ so. Aber vielleicht kann man es in diesem Zusammenhang fixen?
Cache löschen, Chrome Cache löschen, Login mit 26662 auf Ja und 26666 auf Nein: invalid token.
Cache löschen, Chrome Cache löschen, Login mit 26662 auf Ja und 26666 auf Ja: invalid token.
Beide Male mit Private Modus. An den Cookies liegt es also nicht.
Hallo @Michael_Telgmann,
ist es möglich, dass der Fix im jüngsten Update nicht greift, wenn der Shop im Unterverzeichnis läuft?
- Denn bei aktiver csrfProtection (frontend) ist die Gast-Bestellung nicht möglich. Ausgegeben wird die Warnung:
Shopware\Components\CSRFTokenValidationException: The provided X-CSRF-Token for path „/shop/register/saveRegister/sTarget/checkout/sTargetAction/confirm“ is invalid. Please go back, reload the page and try again. in /engine/Shopware/Components/CSRFTokenValidator.php:167 Stack trace:
#0 /engine/Library/Enlight/Event/Handler/Default.php(90): Shopware\Components\CSRFTokenValidator->checkFrontendTokenValidation()
#1 /engine/Library/Enlight/Event/EventManager.php(207): Enlight_Event_Handler_Default->execute()
#2 /engine/Library/Enlight/Controller/Action.php(171): Enlight_Event_EventManager->notify()
#3 /engine/Library/Enlight/Controller/Dispatcher/Default.php(467): Enlight_Controller_Action->dispatch()
#4 /engine/Library/Enlight/Controller/Front.php(225): Enlight_Controller_Dispatcher_Default->dispatch()
#5 /engine/Shopware/Kernel.php(197): Enlight_Controller_Front->dispatch()
#6 /vendor/symfony/http-kernel/HttpCache/SubRequestHandler.php(85): Shopware\Kernel->handle()
#7 /vendor/symfony/http-kernel/HttpCache/HttpCache.php(479): Symfony\Component\HttpKernel\HttpCache\SubRequestHandler::handle()
#8 /engine/Shopware/Components/HttpCache/AppCache.php(266): Symfony\Component\HttpKernel\HttpCache\HttpCache->forward()
#9 /vendor/symfony/http-kernel/HttpCache/HttpCache.php(269): Shopware\Components\HttpCache\AppCache->forward()
#10 /vendor/symfony/http-kernel/HttpCache/HttpCache.php(285): Symfony\Component\HttpKernel\HttpCache\HttpCache->pass()
#11 /engine/Shopware/Components/HttpCache/AppCache.php(147): Symfony\Component\HttpKernel\HttpCache\HttpCache->invalidate()
#12 /vendor/symfony/http-kernel/HttpCache/HttpCache.php(213): Shopware\Components\HttpCache\AppCache->invalidate()
#13 /engine/Shopware/Components/HttpCache/AppCache.php(117): Symfony\Component\HttpKernel\HttpCache\HttpCache->handle()
#14 /var/www/vhosts/xxx.com/httpdocs/shop/shopware.php(122): Shopware\Components\HttpCache\AppCache->handle()
Beim Stage-Shop im Unterverzeichnis shop/stage/ tritt der Fehler dagegen nicht auf…
VG Armin
wie auch immer, irgendwas passt da noch nicht. Bei mir waren die Cookies auffällig. Ich hoffe Shopware bleibt dran.
der Error erscheint, wenn du noch die Debug Optionen in der config.php hast und der CSRF Token invalide ist.
Das ist der normale Zustand und hilft für Debug Zwecke.
Bitte entferne einmal die Debug Optionen, gehe auf die index Seite, lösche deine Cookies und reloade die Seite.
Wir hatten in einer Testumgebung jetzt die Konstellation SW 5.7.9 + Security Plugin 1.1.29. Caches mehrfach geleert - Login ging immer erst beim 2. Versuch, da beim 1. Versuch der CSRF Fehler kam. Nach Update auf 5.7.10 war der Fehler in dieser Umgebung nicht mehr da.
Ja, aber erst nach Update auf 5.7.10, wie auch ein Vorposter sagt.
Bei 5.6.10 ist es nach wievor da und beide Fixes müssen auf Nein stehen damit nicht bei jedem Login die Token Info kommt.
Ich gehe mal davon aus, dass das so bleiben wird und ist mir auch, gelinde gesagt, schön langsam egal.
Wir haben auch einen 5.6.10er. Dort hatte ich den Fehler einmalig nach dem Update auf 1.1.28 im Frontend letzte Woche. Jetzt haben wir bei allen Shops unter 5.7.10 die 1.1.29 mit #26662 deaktiviert (#26666 sollte damit eigentlich nichts zu tun haben), da ja mit der 1.1.29 scheinbar noch einige das CSRF Problem haben. Ich hoffe ja schon, dass das noch weiter untersucht wird…