WHM Interface class

[kubel]

I am having trouble with a custom class I am writing to interface with WHM to create/delete accounts (among other things). I am experiencing a very awkward problem, thought. First, here is the code from the class:

PHP Code:

function CreateAccount($domain, $email, $pass, $package, $user)  {
                $package = $this->User . '_' . $package;
                
                $request =     '/xml-api/createacct?username=' . $user . '&plan=' . $package
                            . '&password=' . $pass . '&contactemail=' . $email . '&domain=' . $domain;
                $result = $this->Request($request);                
                
                if (!$result)
                    trigger_error('An error occured in the create account request. WHM returned a blank result.', E_USER_ERROR);
                
                if (preg_match('#<status>1</status>#', $result) < 1)  {
                    preg_match('#<statusmsg>(.*?)</statusmsg>#s', $result, $matches);
                    
                    trigger_error(    'An error occured while creating this cPanel account (domain : user):<br /><br />' . $domain
                                    . ' <strong>:</strong> ' . $user    . '<br /><br />' . $matches[1], E_USER_ERROR);
                }
                
                return true;
            }
            
            function DeleteAccount($user)  {
                $request =     '/xml-api/removeacct?user=' . $user;
                $result = $this->Request($request);                
                
                if (!$result)
                    trigger_error('An error occured in the delete account request. WHM returned a blank result.', E_USER_ERROR);
                
                if (preg_match('#<status>1</status>#', $result) < 1)  {
                    preg_match('#<statusmsg>(.*?)</statusmsg>#s', $result, $matches);
                    
                    trigger_error(    'An error occured while deleting this cPanel user: ' . $user
                                    . '<br /><br />' . $matches[1], E_USER_ERROR);
                }
                
                return true;
            }
        
            function Request($RequestedURL)  {
                $response = file_get_contents($this->URL . $RequestedURL);
                
                if (empty($response))
                    return false;
                else
                    return $response;
            } 


Next, here is my test file. It has two calls, one to create and one to delete. I just comment out (or terminate with die) the one I don't want when testing. However, I usually create an account via this class and then call for it to delete.

PHP Code:

require('/home/minihost/public_html/include/class/cPanelInterface.class.inc.php');
    $cPanel = new cPanelInterface('minihost');
    header('Content-type: text/plain');
    error_reporting(E_ALL);
    
    var_dump($cPanel->DeleteAccount('w00t'));
    die;
    
    var_dump($cPanel->CreateAccount('w00t.minihost.org', 'test@minihost.org', 'test', 'MH-S1', 'w00t')); 


The problem arises when I call the delete function. The account will exist in WHM (with a username of 'w00t') but when I call the delete function, it takes a little bit to process the request and then it will give me the white screen of death almost like it timed out. But when I view source on that page, it shows the error message (just a var_dump() of the WHM result) in the source but not in the page itself even though I sent a text/plain content-type header.

The message is just WHM's message that the username 'w00t' does not exists. However, WHM did actually delete the account. So basically, it did what it was supposed to do all the way up until it was supposed to return a success message. Instead, it returns a failure, which causes my class to return a failure. It is almost like 1 of 2 things: 1) WHM does the request twice and just says nothing about the first request causing the second to be valid because there would be no 'w00t' user or 2) WHM is doing the delete but is simply returning the wrong message. But when I call the delete URL from my browser (since PHP is only doing HTTP requests anyway), WHM outputs the correct message in saying the account is deleted.

It's important to keep note also that the white screen of death thing only happens when the account actually exists and it tries to legitimately delete the account (and does). If the account is not really there, it doesnt have a problem sending a legit failure message (as designed).

Now, since the white screen of death thing was fishy (at least the fact that the source view had the error in it and the browser window did not), I thought maybe the browser was receiving awkward headers that was causing it to crap out, so I used a header viewer application. You can view the results of the delete call headers here:

http://minihost.org/test.php

GET /test.php HTTP/1.1
Host: minihost.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.x 200 OK
----------------------------------------------------------

