Reply
Highlighted
Contributor
Posts: 11
Registered: ‎11-06-2011
Accepted Solution

ARB response has changed, causing application to think it wasn't approved

I have an ARB set up that has been working flawlessly for almost 4 years now. Now all of a sudden it is failing each and every time someone signs up. When I say failing it is not returning the correct response text.

 

The subscriptions are being set up correctly at authnet but the returned response no longer triggers the correct block of code in AuthnetARB.class.php. The block of code I am referring to is in the process function:

            if ($this->resultCode == "Ok")
            {
                $this->success = true;
                $this->error   = false;
                break;
            }
            else
            {
                $this->success = false;
                $this->error   = true;
                break;
            }

 

I echo'd out the response from them like this: echo 'arb response ' . $arb->getResponse() . ' result code ' . $arb->getResultCode() . ' code ' . $arb->get_code();

 

and I get this:

 

arb response ith,cache-control,content-type,origin,method
Date: Wed, 04 Mar 2015 17:09:38 GMT

OkI00001Successful.23660616 result code ith,cache-control,content-type,origin,method
Date: Wed, 04 Mar 2015 17:09:38 GMT

<?xml version="1.0" encoding="utf-8"?><ARBCreateSubscriptionResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"><refId /><messages><resultCode>Ok</resultCode><message><code>I00001</code><text>Successful.</text></message></messages><subscriptionId>23660616</subscriptionId></ARBCreateSubscriptionResponse> code ith,cache-control,content-type,origin,method
Date: Wed, 04 Mar 2015 17:09:38 GMT

<?xml version="1.0" encoding="utf-8"?><ARBCreateSubscriptionResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"><refId /><messages><resultCode>Ok</resultCode><message><code>I00001</code><text>Successful.</text></message></messages><subscriptionId>23660616</subscriptionId></ARBCreateSubscriptionResponse>

 

If you notice the result code in the echo never happens and neither does the arb->getCode

 

I have already spoken to authnet tech support and they were no help whatsoever, client is anxious and I am literally stuck.

 

The odd part is I have the exact same code running on other sites and have no issue whatsoever AND this code (which has not changed) has been working fine for years.

 

I also can't help but notice the odd characters at the beginning of the response

 

Oh and just for clarity here are the two functions in AuthnetARB.class.php that handle the results:

 

    private function parseResults()
    {
        $this->resultCode = $this->parseXML('<resultCode>', '</resultCode>');
        $this->code       = $this->parseXML('<code>', '</code>');
        $this->text       = $this->parseXML('<text>', '</text>');
        $this->subscrId   = $this->parseXML('<subscriptionId>', '</subscriptionId>');
    }

    private function ParseXML($start, $end)
    {
        return preg_replace('|^.*?'.$start.'(.*?)'.$end.'.*?$|i', '$1', substr($this->response, 335));
    }

 

 


Accepted Solutions
Highlighted
Solution
Accepted by topic author dcdalton
‎08-21-2015 01:58 AM
Posts: 321
Topics: 5
Kudos: 36
Blog Posts: 5
Ideas: 0
Solutions: 26
Registered: ‎11-09-2011

Re: ARB response has changed, causing application to think it wasn't approved

@dcdalton I noticed your ARB response data has this string in it:

ith,cache-control,content-type,origin,method

 

That's coming from new HTTP headers we recently added.

Are you counting characters to figure out where HTTP headers end? Because that could lead to misparsing the HTTP data, effectively starting in the wrong place.

HTTP headers terminate with a carriage return/line feed (CRLF) on an otherwise blank line.

See this sample, taken from http://www.jmarshall.com/easy/http/#sample--and please note the blank line after the final header, Content-Length:

 

HTTP/1.0 200 OK
Date: Fri, 31 Dec 1999 23:59:59 GMT
Content-Type: text/html
Content-Length: 1354

<html>
<body>
<h1>Happy New Millennium!</h1>
(more file contents)
  .
  .
  .
</body>
</html>

 

Since all HTTP headers end with CRLF, what you really want to do here is to look for two CRLFs in a row--one to end the final HTTP header line, and one to terminate the header block entirely.

Once you do that, then you only need worry about the Byte Order Mark, as @RaynorC1emen7 already mentioned.

I hope this helps!

 

 

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

View solution in original post


All Replies
Highlighted
Expert
Posts: 4,525
Registered: ‎03-08-2010

Re: ARB response has changed, causing application to think it wasn't approved

Highlighted
Contributor
Posts: 11
Registered: ‎11-06-2011

Re: ARB response has changed, causing application to think it wasn't approved

I tried a st_replace, removing the byte code but that didn't change anything, still not working

 

 

Highlighted
Solution
Accepted by topic author dcdalton
‎08-21-2015 01:58 AM
Posts: 321
Topics: 5
Kudos: 36
Blog Posts: 5
Ideas: 0
Solutions: 26
Registered: ‎11-09-2011

Re: ARB response has changed, causing application to think it wasn't approved

@dcdalton I noticed your ARB response data has this string in it:

ith,cache-control,content-type,origin,method

 

That's coming from new HTTP headers we recently added.

Are you counting characters to figure out where HTTP headers end? Because that could lead to misparsing the HTTP data, effectively starting in the wrong place.

HTTP headers terminate with a carriage return/line feed (CRLF) on an otherwise blank line.

See this sample, taken from http://www.jmarshall.com/easy/http/#sample--and please note the blank line after the final header, Content-Length:

 

HTTP/1.0 200 OK
Date: Fri, 31 Dec 1999 23:59:59 GMT
Content-Type: text/html
Content-Length: 1354

<html>
<body>
<h1>Happy New Millennium!</h1>
(more file contents)
  .
  .
  .
</body>
</html>

 

Since all HTTP headers end with CRLF, what you really want to do here is to look for two CRLFs in a row--one to end the final HTTP header line, and one to terminate the header block entirely.

Once you do that, then you only need worry about the Byte Order Mark, as @RaynorC1emen7 already mentioned.

I hope this helps!

 

 

--
"Move fast and break things," out. "Move carefully and fix what you break," in.
Highlighted
Contributor
Posts: 11
Registered: ‎11-06-2011

Re: ARB response has changed, causing application to think it wasn't approved

Yes, the code I have been using all this time had a substr in parseXML function that started at character 335.

 

THANK YOU! Finally someone that knew what was going on, been asking and on the phone with tech support since yesterday

 

 

Highlighted
Contributor
Posts: 11
Registered: ‎11-06-2011

Re: ARB response has changed, causing application to think it wasn't approved

For anyone else using this older code and that might hit this problem, to save you the aggravation I just went through let me post what I did to make it work.

 

In the process function I added this after $this->response = curl_exec($ch);

 

            $start = strpos($this->response, "<?xml");

            $this->response = substr($this->response, $start);

 

Also I noticed the Ok in the resultCode field had whitespace on it so I added a trim to all the variable setting lines in the parseResults function, like this:

 

    private function parseResults()    {
        $this->resultCode = trim($this->parseXML('<resultCode>', '</resultCode>'));
        $this->code = trim($this->parseXML('<code>', '</code>'));
        $this->text = trim($this->parseXML('<text>', '</text>'));
        $this->subscrId = trim($this->parseXML('<subscriptionId>', '</subscriptionId>'));
        }

And now it runs flawlessly. Again hopefully we will have saved someone else from beating their head on the desk over this!