Formulare: Fehlermeldung bei deaktivierten Cookies ausgeben

[contaotester]

Ausgangssituation:

• Im Backend ist ein einfaches Formular angelegt, mit einem Radio-Button-Menü und Senden-Button
• Übertragungsmethode ist POST und es gibt keine Weiterleitungsseite (die Seite wird nach dem Senden einfach neu geladen)
• Das Formular ist als Modul ins Seitenlayout eingebunden
• Wenn das Formular gesendet wird, wird der Wert des Radio-Feldes in einem Cookie gespeichert
• Das Cookie-Handling an sich (Cookie erstellen, aktualisieren, löschen) erfolgt in einem KernelResponseSubscriber (implements EventSubscriberInterface) und funktioniert bereits
• Beim Aufruf der Seite mit dem Formular wird im LoadFormFieldListerner geprüft, ob das Cookie bereits im requestStack vorhanden ist. Falls ja wird der im Cookie gespeicherte Wert genutzt, um das entsprechende Radio-Auswahlfeld als 'checked' zu markieren (funktioniert ebenfalls)

Problem:

Ich finde allerdings gerade keinen Lösungsansatz, wie nach dem Senden des Formulars ohne Javascript eine Fehlermeldung ausgeben werden kann, wenn Cookies im Browser deaktiviert sind oder von einer Erweiterung blockiert werden.

Ich vermute, die CSRF-Sicherheitsprüfung mit dem versteckten Formularfeld 'REQUEST_TOKEN' und dem 'csrf_contao_csrf_token'-Cookie von Contao verhindern, dass das Formular verarbeitet wird, wenn Cookies deaktiviert sind, ist das korrekt?

Wie kann man denn eine Fehlermeldung ausgeben, wenn diese Sicherheitsprüfung gescheitert ist?


Was passiert momentan?

Wenn Cookies im Browser komplett deaktiviert sind und man das Formular sendet, wird die Seite einfach nochmal mit dem (unveränderten/ursprünglichen) Formular angezeigt, ohne irgendeine Fehlermeldung.


Was ich bereits probiert habe:

In dem KernelResponseSubscriber wird vor den Cookie-Funktionen geprüft, ob es sich um einen POST-Request handelt (und falls nicht, werden die Cookie-Funktionen gar nicht erst ausgeführt):

// Only continue in the script when a form was send
if ( !$request->isMethod('POST') ) {
  return;
} 

Mein Lösungsansatz wäre nun gewesen, im LoadFormFieldListerner ähnlich vorzugehen und dort zu prüfen, ob der Request ein POST war (das Formular also gesendet wurde). Falls ja könnte man den Wert eines versteckten Feldes 'formular-wurde-gesendet' von '0' auf '1' ändern und über Umwege im Template eine Warnung/Fehlermeldung ausgeben, wenn sich der Radio-Wert nicht vom Standardwert unterscheidet. Das klappt aber leider nicht, weil:

