PHP POST-Daten doppelt senden

[Yuuri]

Hallo zusammen,

folgendes Problem: Daten sollen im Formular an ein externes Script geschrieben werden. Vorher soll allerdings ein eigenes Script die Daten abfassen. Die bisherige Lösung war ein Javascript, was erst einen Ajax-Request ans eigene Script schickt und dann das Formular normal ans externe Script schickt. Funktioniert zwar, find ich aber nicht wirklich schön.

Als Möglichkeit wäre es ideal gewesen, wenn ich einfach alles an mein Script schicken kann und dann per Header ans externe Script weiterleiten kann. Der 307 Header sieht da ja schon recht vielversprechend aus, allerdings weiß ich nicht, ob er dafür eingesetzt werden sollte.

307 Temporary Redirect Die angeforderte Ressource steht vorübergehend unter der im „Location“-Header-Feld angegebenen Adresse bereit. Die alte Adresse bleibt gültig. Der Browser soll mit derselben Methode folgen wie beim ursprünglichen Request (d. h. einem POST folgt ein POST). Dies ist der wesentliche Unterschied zu 302/303.

Einfach umleiten (GET) geht natürlich nicht, dazu würden dann die Post-Daten im zweiten Request fehlen.

Irgendwelche anderen Ideen/Erfahrungen? Die JS-Variante würde ich gern abschaffen wollen.

Hintergrund: Ein SAP-System greift auf einen Shop zu, wo ich dann die Bestellungen im Shop tracken will, das SAP-System dann aber natürlich auch noch Daten erwartet. Hier bitte im Kopf behalten, dass evtl. der IE 8 verwendet wird.

Bevor ich also lange herumexperimentiere, würde ich gern noch ein paar Meinungen und Erfahrungswerte von anderen einholen, vielleicht hat ja jemand sowas schon mal gemacht.



LG

 

[DJND]

Hm... entweder so wie du es gemacht hast oder du schickst es nur an dein eigenes Skript und das wiederrum leitet es einfach an das eigentliche Ziel weiter, schickt die Antwort durch und fungiert damit quasi als eine Art Proxy.

 

[fRaNkLiN]

Hm... entweder so wie du es gemacht hast oder du schickst es nur an dein eigenes Skript und das wiederrum leitet es einfach an das eigentliche Ziel weiter, schickt die Antwort durch und fungiert damit quasi als eine Art Proxy.

+1, ich würde den ersten POST auch an dein PHP-Skript schicken, und das leitet die Daten dann per cURL an das SAP-System weiter.

 

[Yuuri]

Hab grad mal die 307-Variante getestet: Funktioniert wunderbar, allerdings erscheint im Browser dann die Abfrage, ob die Anfrage inkl. Formulardaten an die neue Adresse verschickt werden soll. Im Praxiseinsatz also leider unpraktikabel.

Die Proxy-Art klingt auch gut, muss ich nur mal die Rahmenbedingungen klären.

 

[rumbalotte]

Ich würde es, wie von fRaNkLiN vorgeschlagen, vom Server aus (also durch Dein PHP Script) via cURL an das 2. Post Formular schicken.
Eine doppelte Versendung wäre mir persönlich als User auch ziemlich suspekt.

 

[Yuuri]

Die Proxy-Variante funktioniert so nicht, da noch eine Interaktion auf der Gegenseite gemacht werden muss.

 

[gaunt]

Was spricht denn gegen die Aktuelle variante? So ähnlich arbeiten viele Tracker.

Was auch ginge:
- Nachdem Submit wird ja i.d.R. eine weitere Seite angezeigt. Die könnte ein Tracking Pixel mit den nötigen Daten aufrufen.
- Umleitung über eine Tracking Domain (Click Out Tracking) muss nicht sein, würde aber funktionieren. Könnte aber Probleme mit Privacy Modulen im Browser geben.
- Serverseitig geht natürlich auch und ist am genauesten. Aber brauchst du das wirklich? Frontend Tracking nutzt man üblicherweise nur zur Usage Analyse. Operative Transaktionsdaten bekommst du ja eh am einfachsten über die DB oder das Backend.

 

[Yuuri]

Gegen die aktuelle Variante spricht, dass viel zu viel gemacht werden muss, um die Daten zu übermitteln, plus dass ohne JavaScript kein Tracking der Bestellungen funktioniert. Ist also mal irgendwo durch nen dummen Zufall n Fehler im JavaScript (der JS-Code wird als einzelne Datei gesammelt und minimiert übermittelt), ist das Tracking im Arsch oder sei es durch ein Problem mit einem Browser, einen Bug darin, irgend eine "Sicherheitseinstellung" o.ä. Es ist zu fehleranfällig.

