Request Token nicht vorhanden

[Misios]

Hallo zusammen,

ich habe ein Problem mit einem fehlenden Request Token (Contao 4.13.37, PHP 8.2.*) bei einer "Passwort-Anfordern"-Seite.
Immerhin kann ich es mittlerweile im Firefox reproduzieren, ich weiss aber nicht, wo der Fehler liegt.

Wenn ich folgende URL im Firefox aufrufe um ein Passwort anzufordern, dann funktioniert das nicht, weil im Formular das value für Request Token leer ist.

https://www.cures.de/passwort-anlege...erbereich.html

Wenn ich VORHER auf eine Page der Website gehe, die ein ein Login-Formular enthält und anschließend zurück gehe auf die Seite mit der Password-Anforderung (diese dann auch wirklich reloade), dann ist ein Request Token vorhanden und alles läuft. Das Login-Formular generiert ein contao_csrf_token und das Passwort-Vergessen-Formular produziert KEIN csrf_token.

Der folgende Ablauf funktioniert also:

https://www.cures.de/passwort-anlege...erbereich.html
https://www.cures.de/login.html
https://www.cures.de/passwort-anlege...erbereich.html (RELOAD)

Im Safari hatte ich die Fehlermeldung mit dem fehlenden Token zwar auch schon, ich kann es dort aber trotz Cache und Cookie löschen nicht reproduzieren. Dort läuft es mir zumindest zu 90% und ist nicht reproduzierbar (durch mich).

Im Firefox reicht es die Cookies der Seite zu löschen, um den Fehler zu reproduzieren.

Am Cookiebanner scheint es nicht zu liegen. Das hatte ich zwecks Test auch schon ausgeschaltet.
Das Mod-Template der Passwort-Anfrage ist unverändert.
Ich habe allerdings vor Kurzem ein Update von 4.9 auf 4.13.37 gefahren. Seit dem gibt es die Probleme.

Weiss jemand Rat?

Danke und Grüße,
Misios

[Spooky]

Könnte in Contao 4.13.41 behoben sein. Aber poste mal deine composer.json

[Misios]

Danke für den Hinweis. ich checke nachher mal, ob das Update was bringt.

{
"type": "project",
"require": {
"codefog/contao-mobile_menu": "^2.7",
"contao/calendar-bundle": "4.13.*",
"contao/comments-bundle": "4.13.*",
"contao/conflicts": "*@dev",
"contao/faq-bundle": "4.13.*",
"contao/listing-bundle": "4.13.*",
"contao/manager-bundle": "4.13.*",
"contao/news-bundle": "4.13.*",
"contao/newsletter-bundle": "4.13.*",
"dklemmt/contao_dk_mmenu": "^4.0",
"do-while/contao-backupdb-bundle": "^1.5",
"hschottm/tags": "^4.9",
"inspiredminds/contao-glightbox": "^1.0",
"madeyourday/contao-rocksolid-antispam": "^2.1",
"madeyourday/contao-rocksolid-columns": "^2.1",
"madeyourday/contao-rocksolid-custom-elements": "^2.4",
"markenzoo/contao-file-helper-bundle": "^2.1",
"markocupic/gallery-creator-bundle": "^1.3",
"oveleon/contao-cookiebar": "^1.14",
"pbd-kn/contao-inputvar-bundle": "^1.0",
"plakart/download-inserttag": "^1.0",
"terminal42/contao-conditionalselectmenu": "^4.0",
"terminal42/contao-password-validation": "^1.1"
},
"extra": {
"public-dir": "web",
"contao-component-dir": "assets"
},
"scripts": {
"post-install-cmd": [
"@php vendor/bin/contao-setup"
],
"post-update-cmd": [
"@php vendor/bin/contao-setup"
]
}
}

[Spooky]

Version 4.13.41 wurde noch nicht veröffentlicht.

[Misios]