Now when I call the test.php file after the delete has already concluded (but still sent white screen of death), the header output is:

http://minihost.org/test.php

GET /test.php HTTP/1.1
Host: minihost.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.x 200 OK
Date: Sun, 26 Aug 2007 21:20:07 GMT
Server: Apache/1.3.37 (Unix) PHP/5.2.3 mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 FrontPage/5.0.2.2635.SR1.2 mod_ssl/2.8.28 OpenSSL/0.9.7a
X-Powered-By: PHP/5.2.3
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/plain
X-Antivirus: avast! 4
X-Antivirus-Status: Clean
----------------------------------------------------------

Now, I am no expert at web technologies period. So if the header stuff means nothing, sorry. I just found it odd how different they were, especially considering only in the last delete call (the one where the account didnt actually exist) did the headers even say Content-type: text/plain. I specifically set that in my test.php file with a header() function for it. I am sorry if this is really confusing, now you know how I feel. It is so awkward of a problem. I am completely dumbfounded. Any assistance would be great. I know it would be better to work with a real example but that isnt very practical for me to do with a whole board looking at it. If you need further information, please let me know.

[cPanelDavidG]

That's a very convoluted way of doing things that are supported by APIs. You may want to use the XML-API for these tasks:

http://www.cpanel.net/plugins/xmlapi/index.html

Additionally, since the means by which you are interacting with WHM is not a supported means by which third parties should interact with cPanel/WHM, things may change without notice resulting in a broken script. You can avert such an issue by using our APIs in situations where API support is available for tasks you wish to accomplish.

[kubel]

The XML API is an entirely different issue. I tried using the cpanel::accounting class with the same results. That is how I derived my code. Is cpanel::accounting not supported?

[cPanelDavidG]

Originally Posted by kubel

The XML API is an entirely different issue. I tried using the cpanel::accounting class with the same results. That is how I derived my code. Is cpanel::accounting not supported?

At this time cpanel::accounting (also known as the WHM API) is still supported, it's just an older more inflexible (in terms of availability of varied functionality) way of doing things.

[kubel]

I took your advice and started using the XML API. I still have the same problem. I updated my code in the original post to reflect that. Can you please tell me what is wrong with it?

[cPanelDavidG]

Originally Posted by kubel

I took your advice and started using the XML API. I still have the same problem. I updated my code in the original post to reflect that. Can you please tell me what is wrong with it?

In your Request function, I don't see you authenticating with either using a user/Remote Access Key or user/pass combination. Note, if you intend to use remote access keys, you would be better off using sockets rather than file_get_contents so you can actually pass that authentication information via the HTTP request header (which is different from the HTTP headers you are outputting using header()). If you are making this script for general use, you might want to be aware of the option to disable URL access from file functions - another reason to use sockets.

Also, I am uncertain what the value of $this->URL is given your code, it should be either "http://IP:2086" or "https://IP:2087." where IP is your server's IP or even a hostname if you really wanted to do that, but IP would be less likely to need modification/maintenance.

Sample code using hash authentication:
http://forums.cpanel.net/showpost.ph...38&postcount=6

Thread regarding what to do if you experience timeout issues with fsockopen() with the API:
Connection timed out when using xml-api

[kubel]

I just simply did not include the constructor for my class in my original post because I didn't think it was relevant. Here it is below.

PHP Code:

function cPanelInterface()  {
            require_once('/home/minihost/cPanelSetup.inc.php');
            
            $this->URL =     'http://' . $this->User . ':' . $this->Password . '@' . $this->Domain . ':' . $this->Port;
        } 


cPanelSetup.inc.php gives all the values and constructs them into the following string:

http://minihost:mypassword@minihost.org:2086

That is the $this->URL. It will just take that value and append the xml-api call. Is that incorrect?

[cPanelDavidG]

Originally Posted by kubel

I just simply did not include the constructor for my class in my original post because I didn't think it was relevant. Here it is below.