1. Bestellknopf betätigen
2. Overlay basteln
3. Request absetzen
4. Rückgabe überprüfen
5. Overlay anpassen (+ Error Handling)
6. Overlay anpassen
7. richtiger Submit

Bspw. musste ich letztens erst einen Bugfix in svg-edit einspielen, da der Firefox über verschiedene Versionen lang, die Positionsdaten versaubeutelt hat. Sowas macht keinen Spaß. Deswegen hätte ich lieber gern eine Variante, die ohne großen Code auskommt und sauber funktioniert.

Wie gesagt: Shop-System + SAP-System. Auf das SAP-System hab ich keinerlei Zugriff und eine Anpassbarkeit dessen ist nicht möglich (würde sicherlich gehen, ist aber ein extremer Aufwand + muss ein funktionierendes (externes) System geändert und durchgetestet werden, dessen Admin wird mir den Vogel zeigen). Im SAP-System (so wurde mir berichtet), wird die Bestellung vom Shop per POST übertragen und darin wird die Bestellung nochmal aufgezeigt (+ manuelle Nachbesserung, Druckmöglichkeit, ...) und muss darin bestätigt werden. Anschließend wird eine PDF generiert und diese wird dann als Auftragsbestätigung versendet.

Auf das SAP-System hab ich ergo keinen Einfluss - null. Das Ding wird nirgendwo angepasst werden, ergo muss vom Shop her selbst alles Mögliche selbst funktionieren.

• AJAX-Request mit Sammeln der Daten und Absenden an lokales Script + realer Submit an externes Script: funktioniert, ist aber unschön
• 307 Header: funktioniert, allerdings kommt dann eben genannte Abfrage, wodurch es unpraktikabel wird (zumal ich es nicht in IE 7 und 8 (= mögliche Kandidaten) getestet habe)
• Proxy-Variante per cURL: funktioniert nicht, da nachfolgende Interaktion unmöglich ist
• Tracking-Pixel o.ä.: siehe cURL bzw. muss ein externes System angepasst werden
• Umleitung über Domain: funktioniert nicht, die POST-Daten gehen verloren bei jeglichem Redirect (außer beim 307 Header, aber da kommt eben jene unschöne Abfrage)

 

[Daaron]

Die einfachste und eleganteste Lösung: Löse alles direkt im Shop und füttere den SAP-Kram nachranging mit den eingegangen Daten, z.B. per Cronjob. Ein Shopsystem sollte immer in sich geschlossen und logisch sein.

 

[gaunt]

Fast niemand hat Java Script aus. Ohne JS kannst du heute kaum noch eine Seite vernünftig nutzen. Sehe ich persönlich absolut unproblematisch. Alle unsere Tracker arbeiten primär mit JS und nutzen statische Pixel nur für den Notfall, der aber nur selten eintritt. Das man natürlich keine Fehler drinn haben sollte ist klar.

307 ist Mist. Der ist dafür nu wirklich nicht gedacht.

Aber wenns kein JS sein kann/darf. Naja, dann eben Serverseitig die Daten weiterleiten. Wenn ichs richtig verstanden habe kannst du den Shop (was für einer isses denn?) anpassen (irgendwas musst du ja anpassen). Dann einfach nachdem die Bestellung peristiert wird weiter leiten. Ob mit cUrl, einem WS Aufruf, ner simplen Socket Verbindung oder wie auch immer bleibt dir überlassen bzw. ist vom Zielsystem anhängig.

Man kann sich sicher noch mehr ausdenken. Der Webserver selber könnte Requests auf eine URL Tracken, oder ein z.B. Varnish sitzt davor und kann bei einem Request zwei Backends aufrufen... Ist aber alles schräg!

Ich bleib dabei. Das mit Abstand einfachste ist die JS Variante und für Trackingzwecke auch genau genug.

 

[Yuuri]

Löse alles direkt im Shop und füttere den SAP-Kram nachranging mit den eingegangen Daten, z.B. per Cronjob.

