• Vorträge

    Viele Vorträge, die auf Konferenzen gehalten werden, landen irgendwo im Internet. Wir haben sie für euch zusammengesucht.

    • Post/Redirect/Get Pattern

    von am 5. März 2010
    Dieser Artikel wurde auf Wunsch der phphatesme Leser verfasst und wurde über die Ideenschmiede eingereicht. Falls du auch eine Idee für einen Artikel hast, dann füge sie doch einfach hinzu.

    Was jetzt wohl kommt? Ein neuer Artikel natürlich. Aber erst mal muss ich mich entschuldigen, dass die Gewinnspielpreise erst in einer Woche raus gehen werden, da ich ab morgen für eine Woche beim Snowboarden bin. Ich hoffe ihr seid ein wenig neidisch. Ich wäre es. Falls ihr jetzt Angst habt, dass ihr sieben Tage nichts über PHP erfahren könnt, dann kann ich euch beruhigen. Es gibt eine Handvoll Co-Autoren, die euch durch die Woche bringen werden.

    Soviel erstmal zum Organisatorischen. Jetzt zum Artikel, den ihr bestimmt schon sehnsüchtig erwartet. Es geht um das Post/Redirect/Get Pattern, das einem hilft, mit Post-Methoden umzugehen. Im Speziellen geht es eigentlich darum dass man nicht aus Versehen zwei Mal ein Formular abschickt, wenn man das gar nicht wollte. F5 und die Zurück-Taste im Browser sind da wohl die prominentesten Vertreter für. Ich gehe mal davon aus, dass euch das auch schon öfters passiert ist.

    Die Lösung ist eigentlich schon im Namen des Musters beschrieben. Post -> Redirect -> Get. Also der erste Schritt ist ganz normal das Formular per Post abzusenden. Dann verarbeitet ihr in eurer Applikation die Anfrage genau so, wie ihr es immer macht. Bis jetzt sollte euch das Verhalten bekannt vorkommen, denn so werdet ihr eh schon arbeiten. Was man jetzt im “Normalfall” machen würde ich nach der Verarbeitung die Seite anzuzeigen auf der die Änderungen angezeigt werden.

    PostRedirectGet_DoubleSubmitSolution

    Das machen wir jetzt aber nicht. Statt die Seite anzuzeigen leiten wir per 301 (permanently moved) weiter auf die Seite. Wir erinnern uns ans Redirect im Namen. Schon haben wir unsere Post-Anfrage in ein einfaches Get umgewandelt. Das tolle daran ist, das der Browser die alte Seite komplett vergessen hat, denn durch den 301 sollte er das auch.

    Wenn ich jetzt ein F5 drücke oder im Browser zurückgehe, sollte nicht mehr abgesendet werden. Die Weiterleitung könnt ihr übrigens über die HTTP Header:

    <?php
  header("HTTP/1.1 301 Moved Permanently");
  header("Location: http://www.neue-domain.de/bla.html");
  header("Connection: close");
