[BlueOnyx:14277] Re: API, am I doing this right?

Chris Gebhardt - VIRTBIZ Internet cobaltfacts at virtbiz.com
Mon Jan 20 14:23:48 -05 2014


Thanks Michael,

On 1/20/2014 1:00 PM, Michael Stauber wrote:
> Hmm ... should be right. Please check under "Setup" /
> "Products/Services" / "Server".
> It shows the servers that you have configured and there is also the
> button "Login to Control Panel" and the "AM-Status" next to it.
>
> AM-Status should report "OK". Check if you can login to the GUI using
> the button there. If not, the password might be wrong, as it just
> happened with my own WHMCS test-rig.


AM-Status: OK
Login to Control Panel works fine.

>> I have not modified anything at the WHMCS end in some time (not since
>> installing the BlueOnyx module), so I'm unsure why it has stopped working.
>
> On my end my WHMCS box didn't check at all. The target box where I run
> the test account is a 5108R that's running the YUM updates out of the
> "testing" YUM repository. But the BlueOnyx side of the API didn't change
> in between. I just updated the localization files, but not the actual
> PHP page that WHMCS posts the data to.
>
>> In addition, the other module tasks appear to have stopped working as
>> well.   ie: Suspend, Unsuspend, Change Password, etc.
>
> The error message you get is created by this file:
>
> /usr/sausalito/ui/web/base/api/index.php
>
> See line 139ff:
>
> if (($_POST['action'] == "create") && ($payload->producttype !=
> "hostingaccount")) {
>    echo "BlueOnyx API: At this time only producttype 'hostingaccount' is
> supported.";
>    error_log("BlueOnyx API: At this time only producttype
> 'hostingaccount' is supported.");
>    // nice people say aufwiedersehen
>    $helper->destructor();
>    exit;
> }
>
> It is triggered past the authentication stage (line 61-69), so at that
> point we have a valid username (admin) and the correct password. We also
> have a POST request and the POST payload contains the action "create".
>
> However, the JSON encoded payload doesn't have the right producttype.
>
> Do this for debugging:
>
> In line 138 (above the section of code I posted above) add this:
>
> error_log("Payload: " . $payload->producttype);
>
> Then tail /var/log/admserv/adm_error while you do another create
> transaction. It should log what producttype WHMCS is posting to the API.

Alright, I've done that and now we are onto something interesting. 
Well, for me, at least.   I went to a test account in WHMCS and then 
created a new site on the same production server.   It created just 
fine, and left the following output in /var/log/admserv/adm_error:

[Mon Jan 20 13:11:18 2014] [error] [client 208.77.0.0] BlueOnyx API: 
Access from 208.77.0.0to port 81
[Mon Jan 20 13:11:18 2014] [error] [client 208.77.0.0] Payload: 
hostingaccount

So it likes the producttype there.

I then went back to the domain that we had encountered the error on 
previously, and it failed with the same symptom and:
[Mon Jan 20 13:17:03 2014] [error] [client 208.77.0.0] BlueOnyx API: 
Access from 208.77.0.0 to port 81
[Mon Jan 20 13:17:03 2014] [error] [client 208.77.0.0] Payload:

AH, no producttype!   But I wonder why this is, since both of the 
hosting accounts in WHMCS are configured as the same product.   So there 
can be no difference there.

I will do a little more inspection to see if there is something I can 
learn.   It is difficult for me to "blame" one component right now, 
since the symptoms don't reproduce in each case.

But first... it's time to move a piano.   Talk about some "heavy 
lifting".   Ah, the things we do for family!
-- 
Chris Gebhardt
VIRTBIZ Internet Services
Access, Web Hosting, Colocation, Dedicated
www.virtbiz.com | toll-free (866) 4 VIRTBIZ



More information about the Blueonyx mailing list