Protection für das BE habe ich in der config vorläufig wieder auf “false” gesetzt, weil mein File-Backup sonst nicht durchläuft.
Protection für das BE habe ich in der config vorläufig wieder auf „false“ gesetzt, weil mein File-Backup sonst nicht durchläuft.
Was für ein File-Backup System wird denn durch Shopware beeinflusst? Sinnvollerweise sollten Backup-Systeme unabhängig von der Software laufen, die gesichert wird und außerdem eine Änderung der DB bzw. des Dateisystems während des Backups unterbinden. Ein solches System ist unabhängig von Shopware-Konfiurationen.
Was für ein File-Backup System wird denn durch Shopware beeinflusst? Sinnvollerweise sollten Backup-Systeme unabhängig von der Software laufen, die gesichert wird und außerdem eine Änderung der DB bzw. des Dateisystems während des Backups unterbinden. Ein solches System ist unabhängig von Shopware-Konfiurationen.
Das Backup wird per Script früh morgens über einen Cronjob beim Hoster gestartet.
Es bricht aber immer ab und ich bekomme immer zu der Zeit eine Fehlermeldung (habe ich weiter ober schon gepostet).
Der Token wird ja nur geprüft, wenn auch ein Request auf den Shop abgefeurt wird. Ich wüsste nicht, warum ein Backup das machen sollte - da kann irgendwas bei deinem Backup-Mechanismus nicht stimmen.
Was für ein File-Backup System wird denn durch Shopware beeinflusst? Sinnvollerweise sollten Backup-Systeme unabhängig von der Software laufen, die gesichert wird und außerdem eine Änderung der DB bzw. des Dateisystems während des Backups unterbinden. Ein solches System ist unabhängig von Shopware-Konfiurationen.
Das Backup wird per Script früh morgens über einen Cronjob beim Hoster gestartet.
Es bricht aber immer ab und ich bekomme immer zu der Zeit eine Fehlermeldung (habe ich weiter ober schon gepostet).
Es ist genau wie @Moritz es schon gesagt hat: der externe Backup Mechanismus hat nichts mit dem Shop zu tun und kann den Fehler nicht auslösen, weil er keine Shopware-Komponente aufruft. Du hast wahrscheinlich ein Plugin im Shop installiert,das das backup machen soll. Dieses wird durch den Cronjob angestoßen, vermute ich jetzt mal. Deinen „oben stehenden“ Post habe ich nicht gefunden.
Was für ein File-Backup System wird denn durch Shopware beeinflusst? Sinnvollerweise sollten Backup-Systeme unabhängig von der Software laufen, die gesichert wird und außerdem eine Änderung der DB bzw. des Dateisystems während des Backups unterbinden. Ein solches System ist unabhängig von Shopware-Konfiurationen.
Das Backup wird per Script früh morgens über einen Cronjob beim Hoster gestartet.
Es bricht aber immer ab und ich bekomme immer zu der Zeit eine Fehlermeldung (habe ich weiter ober schon gepostet).
Ich weiß zwar nicht, bei welchem Hoster Du bist, bei uns läuft auch ein Backup über Cronjob - auch hier kommt ab und zu eine Fehlermeldung „internal Server…“. Die liegt aber am Timeout/Zeitüberschreitung und wird erzeugt obwohl das Backup korrekt erzeugt wird/wurde.
Falls Du in Deinem Backup-Ordner die komprimierte Sicherungsdatei haben solltest, dann lade sie mal runter und entpacke sie lokal, um zu prüfen ob die Sicherung alle Dateien enthält.
Deinen „oben stehenden“ Post habe ich nicht gefunden.
Eine Seite zurück, wollte das nicht nochmals hier einfügen.
Das Script und der Job läuft für unsere Webseite jeden Morgen einwandfrei, das Script für den Shop ist, bis auf den Pfad, absolut identisch.
Kann euch nicht mehr sagen, als das genau zu der Zeit auch dieser Fehler produziert wird und ich deshalb testweise die Protection im BE abgestellt habe.
Ein Plugin für das Backup habe ich nicht.
Habe den Job eben mal manuel angestoßen, lief einwandfrei. Ob er morgen früh läuft, werde ich sehen.
Deinen „oben stehenden“ Post habe ich nicht gefunden.
Eine Seite zurück, wollte das nicht nochmals hier einfügen.
Das Script und der Job läuft für unsere Webseite jeden Morgen einwandfrei, das Script für den Shop ist, bis auf den Pfad, absolut identisch.
Kann euch nicht mehr sagen, als das genau zu der Zeit auch dieser Fehler produziert wird und ich deshalb testweise die Protection im BE abgestellt habe.
Ein Plugin für das Backup habe ich nicht.
Habe den Job eben mal manuel angestoßen, lief einwandfrei. Ob er morgen früh läuft, werde ich sehen.
Du kannst so nicht feststellen, ob es das File Backup gewesen ist, das den Fehler verursacht hat. Du müsstes in den Server-Logs nachsehen, wer den Aufruf von /backend/Login initiiert hat. Es kann auch ein externer Aufruf gewesen sein.
Ein Filebackup kann so einen Aufruf nicht verursachen, falls dies doch der Fall ist, solltet ihr die Backup Strategie überdenken.
Was für ein File-Backup System wird denn durch Shopware beeinflusst? Sinnvollerweise sollten Backup-Systeme unabhängig von der Software laufen, die gesichert wird und außerdem eine Änderung der DB bzw. des Dateisystems während des Backups unterbinden. Ein solches System ist unabhängig von Shopware-Konfiurationen.
Das Backup wird per Script früh morgens über einen Cronjob beim Hoster gestartet.
Es bricht aber immer ab und ich bekomme immer zu der Zeit eine Fehlermeldung (habe ich weiter ober schon gepostet).Ich weiß zwar nicht, bei welchem Hoster Du bist, bei uns läuft auch ein Backup über Cronjob - auch hier kommt ab und zu eine Fehlermeldung „internal Server…“. Die liegt aber am Timeout/Zeitüberschreitung und wird erzeugt obwohl das Backup korrekt erzeugt wird/wurde.
Das dürfte bei einer vernünftigen Backup-Strategie nicht passieren. Selbst bei der allersimpelsten über einen Shellaufruf von tar/gzip nicht, der über einen Cronjob gestartet wird.
Hat jetzt aber auch nichts mehr mit dem Thread Thema zu tun.
Hallo,
so nebenbei…Ich denke, dass sich der größte Teil darüber einig ist, dass die Backupproblematik ziemlich sicher nichts mit dem Validierungsproblem zu tun hat. Will sagen, es wird gerade etwas Off-Topic.
Nichts für ungut.
1 „Gefällt mir“
Will sagen, es wird gerade etwas Off-Topic.
Nicht für ungut.
Kann möglich sein, wird sich noch raustellen. Wie ich bereits schrieb, kommt der Fehler aber immer zu der Zeit des Backups.
Bzgl. Quelle kann ich im Logfile nichts finden.
Aktuell:
if ($request->isPost()) {
/** @var \Enlight_Components_Session_Namespace $session */
$session = $this->container->get(‚session‘);
$token = $session->offsetGet(‚X-CSRF-Token‘);Ändern in:
if ($request->isPost() && !$request->isXmlHttpRequest()) {
$context = $this->container->get(‚shopware_storefront.context_service‘)->getShopContext();
$token = $request->getCookie(‚__csrf_token-‘ . $context->getShop()->getId());
Meine Rückmeldung dazu: Es funktioniert, wir haben keine Probleme mehr Kundenseitig, das Bestellaufkommen ist seitdem auch wieder angestiegen!!
Das mit dem Newsletterfehler kann ja wirklich von Bots kommen, ist ja auch sowas wie ein Honigtopf das Eingabefeld…
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).
Bemerken möchte ich noch, dass unsere Hauptdomain unter „https://unsere-Domain.de“ erreichbar ist - die Post-Fehler werden über die umgeleitete Seite „http://unsere-Domain.com“ erzeugt.
Kurz vor diesen 3 Zugriffen erfolgen meist Zugriffe einer Suchmaschine (z.B. mj12bot.com, ahrefs.com usw.) in unmittelbar gleicher Zeitspanne.
Auffällig dann noch: der 2. Aufruf ändert sich im Laufe des Tages (statt 29682 auf 29681 bis 29680)
51.15.50.10 - - [20/Mar/2017:21:28:23 +0100] „GET / HTTP/1.1“ 301 196 „-“ „Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1“
51.15.50.10 - - [20/Mar/2017:21:28:25 +0100] „GET / HTTP/1.1“ 200 29680 „-“ „Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1“
51.15.50.10 - - [20/Mar/2017:21:28:27 +0100] „POST /newsletter HTTP/1.1“ 400 3375 „http://unsere-Domain.com/“ „Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1“
Vom heutigen Tage habe ich die Logs erst morgen zur Verfügung.
Kann da jemand was mit anfangen?
Kann ich diese Aufrufe irgendwie sperren? Die anfragende IP ist wie gesagt immer unterschiedlich.
Vom heutigen Tage habe ich die Logs erst morgen zur Verfügung.
Kann da jemand was mit anfangen?
Kann ich diese Aufrufe irgendwie sperren? Die anfragende IP ist wie gesagt immer unterschiedlich.
Das ganze ist off-topic und das Netz ist voll von Ansätzen.
Leidet die Performance deines Shops merklich darunter?
Wieso off-topic?
Das ist doch hier der Sammelthread -oder?
Welche Ansätze meinst Du denn?
Die Performance leidet nicht darunter, da die Zugriffe ca. alle 15-30 Minuten erfolgen.
Wieso off-topic?
Das ist doch hier der Sammelthread -oder?
Welche Ansätze meinst Du denn?
Die Performance leidet nicht darunter, da die Zugriffe ca. alle 15-30 Minuten erfolgen.
Weil es bei diesem Thread nicht darum geht wie man Bots oder IPs sperrt. Darüber wie es geht, findest Du sehr viele Infos im Netz.
Brauche ich die aktuellste Shopware Version (5.2.20) um den Fix, hier von Moritz gepostet,
https://forum.shopware.com/discussion/comment/190065/#Comment_190065
einzubauen?
Mir geht es nicht nur um das Sperren der Bots - in erster Linie geht es mir darum zu zeigen, wann der CSRF-Fehler auftritt. Mein “Fall” dürfte hier für viele Fehlermeldungen bei anderen bestimmt auch zutreffen.
Ich habe ja nicht das Problem, dass hier eine oder wenige IPs zu sperren sind - es sind immer völlig verschiedene.
Was die ganze Problematik noch ein wenig entschärfen würde wäre, wenn die Fehlermeldung nur dann geworfen wird, wenn es sich auch um einen Shopware-Controller handelt. Wenn ein Bot - wie grad mal wieder - alle möglichen Türchen von Wordpress & Co. abklappert, reicht es, wenn Shopware einen 404 wirft, und nicht den CSRF. Solche Meldungen verwirren nur den unversierten Shopbetreiber unnötig.
Für Zugriffe auf fremde “Controller” reichen die Serverlogs und entsprechende Auswertungstools.
1 „Gefällt mir“
Was die ganze Problematik noch ein wenig entschärfen würde wäre, wenn die Fehlermeldung nur dann geworfen wird, wenn es sich auch um einen Shopware-Controller handelt. Wenn ein Bot - wie grad mal wieder - alle möglichen Türchen von Wordpress & Co. abklappert, reicht es, wenn Shopware einen 404 wirft, und nicht den CSRF. Solche Meldungen verwirren nur den unversierten Shopbetreiber unnötig.
Für Zugriffe auf fremde „Controller“ reichen die Serverlogs und entsprechende Auswertungstools.
Genau darum geht’s. Diese CSRF-Fehlermeldungen sind ja sinnvoll - nur wenn man alle paar Minuten eine Fehler-Mail erhält -> nicht gut.
Und für die jetzt folgenden Tipps, die Benachrichtigung abzuschalten: ich will ja trotzdem benachrichtigt werden, falls mal ein Kunde wg. des CSRF-Token rausfliegt.