Gibt es irgendeinen Work-Around, außer die Token-Abfrage zu deaktivieren? Da es mit dem nächsten Contao-Update vllt gefixt ist scheint es ja ein Bug zu sein ... richtig?

[Misios]

ich hab jetzt für meinen speziellen Fall einen Workaround "entwickelt":

1) Die ursprüngliche Seite "Password anlegen" wird "geschützt" durch eine Mitgliedergruppe ohne Mitglieder :-) Dadurch landet JEDER auf der vorhandenen Login-Seite für den internen Bereich, weil er/sie sich für den internen Bereich anmelden soll.

2) Durch den erzwungenen Weg über die Login-Seite wird offensichtlich ein Request Token generiert.

3) Auf der Login-Seite habe ich das Login-Modul angepasst. Sobald die Login-Seite mit einem redirect-Verweis aufgerufen wird und dieser redirect von der ursprünglichen "Password anfordern"-Seite kommt wird über eine JS-Script-Ausgabe sofort weiter geleitet zu einer zweiten (neuen) und frei zugänglichen Seite "Passwort anlegen".

4) Durch diesen Umweg mit der doppelten Weiterleitung über die Login-Seite landet man dann inkl. Request Token auf der Seite mit der Möglichkeit ein Passwort anzulegen.

Bei mir funktioniert das so.
Vllt hilft es noch sonst jemandem.

Hier noch der Code oben im angepassten mod_login. Die jeweilgen redirect und href müssen dann natürlich auf die eigenen URLs angepasst werden.

<?php
    if (str_contains($_GET['redirect'], 'passwort-anlegen')) {
        echo "<script>location.href='passwort-anlegen-fuer-den-mitgliederbereich-cw.html';</script>";
    }
?>

[Spooky]

Gibt es irgendeinen Work-Around, außer die Token-Abfrage zu deaktivieren? Da es mit dem nächsten Contao-Update vllt gefixt ist scheint es ja ein Bug zu sein ... richtig?

Wenn es sich um das Problem handelt, welches in der nächsten Contao Version behoben wäre, dann liegt die Ursache ursprünglich woanders. Es könnte zB. sein dass eine Extension oder Applikationsanpassung eine Session startet, ohne Daten in die Session zu schreiben.

[Misios]

Da ja mein Workaround oben funktioniert und mit diesem Umweg ein Request Token geliefert wird: Spricht das generell dann eher für einen Contao-Bug oder für ein Problem einer Erweiterung? Oder kann man keine Rückschlüsse daraus ziehen?

[Spooky]

Dass kein Request Token ausgeliefert wird ist nicht das Problem. Das Problem ist, dass bspw. intern irgendwo eine Session gestartet wird, aber diese dann leer ist. Das kann nur von einer Applikationsanpassung oder Extension kommen.

[Misios]

Den Zusammenhang verstehe ich nicht wirklich. Ich kann nur sagen, dass es funktioniert, sobald ein Request Token vorhanden ist.

ich hatte auch versucht mit Modul abzufangen, ob ein Request Token vorhanden ist ... über {{request_token}} und $this->request_token. Beides funktioniert nur dann, wenn tatsächlich ein token vorhanden war. Wenn kein Token vorhanden war, dann wurde der komplette PHP-Code einfach NICHT angeführt.

Also z.b.

<?php 
     echo "TEST RT";
     echo $this->replaceInsertTags('{{request_token}}'); 
 ?>

Hier wurde nur bei vorhandenem Token etwas ausgegeben. Wenn kein Token vorhanden war, dann wurde der komplette PHP-Code einfach ignoriert inkl. sämtlicher sonstiger Anweisungen. Also auch die erste Zeile mit "TEST RT", die ja eigentlich doch erscheinen müsste wurde nicht ausgegeben.

[Misios]

Mit Contao 4.13.41 hat sich das Problem erledigt.

Auch der PHP-Code wie im Beispiel oben wird jetzt ausgeführt, wenn kein Request Token vorhanden ist.

Vielen Dank.