Dann sind wir aber wieder beim Problem, dass der Mitarbeiter diese Bestellung nicht bestätigen kann. Die POST-Daten gehen ans SAP-System, der Mitarbeiter muss darauf diese nun eingegangene Bestellung bestätigen. Per Cron wäre es das gleiche System wie mit einem cURL-Request. Die Bestellung wäre nun losgelöst, der Mitarbeiter hat keine direkt Übertragung mehr, ggf. ist die Bestellung im SAP-System, allerdings schwebend, da der Mitarbeiter seine Bestellung nicht bestätigen kann. Ergo unbrauchbar.

Fast niemand hat Java Script aus.

Was mir nur nichts bringt, wenn im Zielsystem noch ein IE 6 werkeln muss. Der IE < 8 wird beim Shop auch nur noch sehr stiefmütterlich behandelt, Fokus liegt natürlich auf IE 9+ (bei dem selbst svg-edit wunderbar funktioniert). Wenn nun aber ein System mit dem IE 6 ankommt, funktioniert auf einmal evtl. einiges nicht mehr und man muss wegen dieser einen Sache alles umkrempeln und erneut durchtesten. Das macht keinen Spaß. Deswegen hätte ich gehofft, dass jemand einen einfachen non-JS-Weg kennt.

Ohne JS kannst du heute kaum noch eine Seite vernünftig nutzen.

Dann ist die Seite aber nicht vernünftig gebaut. Der Shop um den es hier geht, funktioniert technisch ohne JS wunderbar (bis auf Kleinigkeiten und Gimmicks wie Slider). Und warum sollte es dann genau beim Wichtigsten, dem Absenden der Bestellung, hapern?

Aber wenns kein JS sein kann/darf.

Kann: ja
Darf: ja
Sollte: nein, außer es geht nicht ohne (so wie momentan gelöst)

Naja, dann eben Serverseitig die Daten weiterleiten.

Was nicht funktioniert, da der Mitarbeiter im SAP-System die Bestellung noch weiter bearbeiten kann, ausdrucken kann und hierbei noch eine Bestätigung für diese Bestellung geben muss. Ok, ich weiß nicht, ob die Bestellungen dort dann in einer Queue landen und abgearbeitet werden, allerdings zweifel ich an dieser Methodik sehr stark. Der Server kann hierbei die Dinge nicht per cURL oder was auch immer weiterleiten, da der Mitarbeiter hierbei noch immer im Shop weilt und der Server somit die Interaktion mit der Bestellbestätigung machen müsste, da ja nur dieser die POST-Daten weitergibt. Geht natürlich nicht, da er keinen Zugriff aufs SAP-System hat und dies wohl auch nicht automatisch passieren dürfte.

was für einer isses denn?

Ein extrem angepasstes xt.

Das mit Abstand einfachste ist die JS Variante und für Trackingzwecke auch genau genug.

Ja, weil es wohl leider keine andere Möglichkeit gibt ein Formular an mehrere Stellen zu übergeben. Eine JS-lose Variante würde ich trotzdem immer und überall vorziehen. Scheint eben nur leider nicht so reibungslos zu funktionieren.

 

[Daaron]

Fast niemand hat Java Script aus.

Dann guck ma rüber ins Sicherheits-Forum, zu den ganzen Paranoikern, die meinen sich hinter NoScript & Co verstecken zu können.

 

[gaunt]

Dann guck ma rüber ins Sicherheits-Forum, zu den ganzen Paranoikern

Von den Nerds absehen ist das auf normalen Seiten kaum noch ein Problem. Und wer bewusst JS abschaltet muss sich im klaren sein das er bestimmte Dienste nicht nutzen kann. Ich kann auch nicht Auto fahren wenn ich nicht bereit bin einen Zündschlüssel zu benutzen.

Ich verstehe langsam dein Problem nichtmehr. Aktuell werden Daten vom Client gesendet und bis auf das JS Problem war das wohl auch grundsätzlich OK. Jetzt kann aber der Shop Server nicht aktiv werden, weil im SAP ein Approval erfolgen muss. Das hat doch aber bis dato das JS vermutlich auch nicht bekommen.
Außerdem sollte es doch ein commit oder rollback vom SAP an den Shop geben, sonst laufen dir die Datenbestände in beiden Systemen auseinander. Dann lass eben den Server CURLen wenn er ein Commit bekommt?!?

Und warum sollte es dann genau beim Wichtigsten, dem Absenden der Bestellung, hapern?

