Fehlermeldung "Ungültiges Anfrage-Token" beim Formularversand

Ich bekomme eine Fehlermeldung beim Formularversand.

Ich habe schon einige Einträge dazu im Forum gefunden (z.B. Hier, Hier und Hier ) aber die haben mir leider auch nicht weitergeholfen, weil noch nicht einmal eine entsprechende Fehlermeldung in einem Logfile finden konnte.

Das Formular hat mehrere Jahre fehlerfrei funktioniert, aber jetzt kommt nach dem absenden eine Contao-Fehlerseite mit dem Hinweis "Ungültiges Anfrage-Token / Das Request-Token konnte nicht validiert werden / Der Fehler tritt bei einer POST-Anfrage ohne gültiges Request-Token auf"

Installiert sind:
Contao 4.9.2
Notification Center 1.5.12
php 7.3.28
Hoster: 1&1

Für das Formular wird das NotificationCenter genutzt, Versand läuft über smtp, entsprechender Zugang ist hinterlegt in der app/config/parameters.yml und an den Zugangsdaten hat sich auch nichts geändert. Das Passwort enthält Sonderzeichen und ist in Hochkommata gesetzt, also so: 'Passwort'

Mir würde es schon weiterhelfen wenn ich wüsste in welchem der verschiedenen Logiles ich eine entsprechende Fehlermeldung finden kann. Ich habe schon im Backend unter System-Log und im Ordner var/logs/prod-2021-06-18.log nachgesehen aber nichts gefunden. Nach meinem Verständnis sollte es ja ein Logfile mit aktuellem Datum geben in dem eine Fehlermeldung mit dem Zeitstempel hinterlegt ist an dem das Formular versendet wurde.

Welche Änderungen sind denn vorgenommen worden seit es das letzte Mal funktioniert hat? Updates? Änderungen am Formular, Änderungen beim Hosting? Ansonsten würde ich mal eine komplette Systemwartung im Backend machen und den Anwendungscache neu aufbauen lassen im Manager. Wenn es nur von einem Browser aus passiert auch mal die Cookies der Domain löschen. Und auch mal ein Update auf die aktuelle 4.9.15 durchführen.

Am System wurden meines Wissens keine Änderungen vorgenommen, beim Hoster (1&1) kann mans ja nie so ganz genau wissen und Systemwartung/Cache Neuaufbau hatte ich schon durchgeführt. Problem taucht in allen Browsern auf.
Update ist im Moment leider keine Option, weil das einen Rattenschwanz nach sich zieht.
Mir ist noch aufgefallen, daß fast alle fehlerhaften Formulare die selbe eMail als Absender und Empfänger haben. Es gibt nur ein Formular bei dem eine andere eMail als Empfängeradresse eingetragen ist und bei dem tritt das Problem nicht auf.

Also habe ich mal versucht bei einem der fehlerhaften Formulare auch diese andere eMail als Empfänger einzutragen - Problem besteht weiterhin.

Interessanterweise funktioniert das eine fehlerfreie Formular auch weiterhin wenn ich bei dem genauso wie bei den fehlerhaften auch die selbe eMail als Absender/Empfänger eintrage.

Als nächstes werde ich wohl mal probieren die fehlerhaften Formulare komplett neu anzulegen oder das eine fehlerfreie zu duplizieren.

Aber das wäre natürlich nur Syptomptomdoktorei und keine Lösung des Grundproblemns...

Nach viel Trial&Error konnte ich das Problem nun lösen.

Die fehlerhaften Formulare befanden sich alle auf Unterseiten einer Hauptseite "Kontakt" und für diese war in den Cache-Einstellungen das Häckchen gesetzt bei "Immer aus dem Shared Cache laden".

Häckchen entfernt und alle Formulare gehen wieder.
Da muß man erstmal drauf kommen, daß sich diese Einstellung auf den Formularversand auswirkt!

Die Cache-Einstellungen vererben sich auf alle Unterseiten und das eine Formular das noch funktioniert hat befand sich eben nicht auf einer Unterseite von "Kontakt".

