Hallo Stefan,
wenn du auf 5.7.15 bist, musst du leider bis zum oben genannten Release von 5.7.16 warten
Viele Grüße aus Schöppingen
Michael Telgmann
bin neu im forum, da ich auch das Problem habe. Habe #26662 und #26666 auf nein gesetzt. Caches geleert, Browser Catch (Firefox) geleert, Windows 10 Pro neu gestartet und…nichts hilft. Problem immer noch vorhanden!!! Trotzdem Danke steffffi. Der Versuch war es wert 
Auch security-Plugin 1.137, wie von @Michael_Telgmann beschrieben und auch 1.1.38 haben bei mir das Problem Nicht gelöst. Bin aufgeschmissen!
Hallo Michael, nee bei anderen vielleicht, aber bei uns immer noch nicht. Auch #26662 und #26666 auf nein setzen funktioniert nicht. Alle Catches geleert, auch vom Firefox-Browser, Windows 10 Pro neu gestartet, aber immer noch das Problem vorhanden. Ach ja, Plugin 1.1.38 auch schon am 02.11. installiert. Nichts. Noch ein Vorschlag? - Und welche Garantie gibst du, dass das Problem grundsätzlich mit der Version 5.7.16 behoben ist?Denn es ist sehr teuer, jedesmal ein Backup von einer Fremdfirma machen zu lassen.
Grüße
tj
Hallo,
wir haben heute 5.7.16 geupdatet und unsere Kunden bekommen immer noch den Fehler:
## Invalides Formular-Token!
Die Aktion konnte aufgrund eines invaliden Formular-Tokens nicht durchgeführt werden.
Ein neues Token wurde bereits generiert.Bitte gehen Sie in Ihrem Browser eine Seite zurück und starten die Aktion erneut.
[Zurück zur vorherigen Seite]
Es tritt nicht nur bei Safari auf, sondern auch bei Chrome und Firefox sowohl am Desktop sowie mobile
1 „Gefällt mir“
Jupp, auch bei MS Edge tritt der Fehler auf!
Für alle die im Unterverzeichnis z.B: /staging/ auch noch einen Testshop betreiben wäre die Lösung evtl. vor den Tests einfach die Cookies der Domain zu löschen und dann wirklich nur in Live oder Staging System zu testen.
Sobald man beide Systeme (Domains) im selben Browser öffnet (bei aktivem Sessioncookie) hat man zwei Cookies (Session+token) mit der selben Bezeichnung und Domain aber mit abweichendem Wert drin. Der doppelte Tokencookie führt dann dazu das keine Post Requests mehr durchgehen. (Einloggen, Registrieren, Checkout) usw. ergo Invalides Formular-Token! Meldung.
Vermutlich erklärt das auch warum der Private Modus oft keine Probleme macht.
Strg + F5 reicht nicht aus. Dies leert nur den Cache des Browsers.
Prüfen lässt sich das zB einfach per Mozialla „Web-Speicher“ > Cookies.
Mit der Tastenkombi Strg + Umschalt + Entf läst sich das im Mozialla z.B einfach leeren für die letzte Stunde.
In älteren Shopwareversionen wurde laut unseren Test zwar der Sessioncookie (wie oben beschrieben) doppelt angelegt. Nicht aber der Tokencookie. Vermutlich seit Shopware 5.7.16 findet sich in den Cookies nun immer auch ein zweiter Tokencookie der das Problem dann verursacht.
Für uns war das jedenfalls die Lösung. An sich ist das also kein Fehler in so einem Fall sondern einfach nur eine Überschneidung der Cookies.
Abhilfe würde man wohl auch schaffen, indem man im Stagingsystem in der s_core_shops der Domain des Testsystems bzw dem Shopeintrag eine andere ID gibt. Diese findet sich dann entsprechend in den Cookies wieder.
Vielleicht hilft das jemandem…
1 „Gefällt mir“
Hallo,
schade, hilft UNS leider nicht, aber hoffentlich Anderen. Wir betreiben keinen Testshop zusätzlich. Und bevor das Problem nicht gelöst ist, werden wir auch 5.7.16 nicht updaten weil es für uns nichts bringt (s. FUNtainment-Berlin). shopware scheint es auch egal zu sein, denn seit 10 Tagen liest man nichts mehr von denen bzw. @Michael_Telgmann. Bei bereits bestehenden Kunden, die bei Bestellungen die Zahlart nicht ändern, funktioniert es ja. Aber Neukunden müssen sich einen anderen Shop suchen, was dann natürlich negativ auf uns zurückfällt und nicht auf shopware.
Hallo,
wir haben jetzt noch einmal ausgiebig getestet und meinen Bruder gebeten, sich zu registrieren und eine Testbestellung zu machen. Folgendes ist dabei herausgekommen:
- Neukunden-Registrierung funktioniert mit Zahlart-Festsetzung
- Bestellung funktioniert
- MWSt.-Berechnung funktioniert gar nicht. Wir arbeiten mit JTL-Wawi. Egal, ob man die MWSt. horizontal oder vertikal berechnet und auch egal, ob 1 Stück oder 150 Stück. Jedesmal stimmt der MWSt.-Betrag und somit auch der Endbetrag nicht überein. Kontrolle, ob die 7% und 19% überall richtig eingesetzt sind: JAA!! Anmerkung: Wir sind ein B2B-Shop. Die falsche MWSt.-Berechnung hat aber natürlich nichts mit diesem Formular Token-Problem zu tun.
- Da die/der Kundin:e ja bei der Registrierung eine Zahlart festgelegt hat, funktioniert die Bestellung im Shop. Aber nur, wenn die/der „neue“ oder „alte“ Kundin:e bei der Bestellung die Zahlart NICHT wechselt. Wechselt Sie /Er diese und geht auf „weiter“, dann erscheint die „Ivalides Formular Token“-Seite.
Mein Bruder, der sich registriert hat arbeitet wie wir mit dem Firefox-Browser.
Vielleicht ist diese Info ja hilfreich.
Guten Abend allerseits
Also, das Problem damals war, dass Safari die Cookies anders behandelt hatte als der Chrome Browser.
Dadurch sind bis 5.7.16 noch erweitere Abbrüche mit Safari entstanden.
Deine erwähnten Probleme könnten dadurch entstehen, dass nach einem Login, ein neuer CSRF Token angefragt wird.
Dies passiert im Hintergrund, und dauert etwas.
Wenn jemand in dieser Zeit nun bestellt oder eine Zahlungsart ändert, entsteht der genannte Fehler.
Falls Du das Problem aktiv nachstellen kannst, bitte ich Dich darum, ein Support Ticket zu erstellen.
Dann werden wir das im Detail prüfen.
Hallo zusammen,
bin auf SW 5.7.16 und hatte nun plötzlich seit dem Update keine Bestellungen mehr, erst heute hat ein Kunde mir das gemeldet:
Browser Chrome, WIN 10…also keine Spur von Safari oder iOs
Habe dann wie folgt einige Dinge ausprobiert:
CSRF Protection in der config.php auf false gesetzt >> Fehler besteht weiter
Plugin Manager / Sicherheitsmodus aktiviert >> Fehler besteht weiter
.htaccess …dort lag bei mir das Problem, … mod_headers Eintrag.
VORHER:
<IfModule mod_headers.c>
Header always edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
Header always set X-Xss-Protection "1; mode=block"
Header append X-Frame-Options SAMEORIGIN
Header always set Strict-Transport-Security "max-age=31536000"
Header set Referrer-Policy "no-referrer"
Header set X-Content-Type-Options "nosniff"
Header always unset "X-Powered-By"
</IfModule>
Alle Zeilen des mod_headers Eintrages bis auf diese eine entfernt:
<IfModule mod_headers.c>
Header append X-Frame-Options SAMEORIGIN
</IfModule>
Danach läuft der checkout wieder normal… KEINE Fehlermeldung mehr…
Die oben angeführten mod_Headers Einträge habe ich denke ich schon mehr als 4 Jahre so in Verwendung, warum das jetzt nach dem Update auf 5.7.16 zum Problem wurde, weis vielleicht jemand von Shopware hier ???
Update: genau genommen die Zeile " Header always edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure " ist/war das Problem.
Danke und LG Klaus
1 „Gefällt mir“
Vielen Dank,
wir haben uns mal in den Zahlarten umgesehen und bemerkt, dass ggfs. das PayPal-Logo, welches wir damals mit dem Plugin zusammen installiert haben, sehr groß ist und auch einen scheußlichen, großen grauen Balken im Hintergrund hat.
Daraufhin haben wir im Backend in den Zahlungsarten bei PayPal die Daten in „zusätzliche Beschreibung“ kopiert, gesichert und dann entfernt und siehe da, keine Probleme mehr.
Sodann haben wir das PayPal-Logo aus der Sidebar kopiert und es dann wie folgt eingesetzt:
/custom/plugins/SwagPaymentPayPalUnified/Resources/views/frontend/_public/src/img/sidebar-paypal-generic.png"
Dann natürlich speichern und shop Cache leeren.
Wir haben mit einem Stammkunden bestimmt 20 Testbestellungen gemacht und immer hat der neue CSRF Token blitzschnell, so wie es sein soll, „geantwortet“.
Auch konnte unser Kunde jetzt ohne Probleme im Konto Dashbord die Zahlart ändern und die beiden Buttons unten (zurück) und (Ändern) wurden auch angezeigt. Vorher haben die gefehlt.
Wir vermuten, dass jetzt einfach weniger Speicherplatz benötigt wird. Aber das ist, so wie es scheint, nur für uns speziell
eine Lösung. Denn @klausm hat wohl für sich eine andere Lösung gefunden.
Danke für den Hinweis und für alle frohe Weihnachten und für 2023 alles Gute!
tj
1 „Gefällt mir“
Hallo Zusammen,
ich wünsche allen ein gutes und gesundes neues Jahr!
Seit 5.7.16 tritt bei mir das Problem mit dem „Invalid Formular-Token“ immer auf unabhängig vom Browser und Betriebssystem des Client.
Bis Version 5.7.15 hatte ich das Problem nicht.
Meine Recherche ergab: Die Funktion clearExistingCookie() ab Version 5.7.16 verursacht das Problem, zumindest in meiner Installation.
Gibt es hierzu eine Lösung? Oder bin ich der Einzige, bei dem das Problem seit 5.7.16 auftritt?
Beste Grüße
Dirk
Leider existiert der Fehler bei uns immer noch. Es ist die aktuelle Shopwareversion 5.7.16
Danke und VG Nadja
Gibt es hierzu mittlerweile eine Lösung?