Ungültiges Anfrage-Token nach Formularversand bei gelöschten Cookies

[Diana]

Hallo Zusammen!
Ich habe folgende schöne Knobelaufgabe für euch:

Fehlerbild
Wenn man das Anmeldeformular abschickt, wird folgender Fehler angezeigt:
###
Ungültiges Anfrage-Token
Was ist das Problem?
Das Request-Token konnte nicht validiert werden.

Der Fehler tritt bei einer POST-Anfrage ohne gültiges Request-Token auf. In Contao 2.10 wurde die Referer-Prüfung durch ein Request-Token-System ersetzt. Wenn das Problem anhält, verwenden Sie eventuell eine inkompatible Drittanbieter-Erweiterung oder haben Ihre Contao-Installation nicht vollständig aktualisiert.
###

Im Logfile steht:
[2023-06-15T06:08:38.518274+02:00] security.INFO: Populated the TokenStorage with an anonymous Token. [] []

Reproduktion
Der Fehler tritt nicht immer auf. Ich kann ihn reproduzieren, indem ich zunächst die Cookies lösche und dann das Formular befülle und abschicke.

Installation
PHP 8.1.13
Contao 4.13.16
Erweiterungen: Notification Center 1.7.1
Netzhirsch/cookie-opt-in-bundle 2.8.42

Das Caching auf der Antwortseite ist ausgeschaltet.
Die Seite setzt Cookies für Meta und Google.
Das Formular versendet im Erfolgsfall per Notification Center eine E-Mail über den Standard E-Mail-Gateway.

Für mich klingt es wie dieser Fehler:
https://github.com/contao/contao/issues/2820
Aber der sollte ja in Contao 4.13 behoben sein, oder?

Ich bin ratlos, wo ich weitersuchen soll. Hinweise, die zur Ergreifung dieses Fehlers führen, bitte unten anfügen.

[Spooky]

Poste einen Link zum Formular.

[Diana]

https://dev.bbseminar.de/anmeldung.html

Bei der Seminarnr kannst du TEST eintragen.

[Spooky]

Unabhängig vom aktuellen Problem: auf der Seite wird ungefragt Facebook eingebunden, egal was man im Consent Overlay bestätigt.

[zoglo]

<input type="hidden" name="REQUEST_TOKEN" value="">

Es wird kein Request-Token mitgegeben.
Es kann sein, dass du modifizierte Form-Templates hast, diese müssen an Contao 4.13 angepasst werden.

[Spooky]

<input type="hidden" name="REQUEST_TOKEN" value="">

Es wird kein Request-Token mitgegeben.
Es kann sein, dass du modifizierte Form-Templates hast, diese müssen an Contao 4.13 angepasst werden.

Nein, das ist normal.

[zoglo]

Unabhängig vom aktuellen Problem: auf der Seite wird ungefragt Facebook eingebunden, egal was man im Consent Overlay bestätigt.

