Cybersource Developer Community Cybersource Developer Community

autojunkie05 · ‎02-25-2015

Hello,

So today I came in and we were unable to charge any orders through Authorize.net CIM SOAP API, after talking with their support they said this is a magento wide issue.

I've found the issue, they're response header has changed lengths from 335 characters to 395 characters. The module we were using has a parseXML function like this:

public function parseXML($start, $end, $xml)	 {
		return preg_replace('|^.*?'.$start.'(.*?)'.$end.'.*?$|i', '$1', substr($xml, 335));
	}

What is should really be is:

public function parseXML($start, $end, $xml)	 {
		return preg_replace('|^.*?'.$start.'(.*?)'.$end.'.*?$|i', '$1', substr($xml, 395));
	}

Realistically we should probably use strpos($xml, "<?xml ") in place of "substr($xml, 395)" which would prevent future issues if the response header changes, but unfortunately I don't have time to debug this right now, at least it works...

elreason4 · ‎02-26-2015

Posted February 26, 2015 by IDP & filed under Magento E-Commerce.

IDP Auth Net CIM Plugin Users:

There was an issue with the Authorize.net CIM plugin for Magento. This was a widespread issue with Magento and developers using the CIM SOAP API integration with Auth Net. The issue was reported here:

http://community.developer.authorize.net/t5/Integration-and-Testing/Developers-with-Magento-having-i...

For paid users of the IDP Auth Net Plugin here is the solution:

file: /app/code/local/IDP/AuthorizeCIM/Model/Authorizecimsoap.php

Simply replace the parseXML() function->

public function parseXML($start, $end, $xml) {

$xmlbegin = 0;

$xmlbegin = strpos($xml,”?>”);

if($xmlbegin>0) { $xml = substr($xml,$xmlbegin+2); }

return preg_replace(‘|^.*?’.$start.'(.*?)’.$end.’.*?$|i’, ‘$1′, $xml);

}

The newest version of the Auth Net CIM plugin has other enhancements, but this one change would immediately solve this issue if you choose. The link has the full directory that may affect customizations (though if only the template files were changed the link is safe to use). For standard installation fee I could update your module taking into account any behaviors that were customized. However, replacing the function above would fix this immediate anomaly with no other effects.

Thanks,

Eric Levine

elevine@goidp.com

http://www.goidp.com/blog/authorize-net-cim-plugin-magento-fix/

View solution in original post

Lilith · ‎02-25-2015

@autojunkie05 This is great information, thank you.

Could you elaborate on what you mean by "response header"? Do you mean the HTTP headers prior to the XML stream? Or do you mean the root element of the XML?

--
"Move fast and break things," out. "Move carefully and fix what you break," in.

autojunkie05 · ‎02-25-2015

yes, I mean the HTTP response header before the XML Response:

HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 501
Content-Type: application/xml; charset=utf-8
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET,POST,OPTIONS
Access-Control-Allow-Headers: x-requested-with,cache-control,content-type,origin,method
Date: Wed, 25 Feb 2015 20:13:55 GMT

ï»¿<?xml version="1.0" encoding="utf-8"?><createCustomerProfileResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"><messages><resultCode>Error</resultCode><message><code>E00039</code><text>A duplicate record with ID XXXXXXXX already exists.</text></message></messages><customerPaymentProfileIdList /><customerShippingAddressIdList /><validationDirectResponseList /></createCustomerProfileResponse>

it's 395 characters to the actually XML response, and there's a few weird characters before the response (and some special characters in the HTTP header) that throw off the regex expression and prevent the code in magento from parsing the XML tags for the data. I'm assuming that the previous HTTP response was only 335 characters because that was the value in the orginal function "Substr($xml, 335)" Which worked up until this moring.

If you take the original function:

public function parseXML($start, $end, $xml)	 {
		return preg_replace('|^.*?'.$start.'(.*?)'.$end.'.*?$|i', '$1', substr($xml, 335));
	}

and run the response I posted above this in this post, you'll see that it incorrectly parses the XML

elreason4 · ‎02-26-2015