Neu Shop4 Login Adminbereich wegen CSRF (Cross site request forgery) fehlgeschlagen

  • Wenn Ihr uns das erste Mal besucht, lest euch bitte zuerst die Foren-Regeln durch.

_simone_

Sehr aktives Mitglied
17. Februar 2013
2.237
114
Emsland
#21
Kann es sein, daß beim JTL-Hosting dann die PHP-Einstellungen nicht richtig sind?
Der Wert von "cWert" ist leer, aber es erscheint im Backend-Log immer wieder der folgende Fehler:

Zwischenablage02.jpg
Login macht keine Probleme, also einfach ignorieren?
 

FPrüfer

Moderator
Mitarbeiter
19. Februar 2016
762
121
Halle
#23
Hallo Tom,
diese Logmeldung wird immer dann geschrieben, wenn das Session-Token beim Login-Versuch nicht validiert werden kann. Das passiert z.B. dann, wenn direkt ein POST-Request mit Login-Daten ausgeführt wird, ohne das vorher das Login-Formular angezeigt wurde. Wenn du sehr viele solcher Meldungen im Log hast - und auch im Zshg. mit den Registrierungen innerhalb kurzer Zeit - könnte das ein Hinweis darauf sein, dass irgendwelche Bots versuchen sich im Shop anzumelden, aber nicht clever genug sind und schon an der Token-Validierung scheitern.
Du solltest das aber im Auge behalten ...
 

_simone_

Sehr aktives Mitglied
17. Februar 2013
2.237
114
Emsland
#24
Hallo Tom,
diese Logmeldung wird immer dann geschrieben, wenn das Session-Token beim Login-Versuch nicht validiert werden kann. Das passiert z.B. dann, wenn direkt ein POST-Request mit Login-Daten ausgeführt wird, ohne das vorher das Login-Formular angezeigt wurde. Wenn du sehr viele solcher Meldungen im Log hast - und auch im Zshg. mit den Registrierungen innerhalb kurzer Zeit - könnte das ein Hinweis darauf sein, dass irgendwelche Bots versuchen sich im Shop anzumelden, aber nicht clever genug sind und schon an der Token-Validierung scheitern.
Du solltest das aber im Auge behalten ...
Okidoki, danke für die aufschlußreiche Erklärung. Ich werde es im Auge behalten. 0042.gif
 

mastertango

Sehr aktives Mitglied
10. Oktober 2009
2.193
3
Lüchow
#25
In 99.99% der Fälle ist PHP falsch konfiguriert, sodass keine Sessions geschrieben werden können.
Also ggf. session_save_path etc. prüfen. Wahrscheinlich tritt das Problem auch im Frontend auf? Artikel in Warenkorb legen, Seite neu laden, Warenkorb ist leer?

kannst dud das genauer beschreiben? Wo muss ich was eintragen ?
 

delaware

Aktives Mitglied
23. Juni 2017
197
7
#27
1&1 hat heute etwas umgestellt. Sie sagten das sie bei den Temp Ordnern was umgestellt haben und dadurch wohl diese Probleme auftreten.. Natürlich ist mir der Fehler erst aufgefallen nachdem der JTL Kundensupport schon Feierabend hatte.
Das hasse ich an diesen Laden, dass wenn man dringend Hilfe braucht man niemand erreichen kann.
 
23. Juni 2017
197
7
#29
Nein das ist doch nicht richtig.. 1&1 hat das problem zwar für mich jetzt gelöst haben aber geschrieben :

____________

vielen Dank für Ihre telefonische Anfrage.



Bitte entschuldigen Sie, dass die Rücksprache mit den Admins so lange gedauert hat.

Die Urssache für den Fehler war ein volles System-tmp Verzeichnis. Die Skripte Ihres Shopsystems schreiben die Sessions in dieses Verzeichnis, aber werden nicht gelöscht, wenn die Sessions nicht mehr benötigt werden.

Nachdem wir das tmp Verzeichnis geleert haben ist diese in kürzester Zeit wieder fast vollgelaufen. Das System-tmp Verzeichnes ist 1 GB groß und kann nicht weiter vergrößert werden.