Wir haben angefangen die Cache-Einstellungen zu nutzen um die Performance der Seite zu verbessern. Wenn ich jetzt die lange Contao-Dokumentation zum HTTP-Caching bis ganz zum Schluß durchgelesen und anschließend nochmal lange ganz scharf drüber nachgedacht hätte, dann wäre ich VIELLEICHT drauf gekommen, daß sich diese Einstellung eventuell auch irgendwie auf den Formularversand auswirken könnte. Ein richtig fetter Hinweis wäre vielleicht doch nicht schlecht? Das Wort "Formular" taucht jedenfalls nirgendwo in der Dokumentation auf...

Zitat:

---

Zitat von Balduin

Nach viel Trial&Error konnte ich das Problem nun lösen.

Wenn ich jetzt die lange Contao-Dokumentation zum HTTP-Caching bis ganz zum Schluß durchgelesen und anschließend nochmal lange ganz scharf drüber nachgedacht hätte, dann wäre ich VIELLEICHT drauf gekommen, daß sich diese Einstellung eventuell auch irgendwie auf den Formularversand auswirken könnte.

---

Wow, wie hättest du denn darauf kommen können ...

Seit unserer Umstellung auf 4.9 tritt das Problem bei uns auch sporadisch auf (was bei Cache-Problemen schon plausibel wäre). Wir senden ein Formular, dessen Antwort nicht von Contao ausgewertet wird, sondern von einem auf der Antwortseite inkludierten PHP-Scxript. Dort fügen wir ein hidden Field mit dem Requesttoken ein. Wenn das gecached wird, dann kommt das falsche token.

Auf jeden Fall schon mal vielen vielen Dank für den Hinweis. Mal sehen, ob es was gebracht hat, dass ich für die betroffene Formularseite das Caching komplett ausgeschaltet habe.

lg B.

Zitat:

---

Zitat von bwl21

Wow, wie hättest du denn darauf kommen können ...

Seit unserer Umstellung auf 4.9 tritt das Problem bei uns auch sporadisch auf (was bei Cache-Problemen schon plausibel wäre). Wir senden ein Formular, dessen Antwort nicht von Contao ausgewertet wird, sondern von einem auf der Antwortseite inkludierten PHP-Scxript. Dort fügen wir ein hidden Field mit dem Requesttoken ein. Wenn das gecached wird, dann kommt das falsche token.

Auf jeden Fall schon mal vielen vielen Dank für den Hinweis. Mal sehen, ob es was gebracht hat, dass ich für die betroffene Formularseite das Caching komplett ausgeschaltet habe.

lg B.

---

Hat leider nichts gebracht, das Problem besteht noch immer ...

Ich steuere das request token über {{request_token}} ein, und werden nun {{request_token|uncached}} probieren.

in der Anfrage sehe ich dass REQUEST_TOKEN manchmal leer ist. das 'uncached' hat leider auch nichts gebracht.

Zitat:

---

Zitat von bwl21

Hat leider nichts gebracht, das Problem besteht noch immer ...

Ich steuere das request token über {{request_token}} ein, und werden nun {{request_token|uncached}} probieren.

in der Anfrage sehe ich dass REQUEST_TOKEN manchmal leer ist. das 'uncached' hat leider auch nichts gebracht.

---

Inzwischen habe ich festgestellt, dass beim allerersten Besuch auf der Seite, bzw. nach dem Löschen der cookies das Problem auftritt. Das müsste doch auch bei anderen Installationen passieren, oder?

Welche Contao Version?

Zitat:

---

Zitat von Spooky

Welche Contao Version?

---

Version 4.9.16

Ich kann beobachten, csrf_https-contao_csrf_token cookie beim ersten Submit angelegt wird.
Das formular, das ich schicke wird aber nicht von Contao geneeriert oder ausgewertet, sondern in einem inkludierten PHP-Script erstellt.

Poste mal einen Link zu diesem Formular.

Zitat:

---

Zitat von Spooky

Poste mal einen Link zu diesem Formular.

---

https://www.bruedergemeinde-korntal....7_Grosser_Saal

Ich konnte dort keinen Fehler feststellen.

