PHP POST-Daten doppelt senden

[Yuuri]

Dann mal ganz dreist gefragt: Wer rendert denn den "Submit"-Button? Das Bestätigen des Warenkorbs muss doch durch eine User-Interaktion erfolgen, oder? Dieser Button liegt doch innerhalb des (PHP?) Codes des Shops, oder? Diesen Code kannst du manipulieren wie du lustig bist, oder?

Der Shop natürlich. Der Button ersetzt den normalen "zur Kasse"-Button oder wie er in den Shops heutzutage auch immer heißen mag. Beim Klick wird das SAP-Formular regulär an die entsprechende Rücksprungadresse geschickt.

Es geht mir um folgendes: Derselbe Knopf, der aktuell deine halbgare JS-Lösung beherbergt, kann doch von dir frei manipuliert werden, oder?

Ja genau.

Du kannst den Submit doch sicher problemlos dahin leiten, wo DU es für witzig erachtest und zurückgeben, was DIR richtig vor kommt.

Aber wie sage ich dem Browser dann (ohne 307 Header, ohne JS), dass er diesen Request, den er gerade an mein Script geschickt hat (damit ich die Auslösung der Bestellung mitbekomme), exakt genauso an eine andere URL absenden soll? Genau das ist die große Preisfrage.

 

[Daaron]

Also im Shop hast du ein <form action="SAP-Ziel"><input type="submit" value="klick mich!">? Dann ändere die Action auf "dein PHP cURL Script"... Das Formular, bzw. dessen POST-Request, enthält alle Informationen die du willst. Die Ziel-URL des SAP kennst du auch. Also lass das Script die Daten an die Ziel-URL schicken und vorher damit machen was du für richtig erachtest. Ich seh da kein Problem.

Deine große Preisfrage ist eigentlich ne ganz kleine: Analysier, was für Daten so ein üblicher POST ans SAP verschickt. Im schlimmsten Fall musst du hier Wireshark oder sowas einsetzen und den Netzwerktraffic ganz weit unten mitschneiden. Im günstigsten Fall hat der Browser Entwicklertools, in denen du es im Klartext lesen kannst.
Sobald du weißt, was (in etwa) geschickt wird, kann dein PHP-Script diese Daten auch problemlos in einen cURL-Request kapseln.

 

[Yuuri]

Also im Shop hast du ein <form action="SAP-Ziel"><input type="submit" value="klick mich!">?

<a onclick="$('#sapoci').submit();"><img src=".../button_sapocicheckout.gif"></a>

<form action="..." method="post" id="sapoci">
  <input type="hidden" name="..." value="...">
  <input type="hidden" name="..." value="...">
  <input type="hidden" name="..." value="...">
  ...
</form>

Stark verkürzt, aber ein stink normales Formular eben, das abgeschickt wird.

Dann ändere die Action auf "dein PHP cURL Script"... Das Formular, bzw. dessen POST-Request, enthält alle Informationen die du willst.

Und wie sag ich dem Browser dann, dass er die POST-Daten selbstständig an seine Rücksprungadresse schickt, mit anschließender Umleitung und was dahinter noch so kommt? Dass der Server den Request macht ist schön und gut, aber es bringt mir nichts, wenn der Server dann die Aufgabe des Clients "übernimmt" und im nicht zugänglichen SAP-System die Bestellung bestätigt. Der Client bleibt auf der Seite, sieht ne nette "Bestellung erfolgreich"-Meldung vom Shop und die Bestellung im SAP-System bleibt schwebend, wenn sie überhaupt registriert wird.

Das hatten wir vorhin doch schon, weshalb ich es nochmal erklärt habe.

Ein cURL-Request vom Server versucht den Request vom Client nachzuahmen und das wars. Hier wird immer wieder vergessen, dass der Client im Anschluss noch Sachen erledigen muss (die Bestellung konstrollieren, korrigieren, bestätigen, drucken usw.usf). Ich kann in einem cURL-Request keine Buttons klicken im fremden SAP-System!

Wenn der Browser/Mitarbeiter dagegen auf den Knopf drückt, das Script mir per Ajax-Request eine Kopie zukommen lässt und das selbe Formular dann an ans richtige Script schickt, plus der Client korrekt umgeleitet wird, kann der Mitarbeiter dann weiter seine Sachen erledigen, sodass die Bestellung auch ausgelöst wird, von seinem System aus. Ich kann mit einem cURL-Request keinen Request abschicken, indem steht, dass die Bestellung nun gedruckt und bestätigt wird. Schon gar nicht kann ich ihm sagen, dass die Bestellung als PDF gedruckt und (wahrscheinlich automatisiert) per Fax übermittelt wird.

Sobald du weißt, was (in etwa) geschickt wird, kann dein PHP-Script diese Daten auch problemlos in einen cURL-Request kapseln.

Ich weiß auch so, was dort verschickt wird. [1] Es bringt mir nur nichts, wenn der Client/Browser dann nicht zurück springt und dieser Mitarbeiter vor dem Client/Browser die Bestellung nicht abschließen kann, weil der Server versuchen will, die Rolle zu übernehmen.