Daher haben wir einen separaten tmp Ordner auf Ihrem Webspace angelegt und per .user.ini Datei diesen als Standardspeicherort für Ihre PHP-Sessions festgelegt. Auf diesen Ordner haben auch Sie per FTP oder SSH Zugriff. Sie können alte Sessions löschen, wenn dieser Ordner zu groß wird.

Optimaler ist es aber in den Skripten festzulegen, dass alte nicht benötigte Sessions nach dem Gebrauch gelöscht werden.
Für die lange Bearbeitung entschuldige ich mich.

Wir hoffen, dass Sie sich zukünftig bei 1&1 IONOS wieder rundum wohl fühlen.

______________

Also lag der Fehler nicht an 1&1 sondern dem JTL Shop der müllt das System-TMP zu und löscht es wohl nicht.
Gibt es dazu Lösungsvorschläge ? Soll man das jetzt immer Manuell über den FTP löschen ?
Jetzt weis ich ja wo sich der Ordner befindet den 1&1 angelegt hat.


meine 3 Shops laufen nun seitdem der Fehler weg ist ca. 3 std und es haben sich schon 105 MB in dem Ordner angehäuft.
Ist das normal ?
 

css-umsetzung

Offizieller Servicepartner
SPBanner
6. Juli 2011
3.044
366
Berlin
#30
Es ist "eigentlich" ein hausgemachtes Problem von 1und1, das bei denen schon immer vorhanden war.
Der beste Weg ist es, jedem Shop einen eigenen Sessionpath zu geben. Langfristig sollte man über einen Wechsel zu einem anderem Anbieter nachdenken, denn 1und1 hat von hause schon Probleme mit der Menge an Dateien die auf einem Server erlaubt sind, hier wird dein Dateicache den du vermutlich verwendest unter Umständen das nächste Problem bringen.
 
11. November 2011
10
0
#31
Nein das ist doch nicht richtig.. 1&1 hat das problem zwar für mich jetzt gelöst haben aber geschrieben :

____________

vielen Dank für Ihre telefonische Anfrage.



Bitte entschuldigen Sie, dass die Rücksprache mit den Admins so lange gedauert hat.

Die Urssache für den Fehler war ein volles System-tmp Verzeichnis. Die Skripte Ihres Shopsystems schreiben die Sessions in dieses Verzeichnis, aber werden nicht gelöscht, wenn die Sessions nicht mehr benötigt werden.

Nachdem wir das tmp Verzeichnis geleert haben ist diese in kürzester Zeit wieder fast vollgelaufen. Das System-tmp Verzeichnes ist 1 GB groß und kann nicht weiter vergrößert werden.

Daher haben wir einen separaten tmp Ordner auf Ihrem Webspace angelegt und per .user.ini Datei diesen als Standardspeicherort für Ihre PHP-Sessions festgelegt. Auf diesen Ordner haben auch Sie per FTP oder SSH Zugriff. Sie können alte Sessions löschen, wenn dieser Ordner zu groß wird.

Optimaler ist es aber in den Skripten festzulegen, dass alte nicht benötigte Sessions nach dem Gebrauch gelöscht werden.
Für die lange Bearbeitung entschuldige ich mich.

Wir hoffen, dass Sie sich zukünftig bei 1&1 IONOS wieder rundum wohl fühlen.

______________

Also lag der Fehler nicht an 1&1 sondern dem JTL Shop der müllt das System-TMP zu und löscht es wohl nicht.
Gibt es dazu Lösungsvorschläge ? Soll man das jetzt immer Manuell über den FTP löschen ?
Jetzt weis ich ja wo sich der Ordner befindet den 1&1 angelegt hat.


meine 3 Shops laufen nun seitdem der Fehler weg ist ca. 3 std und es haben sich schon 105 MB in dem Ordner angehäuft.
Ist das normal ?
Hast Du mal einen Shopabgleich mit der Wawi probiert? Ich habe nömlich das gleiche Problem und ich habe das auch so umgestellt, seit dem geht der Shopabgleich nicht mehr. Siehe Foto
 

