Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende ÜberarbeitungNächste ÜberarbeitungBeide Seiten der Revision |
paypal_plus [2017/06/08 17:49] – [Oxid] gerald | paypal_plus [2017/06/09 15:32] – [Oxid] gerald |
---|
</code> | </code> |
| |
Meine Nachforschungen haben ergeben: per Ajax wird nicht etwa PayPal aufgerufen, sonder der Shop selbst. Mit der Form der Seite als POST ([{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! | 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', | 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. |
| |
| |
| |
| |
| |
| |
| |
| |