Die Bestellung funktioniert wie gehabt. Der AJAX Call passiert doch optional. Will heißen die Bestllung geht durch, und wenn der Client JS fähig ist macht er einen Tracking Call. Wenn nicht fällt das Tracking in dem seltenen Fall untern Tisch. Kein Mensch (sofern er halbwegs bei Verstand ist) nutzt Tracking Daten für sensible Operationen (dafür habt ihr vermutlich das SAP System). Beim Tracking hat man immer Abweichungen und lebt i.d.R. einfach damit.

Zitat von Seth666
Diskutier nicht mit Holz.

KTWR?

 

[Daaron]

Ich kann auch nicht Auto fahren wenn ich nicht bereit bin einen Zündschlüssel zu benutzen.

Schlechtes Beispiel... Keyless Go lässt grüßen

 

[Yuuri]

Jetzt kann aber der Shop Server nicht aktiv werden, weil im SAP ein Approval erfolgen muss. Das hat doch aber bis dato das JS vermutlich auch nicht bekommen.

Genau da setzt ja der JS-Ansatz an.

Von vorn:

Das bestehende Formular (mit Warenkorb) wird einfach an ein externes Formular per POST gesendet (direkt an die Schnittstelle vom SAP-System). Hier greif ich dabei per JS ein, indem ich beim Submit des Formulars alle zu übertragenen Daten abgreife und diese an mein Script sende. Gibts einen Success zurück, gibts ein return true im onSubmit, wodurch das Formular nun erst abgesendet wird und somit regulär die Daten ans externe Script schickt.

Was nun beim SAP-System akzeptiert wird ist vorerst egal. So bekommt man im Shop immerhin eine Übersicht an Bestellungen, denn die richtige Bestätigung der Bestellung kommt nur als PDF bzw. als Fax. Hier mit OCR anzugreifen, halte ich für vollkommen übertrieben.

Ja, der Ablauf könnte besser sein, ist er aber nicht. Daran gibts jetzt nichts zu rütteln.

Kein Mensch (sofern er halbwegs bei Verstand ist) nutzt Tracking Daten für sensible Operationen (dafür habt ihr vermutlich das SAP System).

Das SAP-System ist ein Fremdsystem, auf das kein Zugriff existiert. Firma B nutzt ihr SAP-System, um bei Firma A im Shop zu bestellen.

 

[Daaron]

Das ganze Setup ist, gelinde gesagt, von vorn bis hinten total beknackt. Du kannst hier Jahre damit zubringen, die verschiedenen Schichten des Problems abzutragen, am Ende wäre es besser, hier einen komplett neuen, sauberen und einheitlichen Ansatz zu wählen.

Ich versteh aber dein Problem bei obigen Ablauf hinsichtlich cURL (via PHP) nicht.
- Warenkorb sendet an PHP-Script
- PHP-Script startet cURL-Request an das Script, das du aktuell per JS ansprichst
- PHP-Script werter die erste Response aus
- Wenn "true" -> PHP-Script sendet die Daten per cURL an die SAP-Schnittstelle
- Falls nötig: PHP-Script wertet Antwort der SAP-Schnittstelle aus und präsentiert sie dem Käufer

Das ist nicht viel anderes als ne PayPal-Zahlung, bzw. die Auswertung von IPN.

 

[Yuuri]

Das ganze Setup ist, gelinde gesagt, von vorn bis hinten total beknackt. Du kannst hier Jahre damit zubringen, die verschiedenen Schichten des Problems abzutragen, am Ende wäre es besser, hier einen komplett neuen, sauberen und einheitlichen Ansatz zu wählen.

Ich nehm das System so wie es ist, was seit Jahren nun so besteht. Das nun umzukrempeln ist volkommen an den Haaren herbeigezogen. Weißt doch mit Sicherheit selbst wie es ist.

Ich versteh aber dein Problem bei obigen Ablauf hinsichtlich cURL (via PHP) nicht.

Hab es doch schon mehrfach beschrieben.

Firma B (fremd) nutzt ein SAP-System. B nutzt den Browser darin, dieser verbindet auf den Web-Shop von Firma A (eigen). Beim Login wird eine Rücksprungadresse als GET-Parameter hinterlegt und damit eingeloggt (die URL, auf die das Formular dann sendet). Danach alles zusammengetragen, in den Warenkorb gelegt usw. bis alles vorhanden ist. Im Warenkorb (es gibt ergo keine Checkout-Seiten) gibts dann einen Bestellen-Button nur für SAP-Systeme. Im Hintergrund wird ein Formular aufgebaut (alles bestehend aus Hidden-Feldern), wobei diese Daten alle ans SAP-System per POST zurück gehen. Das wars von der Shop-Seite aus.

