Updated: Comment #14
User hits an access denied error, when clicking on "Back to store" link on the paypal confirm page after a successful paypment.
Steps to reproduce:
- Create a PPS payment method via the UI
- Create a payment form with as in paypal_payment_pps_test_payment_form()
- User hits payment button and gets redirected to paypal
- User logs into the paypal account and confirms the payment
- Paypal calls in on /paypal_payment_ipn and a record is created in the table paypal_payment_ipn
- User clicks on 'back to store'-link
- /paypal_payment_pps/return is hit and function paypal_payment_pps_return_access() is called, which subsequently calls PayPalPaymentIPNController::validate($_POST)
- PayPalPaymentIPNController::validate returns FALSE because in line 141 in PayPalPaymentIPNController.inc the load function returns the record created in step 3
Is that a correct analysis of what happens? Is this how it should happen? It seems wrong that the validate method fails when the POST-Request is valid but has already been processed.
The proposed solution in #8 adds a test to discover this issue as well as a solution based on the following:
- Grant access to the return function when valid POST data as expected from PayPal is present in the request, so as to identify the transaction.
- Grant access to the return function only to the user associated with the transaction.
- Process the incoming data only if it has not been processed, so to say on the first request (in the given scenario this is the request generated by IPN).
Review patch #8.
Ideally also test the test coverage. For that you can apply the patch #6.
With this patch you should run the paypal_payment tests and it should fail. Then revert the changes, apply patch #8, run the tests again. They should pass. Follow the steps above to reproduce the error. It should not produce an access denied when coming back from the paypal site.
FAILED: [[SimpleTest]]: [MySQL] 179 pass(es), 2 fail(s), and 0 exception(s). View