Anhänge

css-umsetzung

Offizieller Servicepartner
SPBanner
6. Juli 2011
3.044
366
Berlin
#32
Das bei dir sollte theoretisch nichts mit dem Sessions zu tun haben, da müsste man aber mal genau auf dem Webspace schauen was da wirklich stört.
Eventuell hast du du nicht den session_savepath sondern das tmp Verzeichnis geändert?

Muss man jedenfalls gesehen haben.
 
11. November 2011
10
0
#33
Das bei dir sollte theoretisch nichts mit dem Sessions zu tun haben, da müsste man aber mal genau auf dem Webspace schauen was da wirklich stört.
Eventuell hast du du nicht den session_savepath sondern das tmp Verzeichnis geändert?

Muss man jedenfalls gesehen haben.
Naja, mein Programmierer hat "session.save_path = /homepages/39/........../htdocs/tmpsession/" in die php.ini eingefügt und den tmpsession-Ordner erstellt. Mehr nicht. Ich habe jetzt mal bei JTL ein Ticket erstellt, vielleicht wissen die schon mehr. Muss aber jetzt leider weg, da kann ich erst morgen früh weiter schaun.
 
11. November 2011
10
0
#35
Es ist besser das in die user.ini einzufügen, da die bei 1und1 Verzeichnis Übergreifend ist.
eine php.ini gilt nur in dem Verzeichnis in dem sie liegt, das könnte also auch schon zu Problemen führen.
Guten Morgen. Danke für die Info. Also wir haben es jetzt über die user.ini gemacht und auf den ersten Blick scheint das zu funktionieren. Der Abgleich geht wieder, der Admin-Login geht und man kann auch wieder Artikel in den Warenkorb legen, die dann auch drin bleiben. Leider war die Antwort des Support von JTL, das diese bei 1&1 Problemen kaum noch helfen können, weniger hilfreich. Allerdings stimmt die Aussage, das auch andere Shopanbieter davon betroffen sind. Schlecht ist mal wieder, das 1&1 mir am 08.11. am Telefon gesagt haben, diese hätten nichts geändert. Naja, warten wir es ab, bis zur nächsten Änderung. Danke nochmal.
 

css-umsetzung

Offizieller Servicepartner
SPBanner
6. Juli 2011
3.044
366
Berlin
#36
Schlecht ist mal wieder, das 1&1 mir am 08.11. am Telefon gesagt haben, diese hätten nichts geändert. Naja.
Tja, die machen es sich eben einfach, aber Tatsache ist dass Sie vor einigen etwas geändert haben müssen, denn ich hatte auch mehrere Kunden wo Domains auf einmal nicht mehr erreichbar waren und wenn dann auch noch fast zeitgleich hier mehrere Meldungen kommen das in Shops auf 1und1 Probleme vorhanden sind dann sollte klar sein wer Schuld ist.

Ich verstehe das schon, das JTL selbst da nicht sofort eine Lösung hat, wir als Webworker und SP sind da näher dran an dem Thema und kennen die Macken der einzelnen Hoster besser.
 
11. November 2011
10
0
#39
So, jetzt hat 1&1 irgendwas gemacht. Mal sehen wie lange Bei 1&1 ist dafür gerade die Anzeige für die maximal benutzbaren Dateien voll, wäre angeblich ein Bug. Ich drehe hier voll am Rad.
 

delaware

Aktives Mitglied
23. Juni 2017
197
7
#40
Bei uns funktioniert jetzt alles. Eins und eins hat ein Tempoordner im Hauptverzeichnis angelegt, dort werden nun alle PHP Sessions Temp Dateien abgelegt.

Ich verstehe nicht, warum die Entwickler von JTL Software hier sagen dass wir ein 1&1 problem.

Also normalerweise sehe ich das so dass sich Software Entwickler anpassen müssen und nicht andersherum. Auch wenn JTL das anders sieht, sollten Sie dennoch sowie Kundensupport wie bieten dass ihre Software auf allen Servern anständig funktioniert.
 

Ähnliche Themen