Wenn dem so ist, dann sollte man dem Consent-Tool Hersteller den Fehler melden (https://www.netzhirsch.de/contao-coo...in-bundle.html)

[zoglo]

Nein, das ist normal.

Wenn man über HTML irgendeinen RequestToken als Value im Formular mitsendet, funktioniert es aber

DANKE FÜR IHRE ANMELDUNG.
....

[Spooky]

Solange dein POST Request keinen Request Token braucht, generiert Contao auch keinen Request Token.

Ich konnte das Problem auf der Seite jedenfalls nicht reproduzieren.

[conter]

Hallo zusammen,

ich habe das Problem auch immer mal wieder.
Es war dann angesagt, das es mit der aktuellen contao 4.13 gelöst sein sollte.
https://community.contao.org/de/show...l=1#post570579

Leider hat ein Kunde die Fehlermeldung auch mit 4.13 noch mal bekommen ...

Wie geschrieben, ist der Fehler schwer reproduzierbar ist, er tritt nur selten auf, aber die Kunden wollen natürlich zuverlässig (immer) funktionierende Formulare.

Viele Grüße,
conter

[Diana]

Danke für eure Antworten.
Das Template habe ich überprüft. Daher scheint der Fehler nicht zu rühren.
Tatsächlich scheint Ruhe zu sein, seit ich den Facebook-Codeschnipsel ausgebaut habe. Ich beobachte und berichte.

Ob ein Fehler im Consent-Manager vorliegt, ob ich ihn falsch konfiguriert habe oder ob es am Codeschnipsel liegt - da werde ich weiter testen.

[MrLumbergh]

[Moin,

wir haben das selbe oder ein ähnliches Problem abenfalls.

Hier kann ich mich normalerweise in den Mitgliederbereich einloggen. Das Formular bzw. die Seite wurde nicht verändert in letzter Zeit.
Wir sind auf Version 4.9.
Das Request-Token Feld ist leer und wir bekommen den Fehler "Ungültiges Anfrage-Token".

Wir haben schon diverse JS aus der Seite entfernt, weil ich irgendwo im Forum gelesen habe, dass es da zu Problemen kommen könnte...
Lustigerweise ist in meinem Firefox immer ein Request-Token im Value enthalten, dann klappt es. Nicht allerdings, wenn ich einen privaten Tab öffne. Das kann auch Cache sein...allerdings wüsste ich gern, wo das Request Token dann her kommt...

Zumindest kann ich sagen, dass der Fehler erst jetzt auftritt, obwohl das Formular schon jahrelang im Einsatz ist...]

Ich habe ein ce_download Element im Login-Bereich in Benutzung. Dort hatten wir scheinbar ein altes Template zu angelegt - dieses habe ich gelöscht und nun funktioniert der Login.
STRANGE!
Aber es geht - vielleicht hilft Dir das, Diana?

[Spooky]

https://akn.de/geschaeftskunden-login.html setzt ein Session Cookie, aber kein CSRF Cookie. Dem musst du nachgehen. Das Problem ist nämlich, dass dein nächster POST Request dann ein CSRF Token erfordert, weil du ein Session Cookie hast. Da aber initial Contao keines generiert hat, funktioniert das nicht.

Das CSRF Token Cookie würde hier gesetzt werden: https://github.com/contao/contao/blo...criber.php#L75

Du musst nun rausfinden warum CsrfTokenCookieSubscriber::requiresCsrf (vermutlich) false returned, obwohl aber offensichtlich eine Session erzeugt wurde. Ein möglicher Grund könnte sein, dass du in deinem System einen anderen kernel.response Listener hast, der die Session startet - aber nach dem CsrfTokenCookieSubscriber kommt (Priorität geringer als -832).

[MrLumbergh]

https://akn.de/geschaeftskunden-login.html setzt ein Session Cookie, aber kein CSRF Cookie. Dem musst du nachgehen. Das Problem ist nämlich, dass dein nächster POST Request dann ein CSRF Token erfordert, weil du ein Session Cookie hast. Da aber initial Contao keines generiert hat, funktioniert das nicht.

Das CSRF Token Cookie würde hier gesetzt werden: https://github.com/contao/contao/blo...criber.php#L75

Du musst nun rausfinden warum CsrfTokenCookieSubscriber::requiresCsrf (vermutlich) false returned, obwohl aber offensichtlich eine Session erzeugt wurde. Ein möglicher Grund könnte sein, dass du in deinem System einen anderen kernel.response Listener hast, der die Session startet - aber nach dem CsrfTokenCookieSubscriber kommt (Priorität geringer als -832).

Danke Dir!
Aber scheinbar lag es an dem ce_download Element auf der eingelogged-Seite...siehe oben.

[Spooky]

Damit hat das Problem wahrscheinlich nichts zu tun und das Problem ist auf https://akn.de/geschaeftskunden-login.html immer noch reproduzierbar.

[MrLumbergh]

Damit hat das Problem wahrscheinlich nichts zu tun und das Problem ist auf https://akn.de/geschaeftskunden-login.html immer noch reproduzierbar.

Ja, strange. Im Firefox Privattab geht's. Im Chrome Privattab geht's nicht - außer man geht zurück und versucht es nochmal. Dann geht's...

[Spooky]

Um es zu reproduzieren musst du einfach nur alle Cookies der Domain löschen, denn die URL öffnen, dann das Formular abschicken. Egal in welchem Browser.

[MrLumbergh]

https://akn.de/geschaeftskunden-login.html setzt ein Session Cookie, aber kein CSRF Cookie. Dem musst du nachgehen. Das Problem ist nämlich, dass dein nächster POST Request dann ein CSRF Token erfordert, weil du ein Session Cookie hast. Da aber initial Contao keines generiert hat, funktioniert das nicht.

Das CSRF Token Cookie würde hier gesetzt werden: https://github.com/contao/contao/blo...criber.php#L75

Du musst nun rausfinden warum CsrfTokenCookieSubscriber::requiresCsrf (vermutlich) false returned, obwohl aber offensichtlich eine Session erzeugt wurde. Ein möglicher Grund könnte sein, dass du in deinem System einen anderen kernel.response Listener hast, der die Session startet - aber nach dem CsrfTokenCookieSubscriber kommt (Priorität geringer als -832).

Das ist aber ne gute Frage.
Wenn man über die Startseite geht, wird der CSRF Token scheinbar gesetzt - denn dann funktioniert der Login. Startseite aufrufen, dann Geschäftskunden Login Seite).
Dabei nutzen beide Seite das selbe Seitenlayout...

[Spooky]

Wenn man über die Startseite geht, wird der CSRF Token scheinbar gesetzt - denn dann funktioniert der Login. Startseite aufrufen, dann Geschäftskunden Login Seite).

Ja, weil dann schon das Session Cookie vorhanden ist und Contao daher dementsprechend einen CSRF Token erzeugt.

Dabei nutzen beide Seite das selbe Seitenlayout...

