Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- paypal_plus [2017/06/08 16:50] – [Oxid] gerald
+++ paypal_plus [2024/02/29 13:36] (aktuell) – Externe Bearbeitung 127.0.0.1
@@ Zeile 5: / Zeile 5: @@
 Das PayPal-Plus Modul für Oxid eShop ist ein Alptraum. Dass sie das über eine/die Paywall gelöst haben, ist nicht sehr schön. Schon allein, weil bestimmte Tags bei jedem Theme vorhanden sein muss und man die Tags in den Einstellungen definieren muss (kann, weil man ja alles so lassen kann). Und das für jedes Theme. Was ist, wenn jemand ein völlig eigenes Theme verwendet (nicht basierend auf best. Theme)? Dann kann man wohl kein PPP verwenden.
-Zudem ist lt. Installations-PDF nicht garantiert, dass es mit dem Mobile Theme funktioniert. What??
+Zudem ist lt. Installations-PDF nicht garantiert, dass es mit dem Mobile Theme funktioniert. What?? Und das Modul ist wirklich ein ungeheures Dateimonster, weil die **gesamten** PayPal-REST-API-Dev-Bibliotheken dabei sind.
@@ Zeile 35: / Zeile 35: @@
 __modules/payp/paypalplus/out/src/js/payppaypalpluswall.js__
+  (/var/www/webserver/oxid2/modules/payp/paypalplus/out/src/js/payppaypalpluswall.js)
 Also lauter alerts gesetzt, um zu schauen, wo genau der Fehler auftritt.
@@ Zeile 54: / Zeile 54: @@
 Dann funktioniert es
-Offenbar wird als variable mData nicht nur der Token, sondern eine ganze Menge HTML-Text (die ganze PayWall??? Jedenfalls nicht die komplette Seite, aber zumindest ein Teil davon) übergeben. Warum kommt da die Seite raus?
+Offenbar wird als variable mData nicht nur der Token, sondern eine ganze Menge HTML-Text (die ganze PayWall??? Jedenfalls nicht die komplette Seite, aber zumindest ein Teil davon) übergeben. Warum kommt da die Seite raus? Bei der Seite OHNE Modul kommt als mData nur der Teoken (z.B. 43b313cd4063405a5d06a073db35e0bf).
 Die jQuery.ajax-Dokumentation ((http://api.jquery.com/jquery.ajax/)) sagt dazu:
@@ Zeile 62: / Zeile 62: @@
 A function to be called if the request succeeds. The function gets passed three arguments: The data returned from the server, formatted according to the dataType parameter or the dataFilter callback function, if specified; a string describing the status; and the jqXHR (in jQuery 1.4.x, XMLHttpRequest) object. As of jQuery 1.5, the success setting can accept an array of functions.
 </code>
+Meine Nachforschungen haben ergeben: per Ajax wird nicht etwa PayPal aufgerufen, sonder der Shop selbst. Mit der Form der Seite als POST (console.log("Request: " +  form.serializeArray().toSource()  );
+ sagt: [{name:"stoken", value:"73EED611"}, {name:"lang", value:"0"}, {name:"actcontrol", value:"payment"}, {name:"cl", value:"payment"}, {name:"fnc", value:"validatepayment"}, {name:"paymentid", value:"payppaypalplus"}]). Als Ergebnis wir der Inhalt des Tokens erwartet (oder eine Fehlermeldung). Das ist offenbar so eine Art Sicherheitsvorkehrung, um den Token, der ja im Quelltext der Seite steht zu verifinzieren. Erst wenn der Token der Selbe ist, wird die Zahlung initiiert.
+Mein Modul fängt auf POST-Request ab, weil ja die Leute die NB-Nummer eingeben müssen. Daher kommt offenbar auf den Ajax-Request (fnc: validatepayment) nicht nur der Token, sondern die Seite ohne diese spezielle Funktion. Offenbar beisst sich da was mit meinem Modul. Uff! Übrigens: Diese Sicherheitsvorkehrung halte ich für fraglich, denn wenn sich jemand die Mühe macht, den Toklen im DOM zu ändern, dann kann er sich auch die Mühe machen, den Ajax-Request im DOM zu ändern auf eine Seite, die dann genau den geänderten Token zurück gibt. Augenwischerei?
+Mein Verdacht lt. metadata.php (PayPal): 'payment'   => 'payp/paypalplus/controllers/payppaypalpluspayment',
+OK, der Ajax-Request hat offenbar nicht (nur) Sicherheitsaspekte. Die überlagernde Mathode validatePayment() in der 'payp/paypalplus/controllers/payppaypalpluspayment.php' updated anscheinend das PayPal-Payment.Offenbar wird die Methode nicht ausgeführt, wenn mein Modul geladen ist.
+OK, das ist es auch nicht. /payppaypalpluspayment.php wird ausgeführt. Bei der Funktion _updatePayment() (ca. Z. 374) fibt es eine IF-Abfrage:
+<code>
+        $oShop = paypPayPalPlusShop::getShop();
+        if ($oShop->getValidator()->isPaymentCreated() and $oShop->getRequestParameter('ajax')) {
+</code>
+Der 1. Teil der Abfrage (isPaymentCreated()) ist nicht 1. Daher gibt es einen Fehler. Bin ein Stück weiter.
+Jetzt weiter: im File core/payppaypalplusvalidator.php die Methode isPaymentCreated($oPayment = null) (ca. Z. 135). Der Aufruf '$mPayment = $this->getShop()->getPayPalPlusSession()->getPayment();' fibt ein (bool)false zurück, obwohl $this->getShop()->getPayPalPlusSession() bis dahin ein Objekt ist. Dann geht das folgende if ($mPayment instanceof PayPal\Api\Payment) { schief.
+Hängt es vielleicht doch damit zusammen, dass ich vor die Bestellnummer stets noch ein 'NB' setze??? Nachrecherchiert: ne, ich ändere die Bestellnummer nicht intern, sondern nur in der Repräsentation. Kann es also auch nicht sein. Versuche, bei PayPal noch ein NB davorzisetzen, wenn nötig, scheitern auch.
+Also: in der _updatePayment() kommt die InvoiceNumer MIT NB an. Wenn ich $oShop->getValidator()->isPaymentCreated("ajax") im IF unschädlich mache, gibt es Fehlermeldung, weil das Update $oPayPalPaymentHandler->update($oPayPalSession->getApiContext()); kein Objekt übergeben bekommt. ABER: Wenn ich $this->_ajaxResponseSuccess(); nach oben setze, dann kommt der korrekte Token so wie er soll und und die ganze Chose funktioniert!
+Es liegt also tatsächlich daran, dass $oShop->getValidator()->isPaymentCreated() false ist. Offenbar kann er die (PayPal)Session nicht korrekt auslesen ($mPayment = $this->getShop()->getPayPalPlusSession()->getPayment(); in ...validator.php) . Oh. Oder die Session wird gar nicht korrekt gespeichert.

Nach oben

paypal_plus.1496940640.txt.gz · Zuletzt geändert: 2024/02/29 13:36 (Externe Bearbeitung)

Übersicht Letzte Änderungen

Admin