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

[css-umsetzung]

Ich habs jetzt erstmal selber hingekriegt, es war tatsächlich der volle Speicherplatz auf dem Server, den ich komplett übersehen hatte. Trotzdem werde ich gern auf dein Angebot zurückkommen, wenn mal wieder Probleme auftauchen. Gruß.

sehr gut

Mein Provider ist Greatnet.de. Dort sagt man mir, dass es an der Shop-Software liegen muss. Immerhin will man prüfen, ob das Problem dort gelöst werden kann. Bisher nichts mehr gehört.

Nun weißt du aber auch was du von dem Support zu halten hast, dass muss dem sofort auffallen wenn er deinen Account prüft.

 

[ITMS]

Das Problem ist ja das der Speicherplatz voll ist (habe das gleichen Problem) und keiner weiß warum.
Ich habe beispielsweise nur einen kleinen Shop mit 200 Artikeln und mein Webspace wird mit über 200 GB belegt (???)
Das ist das sehr unwahrscheinlich. Andere haben 800 Artikel und benötigen nicht mal 100 GB

 

[ITMS]

Was ist mit der dbsS\tmp
Die ist bei mir gewaltig?

 

[Mirko.Schmidt User deaktiviert]

Da werden die Daten vom Wawi Abgleich reingeschrieben. Ist in der includes/config.JTL- Shop.de folgendes vielleicht drin
define('KEEP_SYNC_FILES', true);
Dann werden die Dateien nicht gelöscht. Sollte nur für Testzwecke aktiv sein.

 

[css-umsetzung]

Was ist mit der dbsS\tmp
Die ist bei mir gewaltig?

wenn der define define('KEEP_SYNC_FILES', true); nicht gesetzt ist, dann kann es auch sein das deine worker nach einem Update eventuell Amok gelaufen ist, dann überschüttet der den Shop mit Daten, so dass diese irgendwann nicht mehr gelöscht werden können.

Dieses Problem hatte ich bei einem Kunden in zwei verschiedenen Shops.
In jedem Fall würde ich den Worker deaktivieren, die Files aus dem Verzeichnis alle killen, die Config Datei vom Shop prüfen und dann alles wieder in Betrieb nehmen.

 

[ITMS]

Super, danke für den schnellen hinweis.
Mache ich gleich mal.

 

[ITMS]

Also in meiner gibt es einen solchen Eintrag überhaupt nicht.
define('KEEP_SYNC_FILES', true);

Alles was in der:
includes/config.JTL- Shop.ini.php
steht ist:

define('PFAD_ROOT', 'xxxxxxxxxxx');
define('URL_SHOP', 'xxxxxxxxxxx');
define('DB_HOST','xxxxxxxxxxxxx');
define('DB_NAME','xxxxxxxxxxxxxx');
define('DB_USER','xxxxxxxxxxxxxxx');
define('DB_PASS','xxxxxxxxxxxxxxxxxxx');

define('BLOWFISH_KEY', 'xxxxxxxxxxxxxxxxxxx');

//enables printing of warnings/infos/errors for the shop frontend
define('SHOP_LOG_LEVEL', 0);
//enables printing of warnings/infos/errors for the dbeS sync
define('SYNC_LOG_LEVEL', 0);
//enables printing of warnings/infos/errors for the admin backend
define('ADMIN_LOG_LEVEL', 0);
//enables printing of warnings/infos/errors for the smarty templates
define('SMARTY_LOG_LEVEL', 0);
//excplicitly show/hide errors
ini_set('display_e

natürlich mit Daten und nicht mit 'xxxxxxxxxx'

 

[css-umsetzung]

Na dann, einfach mal das Verzeichnis leer machen, den Worker wieder aktivieren und das Verzeichnis den Tag über im Blick haben.
Das tmp Verzeichnis sollte wenn der Worker grade keinen Abgleich durchführt immer leer sein.

 

[css-umsetzung]

Achja, danke für den Blowfishkey, nun muss ich ja nur noch deine DB hacken

 

[ITMS]

Achja, danke für den Blowfishkey, nun muss ich ja nur noch deine DB hacken

Hier laufen doch nur ehrliche Menschen rum oder?

 

[Mirko.Schmidt User deaktiviert]

Habe den mal zensiert

 

[css-umsetzung]

Ich war in TRSI, Alphaflight, Mystic und einigen anderen Groups
Die ältere Generation weiß was das heißt

 

[ITMS]

Auf jeden Fall ist das Problem erst einmal gelöst.
Sage und schreibe 130GB an Daten aus /dbeS/tmp gelöscht.
Die ältesten waren übrigens "Update von 1.3.20 auf 1.3.21 " wo es angeblich nur um die Amazon Flatfiles ging.
Werde das Verzeichnis nun im Auge behalten und schauen ob die Daten nun automatisch gelöscht werden.