?>

    Ich werde das die nächsten Tage für die Ideenschmiede umbauen, denn da kann man nämlich durch F5 ganz einfach bescheißen und das wollen wir ja nicht.

    Nils Langner

    Auch wenn Ihr es mir nicht glauben werdet, aber ich habe nichts gegen PHP. Ich rege mich einfach nur gerne auf. Ok so schlimm ist es auch nicht. Eigentlich wollte ich schon immer einen Blog haben und da ...

    Zum Profil von Nils Langner

    36 Kommentare »


    • Arvid Bergelmir
      am 5. März 2010 um 08:36 Uhr

      Was viele sicherlich von diesem Verfahren abhält ist, dass sie das Problem mit den Erfolgs- bzw. Fehlermeldungen haben, denn ein einfaches Ausgeben der Meldungen geht ja, durch den Redirect, nicht mehr. Den Status über einen GET-Parameter weiterzugeben ist auch keine sehr elegante Lösung für dieses Problem.


    • Sven
      am 5. März 2010 um 08:37 Uhr

      Als erstes würde ich einfach mal die etwas ketzerische Frage in den Raum werfen: Handelt es sich dabei wirklich um ein Pattern? Gibt es noch andere Problemfelder, wo man das Post/Redirect/Get Pattern einsetzen kann? Oder kann man damit wirklich nur das doppelte absenden von Formulardaten verhindern? Weil in diesem Fall ist es eine Problemlösung, aber noch kein Pattern, weil dafür müsste es auch auf andere Problemfelder anwendbar sein.

      So nun aber zum Beitrag an sich. Wir haben dieses Problem auch gehabt und auch diese Lösung eingesetzt. Was man dabei jedoch beachten muss, ist, dass man manchmal auch Aktionen über GET anstößt. Dann müssen vor dem Redirect nämlich die relevanten GET Parameter aus der URL entfernt werden, befor der Redirekt angestossen wird. Mit einem explode(‘&’, …), dem auswerten und einem späteren implode(‘&’, …) geht das auch recht fix.

      Eine andere Lösung, welche denkbar ist wäre dem Formular einen Hash zu geben und wenn das Formular verarbeitet wurde diesen Hash zu invalidieren. Der zweite identische Request wird dann einfach gar nicht verarbeitet. Dies könnte man umsetzen, indem man einen Pool anlegt indem man einen gültigen Hash einfügt und diesen bei Benutzung entfernt. Dabei muss dieser Pool aber je Nutzer angelegt werden, sonst könnte ein Nutzer einen Hash eines anderen Nutzers benutzen.


    • Markus
      am 5. März 2010 um 08:43 Uhr

      Ich habe es bisher immer folgendermaßen gehandhabt:

      1. POST verarbeiten
      2. unset($_POST);
      3. Redirect auf Erfolgsseite via header(‘Location …’);

      Hat auch soweit ganz gut funktioniert. Muss aber gestehen, die hier beschriebene Möglichkeit klingt besser. Das werde ich bei Gelegenheit auf jeden Fall mal ausprobieren.


    • Arvid Bergelmir
      am 5. März 2010 um 08:54 Uhr

      @Sven: Ich hoffe ihr stoßt keine Manipulationsanfragen über GET an, denn dafür ist GET nicht gedacht. Dass man aber zwischendurch, je nach Anwendungsfall, Daten bei einem Redirect über GET weitergeben muss, ist ansich nichts ungewöhnliches. Jeder, der darauf reinfällt, dass die Daten nicht beim Redirect mit übergeben werden, wird das schnell merken und die Parameter beim GET mit übergeben.


    • Arvid Bergelmir
      am 5. März 2010 um 09:01 Uhr

      @Markus: Bringt unset($_POST) wirklich etwas? Das $_POST wird ja ansich nur in deiner Anwendung verwendet. Was der Browser macht, ist ansich was ganz anderes, daher sollte den das unsetten von $_POST völlig kalt lassen.


    • Jan
      am 5. März 2010 um 09:06 Uhr

      Der korrekte HTTP Status Code ist übrigens 303 (See Other).


    • Jens Prangenberg
      am 5. März 2010 um 09:06 Uhr

      Nicht schlecht. Das Problem mit dem drücken der “F5″ Taste habe ich bisher auch öfters gehabt.

      Die Idee ist super, weiß jedoch noch nicht wie ich es umsetzen soll, da man nach meines Wissens vor dem Header keine Ausgabe haben darf. Sehe ich das richtig?


    • Marc Binder
      am 5. März 2010 um 09:09 Uhr

      Zitat:
      ——————————————
      Was viele sicherlich von diesem Verfahren abhält ist, dass sie das Problem mit den Erfolgs- bzw. Fehlermeldungen haben, denn ein einfaches Ausgeben der Meldungen geht ja, durch den Redirect, nicht mehr. Den Status über einen GET-Parameter weiterzugeben ist auch keine sehr elegante Lösung für dieses Problem.
      ——————————————

      Das sehe ich jetzt ein wenig anders. Es gibt nun einmal derzeit nur diese Methode um ein Formular nicht dopelt abzusenden. Daher muss man darauf zugreifen.


    • Marc Binder
      am 5. März 2010 um 09:10 Uhr

      Zitat:
      ——————————————
      Die Idee ist super, weiß jedoch noch nicht wie ich es umsetzen soll, da man nach meines Wissens vor dem Header keine Ausgabe haben darf. Sehe ich das richtig?
      ——————————————

      Jop, das ist richtig.


    • kb
      am 5. März 2010 um 09:20 Uhr

      Mit was ist dieses Diagramm gemacht? :)


    • Christian
      am 5. März 2010 um 09:20 Uhr

      Netter Ansatz. Eine andere Möglichkeit ist die Invalidierung durch das Setzen eines Session-Parameters.

      @Jens: Eine Ausgabe sollte eigentlich immer erst erfolgen, wenn der Feature-Layer mit seiner Arbeit durch ist.
      Leider greift in vielen Applikationen, schätzungsweise auch bei dir, schlussfolgernd aus dem Kommentar, das EVA-Prinzip nicht vollständig.

      Die Ausgabe ist die letzte Aktion und sollte sich auf den Datenstrom berufen, der durch Eingabe (natürlich gefiltert) und Feature-Layer erzeugt wird.


    • Sven
      am 5. März 2010 um 09:23 Uhr

      Zitat:
      ——————————————
      Die Idee ist super, weiß jedoch noch nicht wie ich es umsetzen soll, da man nach meines Wissens vor dem Header keine Ausgabe haben darf. Sehe ich das richtig?
      ——————————————

      Naja entweder man hat schon eine entsprechende Architektur gebaut, dass Actions vor dem Layout etc verarbeitet werden oder man verwendet ob_start(). Dann kann man ganz normal arbeiten und trotzdem jederzeit einen header() abfeuern. Weil der wird nämlich trotzdem rausgeschickt, auch wenn der Output gepuffert wird.


    • Jens Prangenberg
      am 5. März 2010 um 09:25 Uhr

      Zitat:
      ————————–
      Naja entweder man hat schon eine entsprechende Architektur gebaut, dass Actions vor dem Layout etc verarbeitet werden oder man verwendet ob_start(). Dann kann man ganz normal arbeiten und trotzdem jederzeit einen header() abfeuern. Weil der wird nämlich trotzdem rausgeschickt, auch wenn der Output gepuffert wird.
      ————————–

      Dankesehr! Das hilft mir weiter!


    • Kore
      am 5. März 2010 um 09:29 Uhr

      Die sinnvollere Methode Form-resubmits zu verhindern sind einfach One-Time-Tokens, die man im Formular einbindet (und in der Session zur Validierung vorhaelt). Das erschwert zusaetzlich noch CSRF, und sollte daher eh jeder machen. Danach muss man keinen HTTP-Header mehr schicken, kann das durch einen Applikations-internen Redirect loesen, und das funktioniert auch fuer Interaktion ueber andere Protokolle als HTTP.


    • Jens Prangenberg
      am 5. März 2010 um 09:44 Uhr

      Sorry das ich hier ein Doppelpost mache.

      Hat jeder sich schonmal eine gute Architektur gebaut, die mir jemand zur Verfügung stellen könnte. Bin ja noch am lernen :-(

      Zitat von php.net
      ————————-
      Während die Ausgabepufferung aktiv ist werden Scriptausgaben (mit Ausnahme von Headerinformationen)…

      Mit Ausnahme von Headerinformationen?!
      ————————-


    • Axel
      am 5. März 2010 um 09:45 Uhr

      Ich muss mich Sven anschließen, ich wusste gar nicht das das ein Pattern ist. Je öfters ich PhpHatesMe lese desto mehr Patterns benutze ich, cool oder ?

      Wie Sven schon geschrieben hat, bevorzuge ich folgende Lösung.

      1. Get Request auf Formular –> Magic Token wird auf Serverseite generiert und ins Formular geschrieben.

      2. Post Request auf Formular –> Prüfe Magic Token ( wurde von benutzer erzeugt und ist noch gültig )

      Beim verarbeiten des Formulares kann ich nun den doppelten Post verhindern. Ganz konrekt verhindere ich das mehrfache versenden von SMS ^^ Also ein sinnvoller Einsatz.

      fertig :D


    • Julian
      am 5. März 2010 um 09:48 Uhr

      Meiner Meinung nach keine akzeptable Lösung. Beispielsweise möchte ich das User-Verhalten auf meiner Seite analysieren und erzwinge durch diese Methode einen neuen “Aufruf”. Das bedeutet, dass ich das in meiner Analyse beachten (filtern) muss. Wieso also nicht von vornherein bei den Formularen diesen Fall beachten? Ich prüfe einfach mit entsprechenden Zeit- und Request-Werten. Gleiche Werte dürfen die POST-Werte nur nach einem bestimmten abgelaufenen Zeitfenster tragen, ebenso könnte ich verlangen aktuelle Zeitstempel über ein Hidden-Feld zu übertragen. Dieses lässt ja erkennen, dass ein Refresh getätigt wurde, denn der Wert ist beim Refresh der selbe geblieben (Request wird nochmals gesendet). Ein neuer / veränderter Request dagegen kann ja erwünscht sein. Es gibt noch zahlreiche andere Möglichkeiten, Weiterleitungen finde ich in dem Zusammenhang nicht passend und viel zu umständlich gelöst.

      Grüße


    • Arvid Bergelmir
      am 5. März 2010 um 10:03 Uhr

      @Julian: hört sich angreifbar an.


    • Marc Binder
      am 5. März 2010 um 10:15 Uhr

      Mich würde auch interessieren mit welchem Tool du das Diagram gemacht hast.


    • Balu
      am 5. März 2010 um 10:48 Uhr

      @Arvid Bergelmir: Speichere die Nachrichten für die Folgeseite einfach in der Session. Dann kann Dein Script problemlos darauf zugreifen und der Status muss nicht mit im GET übertragen werden.

      Ich überlege gerade, ob man den Redirect auch im Fehlerfall machen sollte. Eigentlich stört dann ein reload nicht, es würde nur denselben Fehler generieren…


    • Gabriel
      am 5. März 2010 um 11:09 Uhr

      @Balu: Guter Punkt. So mache ich es auch meistens: Wenn die Formularverarbeitung erfolgreich war, dann Aktion auslösen und Redirect. War sie erfolglos, kann ich mir das Speichern der Validierungsfehler in der Session sparen, indem ich keinen Redirect mache.


    • Arvid Bergelmir
      am 5. März 2010 um 11:18 Uhr

      Ich mache es so, dass ich die Daten validiere, die Aktionen ausführe und bei Erfolg per Redirect auf die nächste Seite weiterleite. Erfolgsmeldungen werden vorrübergehend bis zum Abruf in der Session zwischengespeichert. Wurde die Meldung angezeigt, verschwindet die Meldung aus der Session. Im Fehlerfall wird nicht weitergeleitet, sondern intern wieder auf die Herkunftsseite umgeroutet, damit diese wieder angezeigt werden kann. Die Fehlermeldungen werden nicht in der Session zwischengespeichert, da auch kein Redirect stattfindet. Der Benutzer befindet sich also noch auf einer POST-Seite. Bei Druck auf F5 wird der Benutzer also abgefragt, ob er die Daten nochmals senden möchte.


    • Andre Moelle
      am 5. März 2010 um 11:38 Uhr

      Mir gefällt die Lösung sehr gut, da sie der Semantik der HTTP-Verben sehr entgegenkommt: POST zum Hinzufügen und GET zum Abfragen von Daten.


    • Nils Langner
      am 5. März 2010 um 12:44 Uhr

      Da ist man mal ‘nen Vormittag im Meetingmarathon und schon muss man 23 Kommentare lesen … sehr coole Sache! Der Ausdruck Design Pattern also Entwurfsmuster habe ich aus der Wikipedia entnommen (http://en.wikipedia.org/wiki/Post/Redirect/Get) wo übrigens auch die Grafik her ist. Ob der Ausdruck nun komplett richtig verwendet wurde will ich hier gar nicht entscheiden.

      Die Token-Geschichte finde ich auch sehr sympatisch, dann aber in Kombination mit der Redirect-Variante, denn so Kombiniere ich Sicherheit und Bequemlichkeit und ich denke mehr kann man kaum erreichen.

      Falls ich nämlich nur das Token verwende, wird mich der Browser immer noch fragen, ob er die Daten erneut senden soll und das nervt mich an manchen Tagen schon ein wenig.


    • Arvid Bergelmir
      am 5. März 2010 um 13:32 Uhr

      Achja, Tokens verwende ich natürlich auch :-) Habe einen Token-Stack von 10 Tokens pro Benutzer. So kann der Benutzer auch in unterschiedlichen Tabs arbeiten ohne, dass gleich der Token für ein Formular abläuft.


    • Paloran
      am 5. März 2010 um 20:27 Uhr

      Hi,
      um das mit dem Header in den Griff zu bekommen, könnte man eine Klasse erstellen welche die ganz Ausgabe abwickelt. Diese könnte z.B. HttpResponse heißen. Die Klasse speichert dann alles in einer Eigenschaft, und sendet erst am Ende des Skripts (evtl. im Destruktor…) das Dokument an den Browser.

      Ansonsten ich vielleicht noch hinzufügen, dass man den Besucher darauf hinweisen sollte, dass er das Formular nur einmal abschicken muss/darf.

      Liebe Grüße Paloran und einen schönen Urlaub (und ob ich neidisch bin…)

      P.s. wenn man nur abends Blogs liest, sind da immer schon unzählige Kommentare…


    • Nils Langner
      am 5. März 2010 um 20:51 Uhr

      Wisst ihr was doof ist? In meinem Urlaub wird der 4000 Kommentar geschrieben und ich bin nicht hier um mitzufeiern.


    • Paloran
      am 5. März 2010 um 20:53 Uhr

      woran sehen wir, welcher der 4000. ist?


    • Nils Langner
      am 5. März 2010 um 21:06 Uhr

      Ganz einfach unter Projekt (http://www.phphatesme.com/das-projekt/) im Menü. Sind nur noch 13, aber ich glaube das schaffen wir heute Abend nicht mehr :) Zumindest nicht ohne zu “bescheißen”.


    • kb
      am 6. März 2010 um 15:35 Uhr

      Und mit welchem Tool wurde das Diagramm jetzt gemacht?? :(


    • maz
      am 6. März 2010 um 20:03 Uhr

      Hallo,
      hat das Schließen der Verbindung mit header(“Connection: close”); einen Sinn? Gerade wenn man dem Browser mitteilt, dass er sich nach einem POST per GET an eine andere URL wenden soll, wäre es doch geschickter, dass der Browser die TCP Verbindung offen hält?


    • Linkhub – Woche 09-2010 « pehbehbeh
      am 7. März 2010 um 17:48 Uhr

      [...] Formulardaten richtig verarbeiten: Post/Redirect/Get Pattern [...]


    • Timo Reitz
      am 8. März 2010 um 08:52 Uhr

      Ist das nicht ein Spezialfall des Command-Query-Separation-Prinzips? Das gilt zwar eigentlich für Methoden, lässt sich aber leicht verallgemeinern.


    • Dennis Becker
      am 8. März 2010 um 11:32 Uhr

      Ich mache es prinzipiell so wie Arvid, dass ich bei einem Fehlerfall auf dem Formular bleibe und im Erfolgsfall einen Redirect durchführe. Wer das Zend Framework verwendet kann zum Beispiel den Flash Messenger verwenden, so hat man ein Systemweites “Meldesystem” – oder hat man hat seine eigene Implementierung, die ein paar mehr Fälle abdecken kann ;)


    • Karsten
      am 18. März 2010 um 15:36 Uhr

      @kb, @mark binder:
      Das Diagramm liegt auf http://en.wikipedia.org/wiki/File:PostRedirectGet_DoubleSubmitProblem.png und wurde der Quellenangabe nach mit PowerPoint erstellt. Die Icons sehen sehr nach dem Crystal SVG Package aus.


    • Paloran
      am 16. April 2010 um 21:52 Uhr

      Kann es sein dass man in der Ideenschmiede immer noch mehrmals dasselbe hintereinander wählen kann; oder funktioniert dieses Pattern nicht?

    RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

    Hinterlasse einen Kommentar

    Werbung
    PHP Magazin
    Ausgabe 02/2010

    Dieses Mal mit Artikeln zu den Themen OpenSocial und Apache Shindig, Graphentheorie, Smarty3

    t3n
    Ausgabe 19

    Social Media (R)evolution. Weitere Themen sind noSQL, Crowdsourcing ...

    PHP Journal
    Ausgabe 2/2010

    PHP & Windows optimal nutzen, die besten PHP-CMS im Überblick, Google-API mit Zend Framework nutzen.

    Wir wurden schon öfters gefragt, ob man uns nicht irgendwie unterstützen kann. Die Antwort war immer einfach: Klar! Am einfachsten ist es eure nächsten Einkäufe bei Amazon über unsere Link abzuwickeln. Damit würdet ihr uns schon sehr helfen. Über Co-Autoren freuen wir uns aber noch mehr.