Wie ich nun die Tage erfahren habe, wird dann alles ans SAP-System zurückgeschickt, dort kann die Bestellung in Mengenangaben, Positionen usw. noch verändert werden. Schlussendlich muss die Bestellung abgenickt werden. Daraufhin wird eine PDF generiert und anschließend als Fax von Firma B an Firma A verschickt.

Die Bestellung wäre auf diesem Weg also nicht im Shop verzeichnet, da der "Checkout" im Warenkorb bzw. im SAP-System passiert und aufgrund der POST-Daten und der nachfolgenden Interaktion im SAP-System im Client selbst passieren muss.

Der bisherige Ansatz war also, den Submit des Formulars abzugreifen, alle Daten dann ans eigene Script zu schicken, eine Bestellung manuell auszulösen und bei Erfolg den gewohnten Ablauf weiterzuführen.

Unterschied zu PayPal: Ich werde nicht umgeleitet und komme nicht zum Shop zurück. Ich bestelle im Shop und verbleibe dann im SAP-System. Ich bekomme keine Meldung zurück, keine Tracking-Pixel, kein gar nichts. Sobald die POST-Daten abgesendet wurden, bekomme ich keinerlei Daten mehr, von nirgendwo. Der Bestellvorgang endet im Warenkorb und sobald der SAP-Bestellbutton gedrückt wurde, habe ich keinerlei Handhabe mehr.

 

[Daaron]

Du brauchst doch auch keine Handhabe. Der Browser (egal, ob er Teil eines SAP ist oder nicht) redet mit dem Shop. Der Shop redet dann mit SAP... Was hindert dich denn daran, dass der Shop eben NICHT erst mit SAP redet sondern per cURL die DAten vorher noch verarbeitet? Dafür benötigt es keine Rückmeldungen. Du willst die Daten doch ERST von deinem eigenen Auswertungsscript verarbeiten lassen, und DANN ans SAP schicken. Also kann dir das Fehlen einer Rückantwort von SAP doch vollkommen Banane sein.

Und du hast den Paypal-Vergleich falsch verstanden. Du solltest mal einen Blick auf IPN werfen. Da sendet PayPal bei Zahlungseingang einen Request an eine (vorher von dir angegebene) URL. Das dort befindliche Script spielt dann erst mal cURL-Pingpong mit PayPal um die Daten zu verifizieren und setzt dann die zugehörige Bestellung auf Bezahlt.

 

[Yuuri]

Der Browser (egal, ob er Teil eines SAP ist oder nicht) redet mit dem Shop. Der Shop redet dann mit SAP...

Nein, der Browser/SAP redet mit dem Shop. Punkt aus. Shop und SAP-System haben keinerlei Kontakt.

Und du hast den Paypal-Vergleich falsch verstanden. Du solltest mal einen Blick auf IPN werfen. Da sendet PayPal bei Zahlungseingang einen Request an eine (vorher von dir angegebene) URL. Das dort befindliche Script spielt dann erst mal cURL-Pingpong mit PayPal um die Daten zu verifizieren und setzt dann die zugehörige Bestellung auf Bezahlt.

Gut, andere Methode. Ja, da haben Shop und Server Kontakt. Bei mir aber nirgends.

Wie bereits mehrmals gesagt: Das SAP-System (bzw. nur der Browser) hat Kontakt mit dem Shop. Wenn die Bestellung fertig ist, sendet der Browser ein Formular ans SAP-System zurück. Der Shop hat hier null Kontakt mit dem SAP-System selbst, einzig weiß er, dass ein Browser auf ihn zugreift.

http://www.hagemeyerce.com/desktopdefault.aspx/tabid-321/437_read-7988/ -> Ablaufdiagramm OCI-Schnittstelle

 

[Daaron]

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?

Es geht mir um folgendes: Derselbe Knopf, der aktuell deine halbgare JS-Lösung beherbergt, kann doch von dir frei manipuliert werden, oder? Du kannst den Submit doch sicher problemlos dahin leiten, wo DU es für witzig erachtest und zurückgeben, was DIR richtig vor kommt. Der SAP-Browser startet n (POST-)Request, und der Shop reagiert mit ner Response, einfachstes HTTP. Diesen Request nach deinem Gutdünken umzuleiten, zu manipulieren, zu loggen,... sollte doch machbar sein.

Ansonsten gilt: Geht nicht, ist nicht, war von Anfang an falsch konzipiert.