Evt. haben manche von deinen Besuchern Cookies in ihrem Browser deaktiviert. In diesem Fall kannst du im Seitenlayout das js_nocookie JavaScript Template aktivieren. Dann bekommen diese Besucher zumindest einen Hinweis, dass sie Formulare nicht benutzen können.

Zitat:

---

Zitat von Spooky

Ich konnte dort keinen Fehler feststellen.

Evt. haben manche von deinen Besuchern Cookies in ihrem Browser deaktiviert. In diesem Fall kannst du im Seitenlayout das js_nocookie JavaScript Template aktivieren. Dann bekommen diese Besucher zumindest einen Hinweis, dass sie Formulare nicht benutzen können.

---

Ich habe deine anmeldung gesehen.

Hat das bei dir auf Anhieb funktioniert?


Wenn keine Cookies da sind, dann ist die Klammer in "Falls Sie hier ( ) nur ein leeres Klammerpaar sehen, dann laden Sie die Seite bitte neu" beim ersten aufruf leer und er hat kein Request-Token. dann funktionert der Aufruf der zweiten Stufe nicht.

Ein einmaliges neuladen der Seite hilft, und das Cookie ist da.

Zitat:

---

Zitat von bwl21

Hat das bei dir auf Anhieb funktioniert?

---

Jup, hat funktioniert.

Zitat:

---

Zitat von Spooky

Jup, hat funktioniert.

---

hm, sehr komisch. wenn ich in den Developer-Tools die Cookies der Seite lösche und dann das Formular neu aufrufen, dann funktioniert es bei mir nicht zum ersten mal. Ich muss die Seit neu laden und dann klappt es.

Der Effekt ist erst seit 4.9 da, mit 4.5 hat es ein Jahr lang klaglos funktioniert.

gibt es eine Funktion über die ich das erstellen eines Request-tokens erzwingen kann?


Offenslichtlich hat sich mein Rumprobieren mit deinem Versuch überschnitten.

ich habe

HTML-Code:

---

<input type="hidden" name="REQUEST_TOKEN" value="{{request_token}}">

---

ersetzt durch

HTML-Code:

---

<input type="hidden" name="REQUEST_TOKEN" value="<?=\Controller::replaceInsertTags('{{request_token}}') ?>">

---

vielen Dank.

B.

Zitat:

---

Zitat von Spooky

Ich konnte dort keinen Fehler feststellen.

Evt. haben manche von deinen Besuchern Cookies in ihrem Browser deaktiviert. In diesem Fall kannst du im Seitenlayout das js_nocookie JavaScript Template aktivieren. Dann bekommen diese Besucher zumindest einen Hinweis, dass sie Formulare nicht benutzen können.

---

Das scheint auch bei mir das Problem gewesen zu sein.
Ich werde das jetzt mal in die Bestätigungsemail reinschreiben.

Zum Einen weiß ich (ich natürlich nicht) sofort an welche Stelle ich
js_nocookie
platziere

zum anderen habe ich die Befürchtung, dass ich es bis zum nächsten Update/ Änderung vergessen habe:o
Die Seit wird nur einmal jährlich gebraucht ( Partyanmeldung) wegen Corona zuletzt 2019 ...

Merkwürdig.
Wenn ich in Safari die Inhaltsblocker ausschalte funktioniert der Link jetzt beim ersten Klick nicht, aber bei einem weiteren Klick doch !?

Zitat:

---

Hallo Jörg!
Vielen Dank für Deine Registrierung bei Kiaora-tonight.

Unten in dieser eMail findest du den Link um Deine Registrierung abzuschließen und Dein Konto zu aktivieren:

Mit dem Klick bestätigst du auch, das Du zur Kenntnis genommen hast wie wir mit Deinen Daten umgehen.

