Method Community

I have run into an issue with the XML that is being returned by the API not being properly escaped. When I try and update a field using the MethodAPIUpdateV2 or MethodAPIInsertV2 calls, if a field is not valid, for instance, if it is to long, the API returns a message with the error. As an example I am trying to update my first name which is limited to 25 characters and this is the response I get back:

<?xml version="1.0" encoding="windows-1252" ?><MethodAPI response = "DanielDanielDanielDanielDaniel is too long for insertion (30 characters). The value must be 25 characters or less." ></MethodAPI>

This response is fine, the problem is, if the text I try to insert contains a < symbol, the XML is not properly escaping that value, which means the XML is invalid, and when I try to parse it I encounter an error. When The value I pass contains the < symbol, this is the response:

<?xml version="1.0" encoding="windows-1252" ?><MethodAPI response = "<DanielDanielDanielDanielDaniel is too long for insertion (31 characters). The value must be 25 characters or less." ></MethodAPI>

This is not valid XML, and when I try and parse it I get the error "simplexml_load_string(): Entity: line 1: parser error : Unescaped '&lt;' not allowed in attributes values "

Can you investigate this issue and let me know if you can update the XML response to properly escape the characters.

Hi dknoben,

I will create a ticket with the development team to investigate this further - however the likelihood of an immediate fix is slim based on the current priorities.  I'd like to better understand how you are using Method so I can relay this back to the development team (as we haven't had any complaints about this scenario recently).

• Is this just one specifc scenario, or do you have many data fields that contain special characters?  And if so, can you provide an example of the dataset?  
• Do you have these special characters in fields sync'ing over to QuickBooks?  

We are using the api to sync information from a web form that the customer fills out about themselves, back into method.  We first noticed this error when our QA tester tried to enter javascript into one of the fields.  We are now validating that no fields contain potential HTML or javascript tags, so we do not expect any users to be able to enter special characters, but they could try to put special characters in any of the felds on the front end.  We expose four fields that the user could fill out that would sync back to Quickbooks, firstName, lastName, Email, and Phone. 

Thanks for the insight dknoben 

I will report this bug to the dev team.  As mentioned above, I don't expect to see a fix to be implemented anytime in the near future as it appears to be a low impact bug.  I'm happy to hear that you have a work around in place at this time to prevent any special characters from making it to the database.  At this time, it appears that front end validation is the only work around available.  

Cheers

Jon

Hi Jon,

Can we get a status update on this? It turns out that this "low impact" bug is literally breaking our web application. We imported data from a legacy site and names with special characters are causing considerable issues.

We're at a loss for what to tell our international customers. They can't use the site because of your code. We're also extremely embarrassed that the names of our international customers are mangled beyond recognition. It seems incredibly disrespectful to those customers who's only mistake was to be born in a different country. 

Thank you,

Daniel 

Hi Daniel,

I understand your frustration.  We are actively working on additional support for special characters.  It isn't in this area but I'm going to try to expand the scope to include this.  I should be able to provide a further update in the next couple weeks.

Regards,

Peter