XML API Fatal errors

[Alan D.]

I'm just wondering if this is a common result in failed calls to the server?

    <font color="#FF0000">Fatal!
 /etc/valiases/demo-test.fake.domain.com. Ignore any messages of success. This can only result in failure!</font>
<br />
....and the xml success message below!

It was a Email::addforward call that works fine for valid domains. But do all calls to the xml api framework fail in a similar fashion?

Alan

 

[cPanelDavidN]

Hi Alan,

The XML-API native functions (here) will be straight forward. You don't need to parse a "statusmsg" to know if you can trust the "status".

cPanel APIs are a little different:

API2 cPanel calls made via the XML-API can mostly be trusted. Typically if a call fails, it will set a contextual error that is recognized by the XML-API engine, which in turn sets an 'error' in the XML response structure. Some calls will set their own "status" or "result" node within their dataset (the "result" or "data" node).

API1 is like API2, but it will not set the contextual error internally, and therefore you're dependent on the call returning something useful in it's dataset...which for some functions can be difficult. API1 calls where (mostly) designed for frontend use and simply return strings (or HTML). The XML-API engine can't do much with that...Additionally, API1 calls often print directly to STDOUT, which can not be trapped effectively and shoved into an XML response. The result is that API1 calls often send mal-formed XML and we highly encourage people to not use API1 if there is an API2 alternative (and to create a feature request or submit a ticket when they encounter such issues).

I'm curious as to how you are making your call and the full response output of your call. Please post or PM me (feel free to hash-out your private data).

Best Regards,
-DavidN

 

[Alan D.]

The calls are from a massively modified xml-api class, running remotely and calling using file streams. I'm refactoring the class into sub-classes and using these for a Drupal module. The request works perfectly fine for valid user domains, but with an invalid domain, it produced the 3 lines of text and the exact same success xml string (approx. 15 lines of valid xml).

I'm in the very early stages of programming the module, so this was only the second method tested and was surprised by the response. The other tests all passed, like resending the same forwarder twice, etc.

I'm testing on a server with WHM 11.28.87 / cPanel Pro 1.0 (RC1), connecting via whm port 2087.

[edit: The domain was an invalid sub-domain of an existing domain from the server: fake.example.com where example.com is hosted]

 

[cPanelDavidN]

But are you making the call as an API1 or API2? If you are making it as an API1, then don't be surprised that HMTL is returned or that in makes the XML invalid; regardless of failure or success. If you calling this as an API2 function, and you're getting mal-formed XML then it's probably a bug. Please provide more detail about the query URL that you are sending.

-DavidN

 

[Alan D.]

I guess this is a GIGO issue, but I also hit it just now using delForwarder(), which according to the docs, has only an API1 call.

An example POST request is (interchanging the source and destination parameters):

URL:
    https://server.com:2087/xml-api/cpanel
Arguments:
    user =>  demo
    cpanel_xmlapi_module => Email
    cpanel_xmlapi_func => delforward
    cpanel_xmlapi_apiversion =>    1
    arg-0 =>  [email protected][email protected]

Which also tries a invalid write (/etc/valiases/hotmail.com) and echos out the debugging text into the middle of the otherwise nicely formed text.

<?xml version="1.0" ?>
<cpanelresult><module>Email</module><func>delforward</func><type>event</type><source>internal</source><apiversion>1</apiversion><data><result>&lt;br /&gt;
&lt;font color=&quot;#FF0000&quot;&gt;Fatal!
Write Failure: /etc/valiases/hotmail.com. Ignore any messages of success. This can only result in failure!&lt;/font&gt;
&lt;br /&gt;
</result></data>  <event>
    <result>1</result>
  </event>
</cpanelresult>

I think the html section may have been escaped on the cpanel side, as I am only escaping it once and this was the screen dump.

So I think that there is an HTML debugging catch within the script that handles writing to the valiases file write, and this output is captured and sent back to the client. Maybe it could be possible to make this script to write to another stream out and test this stream for errors... I have no idea of the internals of cPanel

Anyway, it is an easy grep for #ff0000

 

[Alan D.]

I posted a detailed report, but it seems to have been lost in the moderation queue. Long story short, try either a v1 or v2 call with an invalid domain, for example reverse the src/dest add or delete forwarder actions and you should see it.