|
|||
|
WHM Interface class
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:
PHP Code:
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. Last edited by kubel; 09-03-2007 at 05:57 PM. Reason: updated code |
|
||||
|
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.
__________________
Need technical assistance? You can find your best avenue for support at: http://support.cPanel.net -- cPanel David G., Lead Forum Administrator & cPanel Technical Sales Representative |
|
||||
|
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.
__________________
Need technical assistance? You can find your best avenue for support at: http://support.cPanel.net -- cPanel David G., Lead Forum Administrator & cPanel Technical Sales Representative |
|
||||
|
Quote:
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
__________________
Need technical assistance? You can find your best avenue for support at: http://support.cPanel.net -- cPanel David G., Lead Forum Administrator & cPanel Technical Sales Representative |
|
|||
|
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:
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? |
|
||||
|
Quote:
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)
__________________
Need technical assistance? You can find your best avenue for support at: http://support.cPanel.net -- cPanel David G., Lead Forum Administrator & cPanel Technical Sales Representative |
|
|||
|
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. |
|
||||
|
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.
__________________
Need technical assistance? You can find your best avenue for support at: http://support.cPanel.net -- cPanel David G., Lead Forum Administrator & cPanel Technical Sales Representative |
|
||||
|
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?
__________________
Need technical assistance? You can find your best avenue for support at: http://support.cPanel.net -- cPanel David G., Lead Forum Administrator & cPanel Technical Sales Representative |
|
|||
|
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? |
|
|||
|
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.
|
|
|||
|
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...
|
![]() |
| Thread Tools | |
| Display Modes | |
|
|