Hallo,
hast du keine Weiterleitung von http auf https auf deinem Server eingerichtet?
Wenn du “SSL überall verwenden” aktiv hast, solltest du diese Weiterleitung auf jeden Fall einrichten. Das kann durchaus das Problem sein, dass deine Startseite per http:// aufgerufen wird, aber alle Links von Shopware (und so auch der POST-Request) über SSL laufen (Einstellung “SSL überall verwenden” aktiv).
Moritz
Hallo,
hast du keine Weiterleitung von http auf https auf deinem Server eingerichtet?
Nicht explizit in der .htaccess aber in den Server-Grundeinstellungen ist das Ziel „https://meine-Domain.de“ für alle vorhandenen Domains eingestellt. Die „.com“ wird auch auf „https://…de“ in den Servereinstellungen umgeleitet.
Muss die Umleitung auch nochmal in die .htaccess rein?
Kannst du denn http://www.deineseite.de aufrufen? Oder wird dann umgeleitet auf https://?
Kannst du denn http://www.deineseite.de aufrufen? Oder wird dann umgeleitet auf https://?
Wird immer richtig auf https:// umgeleitet. Wir haben insgesamt 8 verschieden lautende Domains, die auf https://meine-Domain.de umgeleitet sind. Egal wie man die aufruft (z.B. http://meine-domain.com -> https://meine-domain.de), man landet immer auf https://meine-Domain.de
Aber wie oben ausgeführt: der CSRF-Fehler wird ja durch den POST-Aufruf richtig ausgelöst. Kein Token, kein Zugriff - alles ok. Die Meldungen nerven halt extrem, innerhalb der letzten 60 Minuten schon wieder 6 mal eine Mail. Jedesmal schaut man rein, ob es vielleicht doch ein Kunde war.
Vielleicht ist der Ansatz von @sonic ja mal wert, weiter darüber nachzudenken, wie die Tokenfehler weiter behandelt werden…
[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski „Moritz Naczenski“) ich habe gerade mal meinen Testshop auf 5.2.21 gebracht und in der config.php CSRFwieder auf true gestellt. Nach den ersten Tests scheint alles soweit zu laufen. Was mir aber jetzt aufgefallen ist, wechsel ich von einem Artikel in die Listenansicht wird mir ein CSRF-Token an die URL gehangen, sieht dann wie folgt aus:
https://www.meinedomain.de/test/herren-t-shirts/?p=1&__csrf_token=jin5js6SLH8OZLnAq6MXiv0QTlVqcK
Ich kenne mich damit jezt nicht wirklich aus, aber ist das Verhalten korrekt?
Edit: Und das ist auch nur der Fall wenn ich über „Übersicht“ in die Kategorie wechsel. Beim zurückgehen über den Browser wird kein Token angehangen.
Hallo,
danke für das Feedback. Gebe ich mal so weiter.
Ist denke ich erstmal eine Unschönheit für den Benutzer des Browsers - hat also erstmal keine Auswirkungen auf die Funktion. Genau kann ich das allerdings nicht beurteilen.
Moritz
Hallo,
danke für das Feedback. Gebe ich mal so weiter.
Ist denke ich erstmal eine Unschönheit für den Benutzer des Browsers - hat also erstmal keine Auswirkungen auf die Funktion. Genau kann ich das allerdings nicht beurteilen.
Moritz
Und wie sieht die große Suchmaschine G…e diese URL?
Und wie sieht die große Suchmaschine G…e diese URL?
Die Suchmaschine bekommt ja erstmal garkeinen Token. Dann kann der auch nicht an die URL angehängt werden. Wenn du auf deiner Seite mal Cookies verbietest, siehst du das auch direkt.
Dann ist ja gut 
[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski „Moritz Naczenski“) ich habe gerade mal meinen Testshop auf 5.2.21 gebracht und in der config.php CSRFwieder auf true gestellt. Nach den ersten Tests scheint alles soweit zu laufen. Was mir aber jetzt aufgefallen ist, wechsel ich von einem Artikel in die Listenansicht wird mir ein CSRF-Token an die URL gehangen, sieht dann wie folgt aus:
https://www.meinedomain.de/test/herren-t-shirts/?p=1&__csrf_token=jin5js6SLH8OZLnAq6MXiv0QTlVqcK
Ich kenne mich damit jezt nicht wirklich aus, aber ist das Verhalten korrekt?
Edit: Und das ist auch nur der Fall wenn ich über „Übersicht“ in die Kategorie wechsel. Beim zurückgehen über den Browser wird kein Token angehangen.
Konkrekt: Im Artikel im breadcrumb auf „Übersicht“ 
Ist in meinem Testshop exakt auch so - und in 5.2.20 nicht.
[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski „Moritz Naczenski“) ich habe gerade mal meinen Testshop auf 5.2.21 gebracht und in der config.php CSRFwieder auf true gestellt. Nach den ersten Tests scheint alles soweit zu laufen. Was mir aber jetzt aufgefallen ist, wechsel ich von einem Artikel in die Listenansicht wird mir ein CSRF-Token an die URL gehangen, sieht dann wie folgt aus:
https://www.meinedomain.de/test/herren-t-shirts/?p=1&__csrf_token=jin5js6SLH8OZLnAq6MXiv0QTlVqcK
Ich kenne mich damit jezt nicht wirklich aus, aber ist das Verhalten korrekt?
Edit: Und das ist auch nur der Fall wenn ich über „Übersicht“ in die Kategorie wechsel. Beim zurückgehen über den Browser wird kein Token angehangen.
Konkrekt: Im Artikel im breadcrumb auf „Übersicht“
Ist in meinem Testshop exakt auch so - und in 5.2.20 nicht.
Dito
Vielen Dank trixx, dass Du den Fehler so schnell gefunden und direkt gemeldet hast
Ich habe diesbezüglich ein Ticket erstellt: Shopware Issuetracker
Der Fehler wurde bereits gefunden und wird zeitnah behoben. Wie Moritz schon geschrieben hatte, handelt es sich hierbei aber nur um einen Schönheitsfehler, der SEO u.a. nicht beeinträchtigt.
Mit der aktuellen Version 5.2.21 wieder der gleiche Fehler:
exception 'Shopware\Components\CSRFTokenValidationException' with message 'The provided X-CSRF-Token for path "/store/newsletter" is invalid. Please go back, reload the page and try again.' in /engine/Shopware/Components/CSRFTokenValidator.php:151 Stack trace:
#0
Mit der aktuellen Version 5.2.21 wieder der gleiche Fehler:
exception ‚Shopware\Components\CSRFTokenValidationException‘ with message ‚The provided X-CSRF-Token for path „/store/newsletter“ is invalid. Please go back, reload the page and try again.‘ in /engine/Shopware/Components/CSRFTokenValidator.php:151 Stack trace:
#0
die Bots werden den Fehler wohl weiterhin verursachen.
Hallo,
wir haben seit zwei Tagen wieder gehäufte Fehlermeldungen mit dem CSRF-Token: wieder greift anscheinend ein Bot auf die Newsletter-Anmeldung zu. Aus dem Server-Log ergeben sich immer 3 zusammen hängende Aufrufe, dann wird der Fehler erzeugt:
199.249.223.78 - - [20/Mar/2017:05:21:13 +0100] „GET / HTTP/1.1“ 301 196 „-“ „Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1“
199.249.223.78 - - [20/Mar/2017:05:21:16 +0100] „GET / HTTP/1.1“ 200 29681 „-“ „Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1“
199.249.223.78 - - [20/Mar/2017:05:21:19 +0100] „POST /newsletter HTTP/1.1“ 400 3376 „http://unsere-Domain.com/“ „Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1“Die anfragende IP ist dabei immer unterschiedlich - aber immer diese 3 gleichen Aufrufe, wobei dann der „POST“-Aufruf den CSRF-Fehler erzeugt (Zeitstempel ist in der SW-Fehlermeldung/SW-Logdatei gleich).
Hallo zusammen,
nur mal kurzes Update zur Problematik „bot verursacht CSRF-Fehler“: der von mir vor 15 Tagen angesprochene Dauerzugriff auf den Newsletter ist abrupt und ohne ersichtlichen Grund seit 2 Tagen abgebrochen und tritt nicht weiter auf. Es dauert zwar, aber anscheinend hat er (der bot) irgendwann die Lust verloren und aufgegeben.
Dann wirkt ja der CSRF-Schutz auch so wie er soll 
Da mich die Fehler-Mails aber trotzdem tierisch genervt haben, habe ich die Mail-Adresse für die Fehler-Mails geändert:
engine/shopware/Plugins/Default/Core/ErrorHandler/bootstrap.php
Zeile 283: $mailer->addTo([„meineFehlerMailAdresse@meineDomain.de“]);
Dann kamen die CSRF-Mails nur noch in dieses Postfach und nicht mehr an die zentrale Shop-MailAdresse.
Leider weiß ich nicht, wie ich diese Änderung update-sicher hin bekomme - meine Lösung greift direkt in den SW-Core. Aber vielleicht passt ja das SW-Team mal den Error-Handler im nächsten Update an und bietet für die Fehlermeldungen eine spezielle Mailadresse als Textbaustein/Variable an. Dürften max. 4-5 Zeilen zusätzlich in der bootstrap sein und man könnte die Mailadresse über das Backend eingeben…
Mit dem Wunsch bist Du wahrlich nicht der Einzige hier. Doch leider hat SW für diesen Wunsch kein Ohr für die Community.
Die System-Mails „Error“ sollten dringend mal von „Shopbetrieb“-Mails getrennt und konfigurierbar gemacht werden. So kommen z.B. meine „Legacy…“-Fehler aus alten Facebookeinrträgen - die brauch ich nicht, fluten aber auch das Postfach bisweilen - darum sind Fehlermeldungen bei mir auch abgeschaltet. Vermutlich wird eher der Teufel katholisch, als das sich hier was ändert.