Der war gut…
Nur ist das Forum garnicht für offiziellen Support durch Shopware.
*PLONK*
Der war gut…
Nur ist das Forum garnicht für offiziellen Support durch Shopware.
*PLONK*
ja, der Support… Da kommt dann die Frage nach Administratorzugang und FTP Zugang, das war’s dann mit Support. Ich muss gegenüber meinen Kunden bzgl. Datenschutz Grade stehen, sonst niemand, also, hast Du eine bessere Idee? Für mich bleibt eben dann nur das Forum um mir selbst zu helfen.
1 „Gefällt mir“
So ich hab es jetzt nochmals versucht im Demo Shop. Wenn ich das erste Mal die Anzahl des im Warenkorb befindlichen Artikel ändere, kommt der Fehler. Gehe ich zurück und ändere nun, ist alles ok…
ja, der Support… Da kommt dann die Frage nach Administratorzugang und FTP Zugang, das war’s dann mit Support. Ich muss gegenüber meinen Kunden bzgl. Datenschutz Grade stehen, sonst niemand, also, hast Du eine bessere Idee? Für mich bleibt eben dann nur das Forum um mir selbst zu helfen.
Das Vorgehen im Support ist ja relativ einfach, zunächst wird geprüft, ob das Verhalten in einer sterilen Testumgebung reproduzierbar ist. Wenn dies nicht der Fall ist, muss man sich natürlich das Problem auf dem Kundensystem ansehen. Entsprechendes ist ja auch sehr tief in unseren AGBs verankert. Mag sein, dass deine Kunden damit Probleme haben, in der Regel funktioniert dies aber Problemlos. Es gibt ja nur zwei Lösungen:
- Raten, vermuten und im dunklen stochern
- Sich das Problem auf dem System ansehen
Natürlich kann der Support dabei auch entsprechende Daten einsehen, aber ich denke so viel Vertrauen muss man dem Support schon entgegenbringen, Wenn dies nicht der Fall ist, dann braucht man auch keine Professional und auch keinen Wartungsvertrag.
3 „Gefällt mir“
Könntet ihr ja gerne auf einem neutralen Testsystem machen. Das Angebot steht ja, habt ihr aber abgewiesen, da es sich um eine extra Installation handelt auf der lizensierten Domain, dort wäre nach der Aktivierung alles schön reproduzierbar gewesen und das seit Januar 2017, also, so ganz richtig läuft da was nicht bei euch oder es gibt Verständigungsprobleme.
1 „Gefällt mir“
Mit Vertrauen zu argumentieren wird nicht viel bringen, wenn man erst einmal wegen unerlaubter Weitergabe von Kundendaten vor einem Richter steht. Die deutsche Rechtsprechung ist da eindeutig - und das ist auch gut so.
Könntet ihr ja gerne auf einem neutralen Testsystem machen. Das Angebot steht ja, habt ihr aber abgewiesen, da es sich um eine extra Installation handelt auf der lizensierten Domain, dort wäre nach der Aktivierung alles schön reproduzierbar gewesen und das seit Januar 2017, also, so ganz richtig läuft da was nicht bei euch oder es gibt Verständigungsprobleme.
Ich glaube wir reden etwas aneinander vorbei. Ist aber auch nicht weiter tragisch. Hier geht es erstmal primär um den CSRF-Token. Mein Einwurf hatte damit konkret ziemlich wenig zu tun, es ging eher darum, dass man für einen Support auch zugriff auf das System des Kunden braucht. Wenn man den nicht bekommt, wird Support - egal in welcher Form - natürlich schwierig. Hat aber nicht wirklich etwas mit dem CSRF-Problem zu tun.
Meine Kollegen werden morgen einen möglichen Patch einmal in ein paar Kundensystemen (natürlich mit vorherige Nachfrage) testen. Dann haben wir ggf. schon einen potentiellen Fix, der ein paar Probleme beheben wird. Zumindest Probleme die mit einer verlorenen Session zu tun haben. Alles andere wird sich dann noch separat angeschaut.
3 „Gefällt mir“
Meine Kollegen werden morgen einen möglichen Patch einmal in ein paar Kundensystemen (natürlich mit vorherige Nachfrage) testen. Dann haben wir ggf. schon einen potentiellen Fix, der ein paar Probleme beheben wird. Zumindest Probleme die mit einer verlorenen Session zu tun haben. Alles andere wird sich dann noch separat angeschaut.
Hallo Moritz,
gibt es zu den möglichen Patches bereits irgendwelche Infos? Wir brennen vor Neugierde… 
Meine Kollegen werden morgen einen möglichen Patch einmal in ein paar Kundensystemen (natürlich mit vorherige Nachfrage) testen. Dann haben wir ggf. schon einen potentiellen Fix, der ein paar Probleme beheben wird. Zumindest Probleme die mit einer verlorenen Session zu tun haben. Alles andere wird sich dann noch separat angeschaut.
Hallo Moritz,
gibt es zu den möglichen Patches bereits irgendwelche Infos? Wir brennen vor Neugierde…
Ja, mir liegen die neuesten Infos vor, dass CSRF in der Version 5.2.21 entfernt wird. Für alle die, die früher in den Genuß des tollen Features kommen wollen: CSRF Protection
#alternativefacts #fakenews
Meine Kollegen werden morgen einen möglichen Patch einmal in ein paar Kundensystemen (natürlich mit vorherige Nachfrage) testen. Dann haben wir ggf. schon einen potentiellen Fix, der ein paar Probleme beheben wird. Zumindest Probleme die mit einer verlorenen Session zu tun haben. Alles andere wird sich dann noch separat angeschaut.
gibt es zu den möglichen Patches bereits irgendwelche Infos? Wir brennen vor Neugierde…
Erstmal muss das ausreichend getestet/evaluiert werden. Dann gfibt es auch Informationen dazu.
Meine Kollegen werden morgen einen möglichen Patch einmal in ein paar Kundensystemen (natürlich mit vorherige Nachfrage) testen. Dann haben wir ggf. schon einen potentiellen Fix, der ein paar Probleme beheben wird. Zumindest Probleme die mit einer verlorenen Session zu tun haben. Alles andere wird sich dann noch separat angeschaut.
Hallo Moritz,
gibt es zu den möglichen Patches bereits irgendwelche Infos? Wir brennen vor Neugierde…
Ja, mir liegen die neuesten Infos vor, dass CSRF in der Version 5.2.21 entfernt wird. Für alle die, die früher in den Genuß des tollen Features kommen wollen: https://developers.shopware.com/developers-guide/csrf-protection/#disable-the-protection
Das ist kompletter Quatsch.
Hallo,
wir haben unseren potentiellen Fix gestern bereits bei einigen Kunden ausprobiert. Dieser Fix behebt Probleme mit einer abgelaufenen/geänderten Session. Konkret sollte dies also die Probleme mit der Registrierung beheben. Andere Bereiche, die nicht direkt durch dieses Session-Problem einen Fehler werfen, werden noch separat geprüft (bspw. Newsletter). Wir haben die Prüfung auf den Token etwas geändert, sodass nun auf den Inhalt des Cookies geprüft wird und nicht mehr auf den Inhalt der Session. Sollte also aus irgendwelchen Gründen die Session verloren gehen, ist die Prüfung weiterhin erfolgreich.
Ihr könnt das selbst bereits einmal testen.
Datei: /engine/Shopware/Components/CSRFTokenValidator.php
Zeile: 146-149
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());
Bei unseren Testshops war danach kein Fehler mehr in den Core-Logs erkennbar. Wichtig ist natürlich, dass ihr dann den CSRF-Token im Frontend wieder aktiviert.
Wie beschrieben wird dies nicht an jeder Stelle, jede Meldung beheben. Es gibt weiterhin Plugins die einen solchen Fehler werfen und Bereiche, die von uns separat geprüft werden (bspw. die Newsletteranmeldung). Die Registrierungsprobleme sollten dadurch allerdings behoben sein.
Moritz
2 „Gefällt mir“
Also Shop auf HTTPS SSL umstellen klappt auf jeden Fall. Damit konnte man den Fehler schnell umgehen. Ist zwar nicht geklärt warum, aber Fall gelöst und noch HTTPS für den Kunden aktiviert. Mit: https://certbot.eff.org/ auf Linux Root Server fix erledigt. Sollte man in Erwägung ziehen!
Kann ich mir nicht vorstellen, da mein Shop schon immer auf SSL läuft
Das „klappt auf jeden Fall“ können wir auch nicht bestätigen. Wie schon eingangs des Threads erwähnt, hatten wir auch den Eindruck der „Linderung“ nach Komplettumstellung auf https, aber keineswegs war dieses dann die Lösung. D.h., jeder kann und sollte das gerne mal probieren und beobachten was passiert. Allerdings muss man Usern die eine Lösung suchen mitteilen, dass diese Aussage von dkBits in der Pauschalität schlichtweg falsch ist.
Guten Abend Shopware Community,
die Zeilen erreichen Euch aus Tiflis (Georgien). Der ferne Kaukasus benötigt Eure Unterstützung. Ich habe mehrere Stunden aufgewendet um mich im Forum informieren zu lassen. Habe viel versucht und entschlossen mit meinem Anliegen an Euch zu wenden. Habe keinen Nerv mehrJ))
Es geht um folgendes:
Ich versuche einen georgischen Shopwareshop zu meistern.
Ich habe 2 gleiche Versionen von Shopware 5.2.18 auf 2 unterschiedlichen Servern installiert. Einmal bei von Shopware als Test angebotenem Server Profihost und die 2 auf dem Server in Georgien.
Auf dem deutschen Server funktioniert die Kundenlogin soweit einwandfrei. Auf dem georgischen kam immer wieder zu ups meldung mit X-CSRF-Token geschichte und ich habe wie im Forum empfohlen
’csrfProtection’ => [
‘frontend’ => false,
‘backend’ => true
],
benutzt.
Ups Fehlermeldung erscheint nicht mehr, aber das Login funktioniert wieder nicht. Das hat also noch kein einziges mal geklappt. Man wird nicht eingelogt und bleibt auf der gleichen Seite gefesselt.
Die Registrierung funktioniert halbwegs gut. Ich bekomme als Shopbetreiber die „Kundendaten“ auf die Email zugeschickt aber direkt auf der Web Seite bekommt der „Kunde“ keine Meldung nach der Registrierung. (ich weiss nicht ob es so sein soll). Möchte man mit der gleichen Emai adresse neu registrieren kommt die Meldung dass die Adresse bereits registriert ist.
Ich habe dem georgischen Hostinganbieter alles optimieren lassen. Es läuft PHP 7 auf dem server und ion Loader ist auch installiert.
Habe pingelig darauf geachtet, dass bei der Installation auf dem georgischen Server alle von Shopware angegebene Voraussetzungen erfüllt waren.
Das einzige was nicht passen könnte ist
dass APCu und Zend OPcache nicht aktiviert angezeigt werden. Kann es daran liegen, dass die Anmeldung nicht funktioniert?
Die shop Adresse auf dem deutschen Server lautet
http://glimtrex.ge.shopware-hosting.com/
auf dem georgischen
Habe auch mit
if ($request->isPost() && !$request->isXmlHttpRequest()) {
$context = $this->container->get(‘shopware_storefront.context_service’)->getShopContext();
$token = $request->getCookie(’__csrf_token-’ . $context->getShop()->getId()); versucht, aber ohne Erfolg.
Kennt Ihr eventuell einen Rat?
Ich danke im Voraus
Kann ich mir nicht vorstellen, da mein Shop schon immer auf SSL läuft
Ebenso hier, Shop läuft komplett auf SSL, sind trotzdem auf die Nase gefallen.
Sollte ich morgen die Zeit finden, werde ich den Fix einmal testen.
Hat von euch schon jemand den pot. Fix im Einsatz und kann uns hier etwas Feedback geben?
Also, habe den Fix eben getestet - bisher alles prima - keine Fehler mehr - 5.2.20
-
CSRF-Token wieder aktiviert
-
Code in der CSRFTokenValidator.php geändert
-
Shop Cache gelöscht
-
Browser (Firefox) Cache gelöscht
-
Kekse für den Shop gelöscht
-
Backend Login ok (vor dem Login vergessen, die Seite neu zu laden - klar, Fehler)
-
Shopseite neu geladen
-
Mein Konto > Login - ok
-
Testbestellung bis Paypal - ok
-
Testbestellung ohne Konto bis Paypal - ok
Alles im ersten Anlauf und ohne Fehlermeldung.
Hoffentlich bleibt es so 
Grüße, Ralph
Ich kann es leider nicht testen, da ich ja auch ohne Patch keine Probleme habe.
Aber mir ist heute erstmals etwas passiert, was ich nicht ganz zuordnen kann:
Beim Aufruf vom Backend kam gleich das Fenster, dass etwas nicht funktioniert, und im Fenster war CSRF
Soweit - so schlecht - denn: Cookies löschen und Browser neu starten hat nicht geholfen (Chrome). Ein anderer Browser funktionierte.
Nur “Dateien im Cache” löschen brachte mir das Login zurück.
Werden noch irgendwelche Token-Daten in JS-Datein eingesetzt, die ggf. die Sitzung im Browser überleben?