PHP Code:

function cPanelInterface()  {
            require_once('/home/minihost/cPanelSetup.inc.php');
            
            $this->URL =     'http://' . $this->User . ':' . $this->Password . '@' . $this->Domain . ':' . $this->Port;
        } 


cPanelSetup.inc.php gives all the values and constructs them into the following string:

http://minihost:mypassword@minihost.org:2086

That is the $this->URL. It will just take that value and append the xml-api call. Is that incorrect?

Ensure that you can open URLs from file IO functions. This functionality can be disabled in php.ini (allow_url_fopen).

I don't want to cross the line into discussing PHP code itself rather than how to get your PHP code to work with cPanel/WHM. However, I would recommend you put in some debugging code to ensure that you are calling the URL you think you are calling.

I cannot think of anything relating to the API off-hand that would result in a blank page. However, many things that could go unnoticed in PHP code can cause a variable to be blank when it should contain data.

(Likely to be) Common Errors:

Note that if you attempt to do http://...:2087, you will get an Internal Server Error saying (among other things) "Please Speak SSL on this port" as port 2087 is dedicated to https:// connections to cpservd.

If you call an API function that doesn't exist, you'd at least get an HTML comment with a copyright notice in the body.

If you called the server with incorrect login credentials, you'd get a login page returned in the body.

If you call a file that doesn't exist (e.g. /xmlapi instead of /xml-api), you will get a 404 Not Found error (with accompanying body text)

[kubel]

As I said in my original post, WHM actually does do what I ask it to do. Therefore, it is not authentication, not wrong URLs, and its not URL settings in my .ini. The request I sent works but it returns a blank page to firefox. It only does this when I request to delete a legitimate user. It deletes the user but returns an error (found in the source view of firefox cause firefox displays a white screen of death) saying that the user X does not exist on the server. And just for the heck of it, I used your method (exactly...ssl and all) of using sockets to call the request (per the post you made and linked me to), and it still does the same thing.

As I originally said as well, it is odd that the headers returned when it errors are incomplete. When I call the URL that is generated by the script in my browser, it works fine as intended. This is why I am so confused.

If it were a simple PHP error, I would catch that. But this is acting unexpectedly. I think it is a problem with the way WHM is responding to my request or PHP itself. Obviously it is not a problem for other WHM users but I am trying to figure out why it is for me. Any other ideas? IIf you want me to post the new request code using your method I can, but it is the same as how you instructed and the same error produced.

[cPanelDavidG]

Keep in mind, the XML-API is designed for use by scripts, not end-users using web browsers. As a result, never rely on the output the browser provides - always view the source code of the page and proceed from there.

[kubel]

So what should I do, I have done all the techniques and methods that cpanel supports/recommends and it is still doing this. Is there any solution?

[cPanelDavidG]

Originally Posted by kubel

So what should I do, I have done all the techniques and methods that cpanel supports/recommends and it is still doing this. Is there any solution?

Is the problem that no data is being returned or merely that your web browser is not displaying output and you must view the source code to see the output from the API?

[kubel]

The latter. I believe WHM is returning awkward headers (or PHP or Apache or something) and Firefox gets confused. See my header test in the original post.

Well, I just bought an account on another server just because I was getting no where...and my code miraculously works now on that server...perfectly. So obviously it is something with my WHM. Are their any settings that would cause this?

[kubel]

Well, for anyone experiencing this problem, the solution is this: your WHM installation sucks and you need to reinstall. Apparently something had either corrupted itself or mis-set itself and caused everything to stop working. But my code seems to work just spiffy. Hope that helps.

[NexGenUK]

kubel - its more than likely PHP thats causing the issue actually - 5.2.3 although advertised as stable we have had 20-30 dedicated customers have to have their php downgraded to 5.2.0 because of various segmentation faults that occur; Plus you are better off using the fsockopen / curl approach due to various issues such as this (you can debug alot more information this way). However glad to hear you got it working...