More secure IPN postback check and capture registration

[jonathanselander]

High-traffic clients have experienced issues with Paypal IPN postbacks not being registered and invoices not being marked as captured. Adding this patch has fixed the issue

[magento-team]

Hello. We will look into this issue and let you know if we can merge it or otherwise fix it.

[Detzler]

I can confirm that a problem exists at the postback result

I've dumped the array which contains the postback results and it looks like this:

[postback_result] => HTTP/1.1 200 OK
Date: Wed, 11 Apr 2012 12:51:48 GMT
X-Frame-Options: SAMEORIGIN
Set-Cookie: .....
HEADERSTUFF...................

Here comes the body.. nothing interesting

Now look at the paypal-request which made my shop-client angry:

[postback_result] => HTTP/1.1 100 Continue
Set-Cookie: ........ path=/; domain=.paypal.com

HTTP/1.1 200 OK
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=14400
Content-Type: text/html; charset=UTF-8

The connection wants to have a deal with 100-status. The script doesn't parse this request data correctly.
Take a look at this library which avoid the 100-status-problem:

magento2/lib/Zend/Service/WindowsAzure/Storage.php

Line 381 in 4bdbf6b

// - disable Expect: 100 Continue

Either we fix the parsing routine or we just tell paypal that it should use http1.0, not 1.1

[stollr]

Same problem here. But an easier solution @mage2-team :

    $response = preg_split('/^\r?$/m', $response);
    $response = trim(array_pop($response));

Using HTTP 1.0 is no solution, because it is not supported by PayPal's IPN service anymore.

[Detzler]

It would be great to see the IPN-Model-Class following the single reponsibility principle and just handling the primary logic (paypal stuff) instead of focusing on how to parse a raw http body.

[erfanimani]

I can confirm this issue and agree with @Naitsirch ' solution.

I replaced

$response = preg_split('/^\r?$/m', $response, 2);
$response = trim($response[1]);

with

$response = preg_split('/^\r?$/m', $response);
$response = trim(end($response));

Link to blogpost: http://www.dhmedia.com.au/blog/debugging-paypal-ipn-postback-failure-magento

@Detzler has a good point. The class that is responsible for the curl request should also be able to deal with curl error codes (see http://curl.haxx.se/libcurl/c/libcurl-errors.html) because currently, if a request times-out for whatever reason, there is no way to easily see what happened (in the exception logs for example).

[stollr]

And if there is a timeout or server error on PayPal's side, Magento should return a HTTP 500 error code. Otherwise the IPN won't be repeated, because Paypal thinks that everything worked fine.

[verklov]

Hello jonathanselander,
Sorry for the delay with the response.
Magento2 code began using the new magento lib Curl class https://github.com/magento/magento2/blob/master/lib/Magento/HTTP/Adapter/Curl.php, which pre-processes the response in the read method, eliminating the 100/101 response prefix. The call is now made from: https://github.com/magento/magento2/blob/master/app/code/Magento/Paypal/Model/Ipn.php#L185. The existing implementation should safely ignore 100/101 response prefixes.
We are closing this issue.