[1] http://www.festo.com/wiki/de/Open_Catalog_Interface_(OCI)#Standard_R.C3.BCckgabeparameter

 

[Daaron]

Wenn es nur über den AJAX-Weg funktioniert, dann ist das halt ab jetzt so. Setze JavaScript als Systemvoraussetzung auf der Seite und fertig. Wer kein JS aktiv hat, kann z.B. den Submit-Knopf nicht sehen/betätigen. Problem gelöst.

KISS - Keep It Simple, Stupid

 

[gaunt]

OK, also. Ich wiederhol mal wie ichs verstanden hab:
1. Da ist ein XT mit einem Warenkorb der gefüllt wird.
2. Aber statt den internen Checkout zu nutzen drückt der User irgendwann "Will haben!".
3. Der Button befindet sich auf einer Seite mit einem Form mit Hidden fields.
4. Im action des Forms steht die SAP Adresse als ziel.
5. Vor dem Submit erfolgt ein AJAX Call auf eine weitere Adresse welche etwas, was auch immer, mit den Form Daten macht.
6. Der eigentliche Submit schießt den User auf das SAP System.
7. Der Shop ist außen vor und spielt keine Rolle mehr. Alles weitere erfolgt im SAP.

Und das ist eigentlich auch OK!

Jetzt versteh ich auch dein Problem. Natürlich könntest du als Submit Action eine eigene Seite angeben und hier das SAP an curlen. Aber danach gibts weitere Kommunikation zwischen dem User Browser und dem Web Frontend von SAP. Du müsstest also die gesamte Kommunikation nachbauen, was zwar ginge, aber zu aufwändig ist. Der Redirect geht auch nicht, weil dann die angehängten Daten futsch sind. Der Kunde käme also zwar beim SAP raus, hätte seine Bestllung aber vergessen.

Lange Rede kurzer Sinn, ohne die Grundsätzliche Architektur (welche mir reichlich seltsam vorkommt) zu ändern (was nicht möglich ist) ist und bleibt Ajax mit weitem Abstand die einfachste und sicherste Lösung.

Was du aber bedenken solltest: Lässt sich SAP durch ein simples Form Submit an triggern, dann kann jemand mit minimalem Aufwand (z.B. einfaches Selenium Script) dein SAP mit sinnlosen "Bestellungen" fluten. Selbst einfaches vor und zurück des Browsers kann da u.U. doch schon mehrfachbestellungen auslösen.

Ich würde vorerst bei der AJAX Variante bleiben, und mir mal in nem ruhigen Moment überlegen, ob man die Grundarchitektur nicht verbessern kann.

 

[Yuuri]

Wenn es nur über den AJAX-Weg funktioniert, dann ist das halt ab jetzt so. Setze JavaScript als Systemvoraussetzung auf der Seite und fertig.

Klar, ohne JS funktioniert einiges im Shop ja auch nicht. Aber einen JS-losen Weg bei solchen essentiellen Sachen zu präferieren, wäre halt immer das Optimum, zumal sich so auch einige weitere Fehlerteufel einschleichen können.

Und das ist eigentlich auch OK!

Ganz genau so.

Lange Rede kurzer Sinn, ohne die Grundsätzliche Architektur (welche mir reichlich seltsam vorkommt) zu ändern (was nicht möglich ist) ist und bleibt Ajax mit weitem Abstand die einfachste und sicherste Lösung.

Als sicher empfind ich es eben nicht, denn sobald irgendwas im JS passiert (deaktiviert, Fehler im Code, Fehler im Client, fehlerhaftes Encoding beim Interpretieren im Client, Verbindungsprobleme beim Übertragen des JS, ...) ist das Tracking dahin.

Selbst einfaches vor und zurück des Browsers kann da u.U. doch schon mehrfachbestellungen auslösen.

Das kann mir egal sein, ist ja nicht mein SAP-System. Das zu sichern können die Admins der entsprechenden Firmen machen.

Ich würde vorerst bei der AJAX Variante bleiben, und mir mal in nem ruhigen Moment überlegen, ob man die Grundarchitektur nicht verbessern kann.

Ich hab da keinerlei Einfluss drauf. Es ist ja nicht nur ein SAP-System, in Zukunft sollen es mehrere werden, insofern die Kunden des Shops SAP einsetzen und da ist die OCI-Schnittstelle ja bereits vorhanden.

 

[Kokuswolf]

Ist das Thema noch aktuell? Find's nämlich ganz interessant. Wobei ich diese Sinn-Diskussionen übersprungen habe.

Ein Detail ist mir nicht ganz klar. Ich möchte kurz dazu anmerken, das es einerseits HTTP POST als Aufruf gibt, und andererseits POST-Daten die darin verwendet werden können. Das ist ein wichtiger Unterschied. Letztere werden üblicherweise in "application/x-www-form-urlencoded" übertragen, was am Ende genauso aussieht wie urlencodierte GET-Parameter in einer URL. Jedoch werden POST-Daten auch u.a. in HTTP PUT verwendet.

