search

upmind-automation / provision-provider-domain-names

This provision category contains common functions used in domain name provisioning flows with various registries and registrar/reseller platforms
GNU General Public License v3.0
4 stars 6 forks source link

Issues with the Namesilo Integration #83

Open mendozal opened 6 months ago

mendozal commented 6 months ago

Hi.

I noticed a couple of issues with the Namesilo Module:

  1. I noticed that registrant information retrieved from the module comes as HTML entities, for example, here's the response from the module:

"city": "Asunción", This should be "Asunción" in the UI, but is showing as "Asunción" Namesilo is showing correctly in their page.

Maybe this is something that should be managed by the UI, if so please let me know and I will open a Ticket in Upmind.

  1. When you set the registrant information from Upmind, the phone number is going without the country code. Please consider sending the full number for accuracy purposes.

Thanks.

mendozal commented 6 months ago

Maybe this is something new, because previous domains's contact information is completely stripped of special characters.

uphlewis commented 6 months ago

Im not sure the formatting came out correctly in your issue description. Could you raise a support ticket so we can check the provision logs in question?

uphlewis commented 6 months ago

As far as I can tell this looks like a bug on Namesilo's end. We create contacts by sending a payload using GET query parameters (unfortunately this is what their API requires), so these are url-encoded to be valid for a HTTP GET request (which means Asunción becomes Asunci%C3%B3n). In their responses, they appear to be double-escaping these for their XML responses, so we get back <city>Asunci&amp;oacute;n</city>. When parsing the XML on our side this becomes Asunci&oacute;n because they are double-encoding the ampersand in the HTML entity for ó (which is &oacute;) which results in the &amp;oacute; which they are returning.

The reason the state returns back ok is because we map the requested state name to a state code, so in our API request we are sending and getting back ASU which we map back to Asunción in our provision result.

I'm hesitant to try and "double-decode" their API response values as this may introduce other issues, so this is something they should investigate on their end.