PHP Warning: Illegal string offset in linkpoint_api module

[11-Aug-2014 20:14:44 UTC] PHP Warning: Illegal string offset 'r_approved' in /home/xxx/public_html/153/includes/modules/payment/linkpoint_api.php on line 818
[11-Aug-2014 20:14:44 UTC] PHP Warning: Illegal string offset 'r_error' in /home/xxx/public_html/153/includes/modules/payment/linkpoint_api.php on line 818

PHP 5.4.31
Zen Cart 1.5.3

~Melanie

Turns out those warnings only occur if a communications error happens. So, they're symptomatic of a deeper problem.

I realize that, but why are both approved and error being triggered?

The logged Linkpoint error is

Communication Result: 60 - SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

So if the communication is failed, then why would the log also trigger approved?

~Melanie

v1.5.0

$ch = curl_init ();
curl_setopt ($ch, CURLOPT_URL,$host);
curl_setopt ($ch, CURLOPT_POST, 1);
curl_setopt ($ch, CURLOPT_POSTFIELDS, $xml);
curl_setopt ($ch, CURLOPT_SSLCERT, $key);
curl_setopt ($ch, CURLOPT_CAINFO, $key);
[B]curl_setopt ($ch, CURLOPT_SSL_VERIFYHOST, false);[/B]
curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt ($ch, CURLOPT_SSLVERSION, 3);
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, true);

v1.5.3

$ch = curl_init ();
curl_setopt ($ch, CURLOPT_URL,$host);
curl_setopt ($ch, CURLOPT_POST, 1);
curl_setopt ($ch, CURLOPT_POSTFIELDS, $xml);
curl_setopt ($ch, CURLOPT_SSLCERT, $key);
curl_setopt ($ch, CURLOPT_CAINFO, $key);
//    curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, FALSE); // NOTE: Leave commented-out! or set to TRUE!  This should NEVER be set to FALSE in production!!!!
curl_setopt ($ch, CURLOPT_SSLVERSION, 3);
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, true);

So adding the lines

      curl_setopt ($ch, CURLOPT_SSL_VERIFYHOST, false);
      curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, false);

Back in make it successful transaction with NO other changes.

~Melanie

I would strong caution against disabling certificate verification. Disabling verification opens the communications (with customer payment information) to man-in-the-middle attacks (and possibly other security concerns).

When the behavior you are reporting occurs, it usually indicates one of two things:

1. The payment gateway does not have a valid 3rd party signed certificate properly installed. This is a very rare case.
2. The hosting provider does not have the server properly configured to validate certificates (via cURL). Most times this means they have not installed a recent CA Certificate Bundle or cURL does is not configured to use installed CA Certificate Bundle... The hosting provider should be able to either update their bundle (and configure cURL server wide to use the bundle)... Or at least they should be able to tell you where the bundle is on their server (so you can add a CURLOPT_CAINFO or CURLOPT_CAPATH to the options for each call made by cURL).

Agreed... and I believe it is fixed by using the original lphp.php (http://cloud1.firstdata.com/downloads/customerservice/30006_api_php.zip)

So it would stand to reason that there is a bug somewhere in the Zen Cart version of lphp.php

~Melanie

CURLOPT_CAINFO The name of a file holding one or more certificates to verify the peer with. This only makes sense when used in combination with CURLOPT_SSL_VERIFYPEER. Requires absolute path.

http://php.net/manual/en/function.curl-setopt.php

What version of PHP is the server running?
What version of cURL is being used?

Found some time to take a little deeper look at this thread and the differences between the "lphp.php" and "class.linkpoint_api.php"... Can you try the following changes in "/includes/modules/payment/linkpoint_api/class.linkpoint_api.php" (changes in red):

$ch = curl_init ();
curl_setopt ($ch, CURLOPT_URL,$host);
curl_setopt ($ch, CURLOPT_POST, 1);
curl_setopt ($ch, CURLOPT_POSTFIELDS, $xml);
curl_setopt ($ch, CURLOPT_SSLCERT, $key);
// curl_setopt ($ch, CURLOPT_CAINFO, $key);
// curl_setopt ($ch, CURLOPT_SSL_VERIFYHOST, 2); // NOTE: Leave commented-out (removed in cURL 7.28.1)! This should NEVER be set to 0 in production!!!! (0 disables remote certificate "Common Name (CN)" verification against the remote server)
// curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, true); // NOTE: Leave commented-out! or set to TRUE! This should NEVER be set to FALSE in production!!!! (FALSE disables all remote certificate verifications)
curl_setopt ($ch, CURLOPT_SSLVERSION, 3);
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, true);

This should allow cURL to use the CA Bundle configured on the server (instead of trying to validate the remote linkpoint server certificate against the local linkpoint client certificate). For some reason I missed CURLOPT_CAINFO being set in the previous post.

mprough:

... So if the communication is failed, then why would the log also trigger approved? ...
Good question... When the transaction has been declined, the block starting at line 560 of "linkpoint_api.php" should trigger a redirect to the checkout payment page w/ an appropriate message to the customer... I did notice both versions of the Linkpoint API do not ensure r_approved will be returned after the initial processing of data via cURL...

The following changes should help ensure r_approved is set to a failure when not present. This should hopfully take care of the "Illegal string offset" error as well. Starting around line 811 in "/includes/modules/payment/linkpoint_api.php" (changes in red):

    include(DIR_FS_CATALOG . DIR_WS_MODULES . 'payment/linkpoint_api/class.linkpoint_api.php');
    $mylphp = new lphp;

    // Send transaction, using cURL
    $result = $mylphp->curl_process($myorder);
    if(!is_array($result)) {
    	$result = array(
    	  'r_approved' => 'FAILURE',
    	  'r_error' => 'Communications Error'
    	);
    }
    else if(!array_key_exists('r_approved', $result)) {
      $result['r_approved'] = 'FAILURE';
      $result['r_error'] = 'Communications Error';
    }

    // do debug output
    $errorMessage = date('M-d-Y h:i:s') . "\n=================================\n\n" . ($mylphp->commError !='' ? $mylphp->commError . "\n\n" : '') . 'Response Code: ' . $result["r_approved"] . ' ' . $result["r_error"] . "\n\n=================================\n\n" . 'Sending to Gateway: ' . "\n" . $mylphp->sendData . "\n\n" . 'Result: ' . substr(print_r($result, true), 5) . "\n\n";
    if ($mylphp->commError != '') $errorMessage .= $mylphp->commError . "\n" . 'CURL info: ' . print_r($mylphp->commInfo, true) . "\n";
    if (CURL_PROXY_REQUIRED == 'True') $errorMessage .= 'Using CURL Proxy: [' . CURL_PROXY_SERVER_DETAILS . ']  with Proxy Tunnel: ' .($proxy_tunnel_flag ? 'On' : 'Off') . "\n";
    $failure = ($result["r_approved"] != "APPROVED" ? true : false);

Not sure this the the best possible solution, but am curious to see what effect (if any) the changes have upon the situation...

NOTE: The above changes are have not been fully tested (and may contain errors). They are merely suggestions. Please test thoroughly before applying to a production website.

The correct fix for the SSL error is indeed to comment out this line, by adding the // as shown:```
[B]//[/B] curl_setopt ($ch, CURLOPT_CAINFO, $key);

Thanks a ton! I was facing the same problem... and just commenting out 1 line did the job! :)