The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

XML API Fatal errors

Discussion in 'cPanel Developers' started by Alan D., Jun 18, 2011.

  1. Alan D.

    Alan D. Member

    Joined:
    Nov 4, 2009
    Messages:
    6
    Likes Received:
    0
    Trophy Points:
    1
    I'm just wondering if this is a common result in failed calls to the server?


    Code:
        <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
     
  2. cPanelDavidN

    cPanelDavidN Integration Developer
    Staff Member

    Joined:
    Dec 17, 2009
    Messages:
    571
    Likes Received:
    1
    Trophy Points:
    18
    Location:
    Houston, TX
    cPanel Access Level:
    Root Administrator
    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
     
  3. Alan D.

    Alan D. Member

    Joined:
    Nov 4, 2009
    Messages:
    6
    Likes Received:
    0
    Trophy Points:
    1
    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]
     
  4. cPanelDavidN

    cPanelDavidN Integration Developer
    Staff Member

    Joined:
    Dec 17, 2009
    Messages:
    571
    Likes Received:
    1
    Trophy Points:
    18
    Location:
    Houston, TX
    cPanel Access Level:
    Root Administrator
    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
     
  5. Alan D.

    Alan D. Member

    Joined:
    Nov 4, 2009
    Messages:
    6
    Likes Received:
    0
    Trophy Points:
    1
    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):
    Code:
    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 =>  example@hotmail.com=example@error-interchanged-src-dest.com
    
    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.

    Code:
    <?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 :)
     
  6. Alan D.

    Alan D. Member

    Joined:
    Nov 4, 2009
    Messages:
    6
    Likes Received:
    0
    Trophy Points:
    1
    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.
     
Loading...

Share This Page