Wenn Cookies im Browser deaktiviert sind, ist die [#method] im requestStack seltsamerweise immer GET anstelle POST?
(also wenn ich im KernelResponseSubscriber ODER im LoadFormFieldListerner dump($request); mache)

Hat jemand eine Tipp oder eine Idee, wie man eine Fehlermeldung nach dem Senden ausgeben kann, wenn das Formular von Contao gar nicht verarbeitet wurde?

Und unabhängig von meiner Baustelle, aber ist mir in dem Zusammenhang aufgefallen: Warum kann man auf der Contao-News-Demoseite (Link) einen Kommentar absenden, wenn Cookies und Javascript im Browser deaktiviert sind, obwohl dort ein (leeres!?) verstecktes Formularfeld 'REQUEST_TOKEN' sowie zusätzlich das Feld Sicherheitsabfrage eingebunden sind? Das dürfte ohne Cookies doch eigentlich auch nicht funktionieren, oder verstehe ich das falsch mit den CSRF-Cookies?

[zoglo]

Warum nicht das Sessionbag nutzen, machen die Filter auch, dann bist du auch von Cookies befreit.

Ansonsten via PHP ein Cookie setzen und schauen ob es gesetzt ist, falls nicht, dann sind Cookies deaktiviert.

[Spooky]

• Das Cookie-Handling an sich (Cookie erstellen, aktualisieren, löschen) erfolgt in einem KernelResponseSubscriber (implements EventSubscriberInterface) und funktioniert bereits

Mit welcher Priority?

[contaotester]

Warum nicht das Sessionbag nutzen, machen die Filter auch, dann bist du auch von Cookies befreit.

Cookies können länger als die Session erhalten bleiben und der Besucher (kein angemeldetes/registriertes Mitglied) muss die Auswahl beim nächsten Besuch nicht erneut treffen (sofert die Cookies nicht vom Browser oder einer Erweiterung gelöscht werden). Der Besucher kann in meinem Fall selbst entscheiden, ob er den Formularwert in einem Cookie speichern möchte und falls ja, für wie lange das Cookie gespeichert werden sollen (1 Tag, 1 Woche, 1 Monat...).

localstorage hatte ich auch in Betracht gezogen, wird im Gegensatz zu Cookies aber nicht mit dem Request geschickt, kann daher nicht im LoadFormFieldListener ausgelesen werden und das nachträgliche Anpassen der Radio-Auswahl an den im localstorage gespeicherten Wert funktioniert nur, wenn Javascript aktiviert ist. Für manche Zwecke haben Cookies weiterhin eine Daseinsberechtigung...

Allerdings sollte eben auch der Fall abgedeckt sein, dass Cookies nicht gespeichert werden konnten und dann sollte der Benutzer eine Fehlermeldung oder zumindest einen Hinweis erhalten, dass es nicht geklappt hat.

Ansonsten via PHP ein Cookie setzen und schauen ob es gesetzt ist, falls nicht, dann sind Cookies deaktiviert.

Genau das war ja meine Überlegung. Wenn das Formular gesendet wurde, wird im LoadFormFieldListener geprüft, ob die neuen Cookies im Request vorhanden sind. Sind sie aber nicht, wenn Cookies deaktiviert sind. Jetzt müsste man nur unterscheiden können, ob die fehlenden Cookies daran liegen, dass sie nicht gespeichert werden konnten, ob weil das Formular noch gar nicht abgesendet wurde. Aber wie schon geschrieben ist die Request-Methode bei deaktivierten Cookies seltsamerweise immer GET anstelle POST, daher weiß ich nicht, wie man das unterscheiden kann, um ggf. eine Fehlermeldung anzuzeigen.

Mit welcher Priority?

 public static function getSubscribedEvents(): array
  {
    return [
      KernelEvents::RESPONSE => [
        ['onKernelResponse', -128],
      ],
    ];
  } 

Ich weiß offen gestanden nicht, welche Priorität dieser Listener bzw. Subscriber haben sollte.

Es werden hier nur die Cookies gesetzt, aktualisiert oder gelöscht, sonst macht der nichts "Wichtiges". Daher vermute ich, er hat eine geringe Priorität?

[Spooky]

Ich weiß offen gestanden nicht, welche Priorität dieser Listener bzw. Subscriber haben sollte.

Es werden hier nur die Cookies gesetzt, aktualisiert oder gelöscht, sonst macht der nichts "Wichtiges". Daher vermute ich, er hat eine geringe Priorität?

Du musst die Priorität höher setzen als der Response Listener, der das CSRF Cookie setzt. Der CsrfTokenCookieSubscriber von Contao hat eine Priorität von -1006, insofern sollte es bei dir also funktionieren.

Aber ich stimme @zoglo zu, dass du das einfach die Session schreiben könntest, anstatt in ein eigenes Cookie. Warum setzt du es überhaupt als kernel.response Listener um?

[contaotester]

Warum setzt du es überhaupt als kernel.response Listener um?

Weil das in der Contao-Hilfe steht

https://docs.contao.org/dev/reference/hooks/setCookie/

Using the setCookie hook has been deprecated and will no longer work in Contao 6.0. Implement a kernel.response listener instead.

[Spooky]

Das hat ja nichts mit deiner Anforderung zu tun. Der setCookie Hook ist deprecated - aber du wolltest diesen Hook ja nicht benutzen.

Nutze wie gesagt einfach die Session - und den Wert setzt du ganz normal in einem processFormData Hook.

[contaotester]

Nutze wie gesagt einfach die Session

Darf ich fragen, warum du in dieser Erweiterung ein Cookie und nicht die Session nutzt?

https://github.com/inspiredminds/con...ember-language

und den Wert setzt du ganz normal in einem processFormData Hook.

Da hatte ich die Cookie-Logik sogar zuvor schon mal drin... werde meine Lösung nochmal überarbeiten.

Danke euch für die schnellen Antworten!

[Spooky]

Darf ich fragen, warum du in dieser Erweiterung ein Cookie und nicht die Session nutzt?

https://github.com/inspiredminds/con...ember-language

Die Session ist begrenzt, das Cookie nicht.

Soweit ich deine Anforderung verstehe musst du den Wert aber nicht unendlich lang speichern lassen können?