In Bezug auf die neue Datenschutz-Verordnung vom 25. Mai 2018 erklären wir, dass wir als Organisatoren der KiaOra - Party Deine eMail - Adresse und Deinen Namen ausschließlich für die Erstellung der Gästeliste, Vorbereitung und Einladung zur Party nutzen werden. Nur zu diesem Zweck haben wir Deine eMail - Adresse und Namen gespeichert.
Eine Weitergabe an Dritte ist nicht vorgesehen. Weiterhin ist es möglich, dass während der Veranstaltung Fotos gemacht werden und im Nachhinein auf der – nur mit Login und Password zugänglichen - Webseite "www.Kiaora-tonight.de/besucher-info" veröffentlicht werden. Falls Du damit nicht einverstanden bist, bitten wir Dich, uns im Vorfeld schriftlich mit einer eMail an orga@kiaora-tonight.de zu informieren. Weitere Infos zum Umgang mit Deinen Daten findest Du im Impressum.

Dies ist der Bestätigungslink:

https://www.kiaora-tonight.de/regist...235852ba3ed3a5

Der Bestätigungslink ist 24 Stunden gültig.

Wenn Du keinen Zugang angefordert hast, ignoriere bitte diese E-Mail.

---

Im Anhang ein Screenshot wo das js_nocookie aktiviert wird.

Anhang 25868

Viele Grüße,
conter

Zitat:

---

Zitat von bwl21

HTML-Code:

---

<input type="hidden" name="REQUEST_TOKEN" value="{{request_token}}">

---

ersetzt durch

HTML-Code:

---

<input type="hidden" name="REQUEST_TOKEN" value="<?=\Controller::replaceInsertTags('{{request_token}}') ?>">

---

vielen Dank.

B.

---

Stehe auch vor dem Problem.
Wenn sich ein FE-Mitglied anmelden will kommt "Ungültiges Anfrage-Token"

HTML-Code:

---

<input type="hidden" name="REQUEST_TOKEN" value="<?=\Controller::replaceInsertTags('{{request_token}}') ?>">

---

behebt das Problem, allerdings komme ich dann sobald sich ein FE-User anmeldet nicht mehr ins Backend :( Und muss über DB den Admin löschen und im Install-Tool einen neuen anlegen...
Contao 4.9.39

Kann hier nochmal jemand weiterhelfen?

Zitat:

---

Zitat von marcohe

Stehe auch vor dem Problem.

---

Noch der Stack Trace dazu

Zitat:

---

Contao\CoreBundle\Exception\InvalidRequestTokenExc eption:
Invalid CSRF token. Please reload the page and try again.

at vendor/contao/core-bundle/src/EventListener/RequestTokenListener.php:125
at Contao\CoreBundle\EventListener\RequestTokenListen er->__invoke(object(RequestEvent), 'kernel.request', object(TraceableEventDispatcher))
(vendor/symfony/event-dispatcher/Debug/WrappedListener.php:126)
at Symfony\Component\EventDispatcher\Debug\WrappedLis tener->__invoke(object(RequestEvent), 'kernel.request', object(TraceableEventDispatcher))
(vendor/symfony/event-dispatcher/EventDispatcher.php:264)
at Symfony\Component\EventDispatcher\EventDispatcher->doDispatch(array(object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener)), 'kernel.request', object(RequestEvent))
(vendor/symfony/event-dispatcher/EventDispatcher.php:239)
at Symfony\Component\EventDispatcher\EventDispatcher->callListeners(array(object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener)), 'kernel.request', object(RequestEvent))
(vendor/symfony/event-dispatcher/EventDispatcher.php:73)
at Symfony\Component\EventDispatcher\EventDispatcher->dispatch(object(RequestEvent), 'kernel.request')
(vendor/symfony/event-dispatcher/Debug/TraceableEventDispatcher.php:168)
at Symfony\Component\EventDispatcher\Debug\TraceableE ventDispatcher->dispatch(object(RequestEvent), 'kernel.request')
(vendor/symfony/http-kernel/HttpKernel.php:145)
at Symfony\Component\HttpKernel\HttpKernel->handleRaw(object(Request), 1)
(vendor/symfony/http-kernel/HttpKernel.php:81)
at Symfony\Component\HttpKernel\HttpKernel->handle(object(Request), 1, true)
(vendor/symfony/http-kernel/Kernel.php:201)
at Symfony\Component\HttpKernel\Kernel->handle(object(Request))
(web/index.php:31)

---