Xero - beautiful accounting software

Xero Developer Help Center

Xero Developer Community

Community > API Authentication >

Adding SummarizeErrors=false to the Invoices API URL gives me a signature_invalid error

Started by Mark Solly -   in API Authentication

I've tried sending this variable by appending it to the URL and also by adding it as a POST variable but either way seems to break oauth at Xeros end.

From what I can tell the Xero API is not including the SummarizeErrors variable when it is verifying the oauth signature?

This is a private, permanently authorized application so I'm using RSA_SHA1 as the signature method. I'm wondering if that has something to do with it?
Hi Mark,

I've looked into this issue and have traced the problem to the OAuth library that we're using on api.xero.com. This library isn't correctly validating oauth signatures when querystring parameters start with uppercase letters.

A quick search revealed that I'm not the first person to be tripped up on this issue: http://stackoverflow.com/questions/839429/oauth-lexicographical-byte-value-ordering-in-c.

I've written a fix which will be deployed in the next major release of API, but in the meantime, you can get around the problem by using the parameter summarizeErrors rather than SummarizeErrors (note the capitilization on the first letter).

Dan..
 

Dan Barratt (Xero Staff)  

Thank you for your response Dan. Glad to know I wasn't losing my mind there...

Can you also update the API documentation at http://blog.xero.com/developer/api/Invoices/ so that no one else gets caught by this bug? It specifies the parameters with the first letter capitalized (which is why I was caught out. I always assume these things are case sensitive and copy/paste verbatim).
 

Mark Solly  

After further testing I've found that changing the URL parameter to summarizeErrors does not help. I still receive a signature_invalid error.

However, I did find that leaving the URL unchanged and including "summarizeErrors=false" as an HTTP POST parameter gets around the problem.

Could it be we both have a bug in our OAuth libraries or is the API documentation incorrect?
 

Mark Solly  

Is this an issue that has started recently? I myself have been using the OAuth library provided by xero (Advanced version). I was able to PUT Invoices to my account before, but have recently started receiving error 14 returned (Invalid Root Element).

Does the issue with summarizeErrors starting with a capital apply to me or I have I misunderstood this post?

here is exactly what my error states:
<ErrorNumber>14</ErrorNumber>
<Type>PostDataInvalidException</Type>
<Message>Xml for post data was invalid, Root element is missing.</Message>
 

Fred Johnson  

Hi Mark,

As it turns out, the Xero API uses the same OAuth library that we publish on github. If you use this library, you won't have the same problem with summarizeErrors that developers on other platforms have. The method of signature generation is technically incorrect on both sides. To ensure that you're not falling fowl of this issue, always pass in querystring parameters names in lowercase.

As for the "Xml for post data was invalid" error you're getting, this is a separate problem. The error message indicates that the http body you're posting can't be understood as valid xml by the API server. I suggest that you download an http proxy (e.g. www.fiddler2.com) and capture the http request and response messages from you application to the Xero API. Compare the results with the samples on http://blog.xero.com/developer/api-overview/http-put-and-post/. If you're still stuck, email us at network@xero.com.
 

Dan Barratt (Xero Staff)  

I'm hitting the same problem using the PHP-xero class and have been working to hack around it to ease my validation of multiple invoice submission. I've tried including it as part of the POST request, but that doesn't seem to affect the data that is returned. Including it in the URL (either upper or lowercase) blows up OAuth as others have found. Urlencoding the parameter results in "A potentially dangerous Request.Path value was detected from the client (?)."

Any chance of an update as to when this will be patched?
 

Tony Dodd  

@Dan Barrett can you explain exactly how "the method of signature generation is technically incorrect on both sides"? We're using a Clojure OAuth library. When we use GET requests we have no problems but POST requests are being rejected with signature_invalid. If we know how your signature method is non-standard we might be able to fix our library to make it compatible.

Cheers, Dan Dukeson

 

Dan Dukeson