Damit hat das nichts zu tun. Siehe https://community.contao.org/de/show...l=1#post573644 - poste z.B. mal die Ausgabe von

debug:event-dispatcher kernel.response

[MrLumbergh]

Ja, weil dann schon das Session Cookie vorhanden ist und Contao daher dementsprechend einen CSRF Token erzeugt.


Damit hat das nichts zu tun. Siehe https://community.contao.org/de/show...l=1#post573644

Ok. Jetzt raste ich aus.
Ich habe nun bei den Userrechten der Seite der "Gruppe" alles erlaubt - und habe nun kein Problem mehr damit, mich einzuloggen...

[Spooky]

Ich habe nun bei den Userrechten der Seite der "Gruppe" alles erlaubt - und habe nun kein Problem mehr damit, mich einzuloggen...

Nein, das Problem besteht nach wie vor. Du musst dich an die Reproduktionanleitung halten, um das Problem zu reproduzieren.

[MrLumbergh]

Ok. Jetzt raste ich aus.
Ich habe nun bei den Userrechten der Seite der "Gruppe" alles erlaubt - und habe nun kein Problem mehr damit, mich einzuloggen...

WTF. Jetzt geht's wieder nicht.

[Spooky]

WTF. Jetzt geht's wieder nicht.

https://community.contao.org/de/show...l=1#post573652

[MrLumbergh]

https://community.contao.org/de/show...l=1#post573652

Hey Spooky,

danke für deine Geduld und so.
Wir haben hier ein Contao, was 2021 von 3.5 auf 4.9 geupdated wurde - wir haben keinen ssh Zugriff. Wir haben keine Anpassungen an kernel oder sowas gemacht. Es ist ein "stinknormales" Contao Projekt.
Und - ich muss ganz ehrlich sein - "warum CsrfTokenCookieSubscriber::requiresCsrf (vermutlich) false returned," kann ich nicht nachvollziehen.

Ich habe jetzt nochmal ausführlich getestet:
Wenn ich die Seite aufrufe, steht "PHPSESSID" unter Cookies. Wenn ich sie RELOADE, steht dort "csrf-https-contao_csrf_token" drin. Nach weiterem Reload wieder "PHPSESSID".
Was bedeutet, dass ich die Seite aufrufen und reloaden kann, um mich einzuloggen. Das ist doch ein komisches Verhalten...

Hast Du noch ne Idee, was ich machen könnte? Update auf 4.13? Könnte das helfen?

[Spooky]

wir haben keinen ssh Zugriff.

Dann prüfe es in einer lokalen Kopie.

Und - ich muss ganz ehrlich sein - "warum CsrfTokenCookieSubscriber::requiresCsrf (vermutlich) false returned," kann ich nicht nachvollziehen.

In wie fern?

Das ist doch ein komisches Verhalten...

Siehe https://community.contao.org/de/show...l=1#post573644

[MrLumbergh]

Dann prüfe es in einer lokalen Kopie.



In wie fern?



Siehe https://community.contao.org/de/show...l=1#post573644

Hey Spooky,

ich denke, wir haben den Fehler gefunden.
Auf der ersten Seite ist ein Login-Formular eingebunden und auf der darauf folgenden Seite war das selbe Formular eingebunden. Wählt man ein *anderes* Login-Formular (mit anderer Weiterleitungsseite), funktioniert alles!

[d33eniz]

Ich grabe das Thema kurz erneut auf:

Wir haben von einem Kunden (bisher) öfter mitgeteilt bekommen, dass so eine ähnliche Fehlermeldung kommt, aber nicht immer:

mspaint_iMEFHsCnKS.png

Blöd ist nur, dass im Log nichts zu finden ist? Wie kann das sein oder woran könnte das liegen? Stinknormales Kontaktformular, mit anschließender Danke-Seite und mehr nicht. In all unseren eigenen Tests ist der Fehler noch nie aufgetreten, er scheint also sporadisch mal hier und da aufzutauchen. Ohne Hinweise in den Log-Files wird es allerdings schwer...

[Spooky]

Welche Contao Version?

[zoglo]

Ich grabe das Thema kurz erneut auf:
Wir haben von einem Kunden (bisher) öfter mitgeteilt bekommen, dass so eine ähnliche Fehlermeldung kommt, aber nicht immer

• Aktualisiere mindestens auf Contao 4.13.41 / Contao 5.3.5 , besser sogar 4.13.42 / Contao 5.3.6
• Wenn du ein angepasstes form_captcha.html5 Template hast, musst du dieses seit Contao 4.13.37 auch aktualisieren

[d33eniz]

Aus Kompatibilitätsgründen noch die 4.9.42 (einige Pluginabhängigkeiten von einem anderen Entwickler). Die form_captcha.html5 haben wir nicht abgeändert.


Komplett gelogen, es läuft die 4.13.38, ich aktualisiere mal und dann beobachten wir das Ganze nochmal! Danke!