[Spooky]

Den Zusammenhang verstehe ich nicht wirklich. Ich kann nur sagen, dass es funktioniert, sobald ein Request Token vorhanden ist.

ich hatte auch versucht mit Modul abzufangen, ob ein Request Token vorhanden ist ... über {{request_token}} und $this->request_token. Beides funktioniert nur dann, wenn tatsächlich ein token vorhanden war. Wenn kein Token vorhanden war, dann wurde der komplette PHP-Code einfach NICHT angeführt.

Also z.b.

<?php 
     echo "TEST RT";
     echo $this->replaceInsertTags('{{request_token}}'); 
 ?>

Hier wurde nur bei vorhandenem Token etwas ausgegeben. Wenn kein Token vorhanden war, dann wurde der komplette PHP-Code einfach ignoriert inkl. sämtlicher sonstiger Anweisungen. Also auch die erste Zeile mit "TEST RT", die ja eigentlich doch erscheinen müsste wurde nicht ausgegeben.

Wie gesagt liegt die Ursache woanders - eben dass ein Teil deines Codes irgendwo eine Session startet ohne Daten in die Session zu schreiben.

[Misios]

Wie gesagt liegt die Ursache woanders - eben dass ein Teil deines Codes irgendwo eine Session startet ohne Daten in die Session zu schreiben.

Das glaub ich dir ja. ich kenn mich da eh nicht näher aus bzgl. Sessions etc.

Aber so rein interessehalber:
Wenn Contao beim Abfrageversuch eines nicht vorhandenen Request Tokens über $this->requestToken den kompletten PHP-Code ignoriert, dann stimmt doch was am Core nicht würde ich denken. Beim Abfrageversuch von anderen nicht vorhandenen Variablen wird der PHP-Code ja auch entweder weiter ausgeführt oder es gibt eine Fehlermeldung. Ist aber auch letztendlich wurscht. Funktioniert jetzt ja (wieder).

[Spooky]

Das glaub ich dir ja. ich kenn mich da eh nicht näher aus bzgl. Sessions etc.

Ja, das müsste man halt debuggen. Mit dem fix in der 41 ist das zwar erledigt - aber es sollte dennoch an der Quelle behoben werden.

Wenn Contao beim Abfrageversuch eines nicht vorhandenen Request Tokens über $this->requestToken den kompletten PHP-Code ignoriert, dann stimmt doch was am Core nicht würde ich denken. Beim Abfrageversuch von anderen nicht vorhandenen Variablen wird der PHP-Code ja auch entweder weiter ausgeführt oder es gibt eine Fehlermeldung. Ist aber auch letztendlich wurscht. Funktioniert jetzt ja (wieder).

Contao ignoriert hier nichts. Contao hat den Request Token aus der Response absichtlich entfernt.

[Misios]

Contao ignoriert hier nichts. Contao hat den Request Token aus der Response absichtlich entfernt.

Hm. Und das ist korrekt und gewollt, dass dann jeglicher PHP-Code im Modul nicht mehr ausgeführt wird? Es gab ja nicht nur die Abfrage/Ausgabe des Request Token, sondern auch davor und danach noch Code-Zeilen ohne Request Token. Es wurde immer nur alles an PHP ausgeführt, wenn ein RT vorhanden war. Ansonsten wurde tatsächlich gar nichts angeführt an PHP. Und das alles ohne Fehlermeldung oder Log-Eintrag. Fand ich seltsam.

[Coda]

Mit Contao 4.13.41 hat sich das Problem erledigt.

Ein ergänzender Hinweis für diejenigen, bei denen noch immer die Request Token Meldung erscheint:
Das Template form_captcha.html5 für die Sicherheitsfrage (contao/core-bundle/src/Resources/contao/templates/forms/form_captcha.html5) wurde ebenfalls angepasst. Wer also ein eigenes/modifiziertes Template für die Sicherheitsfrage verwendet, sollte die Änderungen übertragen.