Wäre der Fall nun so, das die SAP-Software auch HTTP GET erlaubt, so würde ich 302 Redirect auf GET vorschlagen, wo einfach die POST-Daten umgewandelt an die URL angefügt werden. (Auch (assoziative) Arrays lassen sich per GET übermitteln.)

Im übrigen ist vom 307 abzuraten, da viele Softwareentwicklungen diesen oft nicht entsprechend dem Standard implementiert haben. (Hab da meine eigenen Erfahrungen machen müssen)

Falls es aber keinen Ausweg gibt, und das SAP-System wirklich nur ausschließlich einen HTTP POST verarbeitet, hätte ich sogar noch einen Gedanken parat. Nachdem der POST verarbeitet wurde, folgt ein 302 Redirect (was ein GET sein muss) auf eine temporäre HTML-Seite, die die Daten erneut in ein Formular kappselt und dieses per JS sofort an die SAP-Adresse abschickt. Naja ... Problem wäre hier schonmal, das dies in der Historie des Browsers landen würde. Aber zumindestens wäre es ein gedanklicher Anfang.

 

[Yuuri]

Ist das Thema noch aktuell?

Wenn du ne JS-lose Variante hast, immer her damit.

Wäre der Fall nun so, das die SAP-Software auch HTTP GET erlaubt, so würde ich 302 Redirect auf GET vorschlagen, wo einfach die POST-Daten umgewandelt an die URL angefügt werden. (Auch (assoziative) Arrays lassen sich per GET übermitteln.)

Wäre... Das Problem ist, dass im Content auch Artikelbeschreibungen mitgeschickt werden und diese sind zwar kurz und bündig, allerdings kann man hier bei mehreren Artikeln natürlich problemlos bereits die 1000 Zeichen knacken (+ passend kodiert für die URL, ergibt ein bisschen Overhead). Sowas in ne URL zu verpacken... Erstens sehr unschön, zweitens bezweifel ich, dass die Webserver solche elendig langen URLs mitmachen. Der Apache soll ja "bereits" ab 4k Zeichen langen URLs Probleme bekommen.

Im übrigen ist vom 307 abzuraten, da viele Softwareentwicklungen diesen oft nicht entsprechend dem Standard implementiert haben. (Hab da meine eigenen Erfahrungen machen müssen)

War auch meine Angst, hab es auch nur im FF getestet und nicht im IE 6 - 8. Allerdings schreckt der Prompt beim Redirect ab, von daher...

die die Daten erneut in ein Formular kappselt und dieses per JS

Fällt somit raus, da es imho aufwändiger und fehleranfälliger als die bisherige Lösung ist. Lieber einen Request per Ajax anstatt diesen Request über mehrere Seiten zu schleifen.

 

[Kokuswolf]

Wäre... Das Problem ist, dass im Content auch Artikelbeschreibungen mitgeschickt werden ... [etc]

Artikelbeschreibungen mitschicken? Ok... naja, ansonsten der Webserver hätte aber nicht mehr Probleme das aus der URL zu verarbeitet - es ist nur eine Frage seiner Limit-Einstellung. Und diese Limitierung gibt es auch für POST-Daten. ... von daher wäre es interessant, ob und inwieweit eine Differenz in der Limitierung aussieht.

Ansonsten ...

Wenn du ne JS-lose Variante hast, immer her damit.

... sehe ich da nichts. Weder kann ein reiner HTML-Button(click) zwei simultane/hintereinanderliegende Request starten (ohne das JS das per AJAX übernimmt), noch kann irgendwie anderweitig per reinem HTML ein POST ohne Userhandlung erzwingen. Das liegt daran das sonst damit so einiges an Schindluder getrieben werden könnte.

 

[Yuuri]

naja, ansonsten der Webserver hätte aber nicht mehr Probleme das aus der URL zu verarbeitet - es ist nur eine Frage seiner Limit-Einstellung. Und diese Limitierung gibt es auch für POST-Daten.

Beim Apache gibt es aber des Öfteren Meldungen in den Weiten des Internets, dass er mit URLs Probleme ab ~ 4k Zeichen bekommt (obwohl das Limit bei 8k liegen soll). Mir wäre es neu, dass ein POST keine 4 kB groß sein darf (zumal man die POST-Length in der Config neu definieren kann). Der FF soll bspw. auch bei URLs mit 65k Zeichen keine Probleme haben.

Das liegt daran das sonst damit so einiges an Schindluder getrieben werden könnte.

Das liegt aber bestimmt nicht an der von Anfang an bedachten Sicherheit anno 1999 (oder ab wann das Formular in die Spezifikation genommen wurde), welche damals praktisch nicht existent war...

 

[Kokuswolf]

Mir wäre es neu, dass ein POST keine 4 kB groß sein darf (zumal man die POST-Length in der Config neu definieren kann).

Ich hab ja auch nichts davon gesagt wie groß die Limitierung ist, sondern nur, das es auch einer Limitierung unterliegt, die, wie Du es in den Klammer noch schnell formuliertest, genauso konfigurierbar ist.

Wenn die Apacheversion am anderen Ende von diesem ominösen Problem ab 4k Zeichen betroffen ist, dann geht es wohl nicht. Ich lese aber hier erneut raus, das Du es ja nicht weißt.