After update to SVN client_add is broken?

[zabersoft]

Hi,

I updated to the latest SVN to solve the old problem with sites_web_domain_add - But now my client_add function is no longer working. The user gets created, but none of the values I send in $params gets saved (i.e. user name company name etc. etc. are all empty)

These are the params I am sending, and how I call client_add:

$params = array( 'server_id' => 1,
'company_name' => $add_company,
'contact_name' => $add_fullname,
'username' => $add_username,
'password' => $add_password,
'language' =>'en',
'usertheme' =>'default',
'street' =>$add_address,
'zip' =>$add_zip,
'city' =>$add_city,
'state' =>'non-US',
'country' =>'DK',
'telephone' =>$add_phone,
'mobile' =>'',
'fax' =>'',
'email' =>$add_email,
'internet' =>'',
'icq' =>'',
'notes' =>'CVR Nummer:'.$add_cvr,
'template_master' => '1',
'template_additional' =>'',
'default_mailserver' =>'1',
'limit_maildomain' =>'1',
'limit_mailbox' =>'-1',
'limit_mailalias' =>'-1',
'limit_mailforward' =>'-1',
'limit_mailcatchall' =>'-1',
'limit_mailrouting' => '-1',
'limit_mailfilter' =>'-1',
'limit_fetchmail' =>'-1',
'limit_mailquota' =>'-1',
'limit_spamfilter_wblist' =>'-1',
'limit_spamfilter_user' =>'-1',
'limit_spamfilter_policy' =>'-1',
'default_webserver' =>'1',
'limit_web_domain' =>'-1',
'limit_web_quota'=>'-1',
'web_php_options' =>'mod',
'limit_web_aliasdomain' =>'-1',
'limit_web_subdomain' =>'-1',
'limit_ftp_user' =>'-1',
'limit_shell_user' =>'-1',
'ssh_chroot' =>'no',
'default_dnsserver' =>'1',
'limit_dns_zone' =>'-1',
'limit_dns_record' =>'-1',
'limit_client' =>'0',
'default_dbserver' =>'1',
'limit_database' =>'-1',
'limit_cron' =>'0',
'limit_cron_type' =>'',
'limit_cron_frequency' =>'-1',
'limit_traffic_quota' =>'-1');

$client_id = $client->client_add($session_id, $reseller_id, $params);

I've checked in client.tform.php to see if you have made any changes to the table definitions but I see no change from stock 3.0.2.2 - So I am thinking some underlying change was made that I need to be aware of - or that it is simply broken in the latest SVN - Any info on this would be cool

As usual - Thanks for all the great feedback!

[zabersoft]

And no - before you ask - my variables I am using to set the values in $params are not empty ;)

Update: Another thing - I checked out the remote users in the backend and saw that suddenly client functions and a few other things were unchecked for my remote user. So i enabled those and hit save - but the problem persists. I didn't suspect this in the first place as I remember the remote functions throwing errors if my remote user doesn't have the appropriate rights. So I don't think this is relevant - but I thought I might as well mention that I had checked this ...

[zabersoft]

Ok well I guess I need to start debugging the code - doesn't look like anyone has an easy answer. Where do you think I should start looking for the most likely suspect that would cause an insertion into the client table with null values?

I bet it's going to be something really simple.... ;)

[zabersoft]

Ok so this is what I have found so far ... It is certainly strange, and I can't quite tell how updating to the latest SVN would result in this weirdness - but this is what I am seeing:

A print_r($params) right before I call the SOAP function client_add like so:

$client_id = $client->client_add($session_id, $reseller_id, $params);

Looks all fine and dandy - that is, the array is filled out nicely.

I then assume that the parameters are sent directly to the client_add function in remoting.inc.php - However, a print_r($params) in this function, like so:

public function client_add($session_id, $reseller_id, $params)
{

error_log(print_r($params)); //my debug code

if (!$this->checkPerm($session_id, 'client_add'))
{
$this->server->fault('permission_denied','You do not have the permissions to access this function.');
return false;
}


$affected_rows = $this->klientadd('../client/form/client.tform.php',$reseller_id, $params);
return $affected_rows;

}


Results in it returning "1" - that is, a truncated array/messed up variable. Now my question is: Is anything happening before client_add? As far as I can see in the code the SOAP server is invoked and the remoting class is loaded - so logically speaking nothing should be happening to the $params array between my call to the function and the function executing. Please correct me if I am wrong here.

I just did a check and the $reseller_id and $session_id variables are passed through to client_add just fine.

Certainly strange, no?

[till]

Results in it returning "1" - that is, a truncated array/messed up variable. Now my question is: Is anything happening before client_add? As far as I can see in the code the SOAP server is invoked and the remoting class is loaded - so logically speaking nothing should be happening to the $params array between my call to the function and the function executing. Please correct me if I am wrong here.

Thats correct.

Anyone else has this problem with the current SVN version?

[zabersoft]

Ok so thinking logically about this:

1) My code worked perfectly before the SVN update
2) I did an SVN update using ispconfig_update.sh - reconfigured services
3) Suddenly my code stops working

- I then do the debug steps above which reveal that an array can no longer be passed through to client_add via. SOAP. Other variables go through fine.

So - my instincts tell me that something during the update process changed something in the way PHP handles SOAP requests. Does ISPConfig change PHP settings when services are reconfigured? I have started thinking in system fundamentals here - but I'm not sure where to begin to look ...

Update:
Just to confirm that the problem lies with passing an array to SOAP I tried adding a variable to the client_add function and passing a hardcoded string - like so:

$client_id = $client->client_add($session_id, $reseller_id, $params, "testing other var");

and client_add looks like so:


public function client_add($session_id, $reseller_id, $params, $testvar)
{
if (!$this->checkPerm($session_id, 'client_add'))
{
$this->server->fault('permission_denied','You do not have the permissions to access this function.');
return false;
}

error_log("In client_add testvar: ".$testvar." AND printr params ".print_r($params)." AND noprintr ".$params." AND session ".$session_id." AND reseller ".$reseller_id);

$affected_rows = $this->klientadd('../client/form/client.tform.php',$reseller_id, $params);
return $affected_rows;

}



this outputs the following in my php debug log:

[08-Sep-2010 13:40:27] In client_add testvar: testing other var AND printr params 1 AND noprintr Array AND session 37207531d0a1f7847b63dad2bad934a3 AND reseller 11

So you can see - Strings and integers go through fine - PHP sees $params as being an array, but a print_r just returns "1" - Which I personally have never seen happen before in any other context

[zabersoft]

Ok so now the plot thickens somewhat. I got bogged down in looking at my client_add function so I ignored trying to see if the other functions were working - so I just did a quick test where I call the defunct client_add function (which, as mentioned, fails filling in any DB fields) and then subsequently calling sites_web_domain_add - here $params seems to go through just fine!!

The DB for web domains looks just peachy. So the $params array is being picked up by ISPConf just fine.

This seriously confuses the heck out of me - because that now indicates that the problem is at my end. Something which I was sure I had ruled out.

:confused: :(

I guess I will go back to basics and make some stripped down test scripts - as I am using a pretty monolithic infrastructure right now that I've built over the last few weeks - that will maybe shed some light on the issue.

[zabersoft]

Alright - I've found the issue - this seems to be at least partially an ISPConf bug. Here's the rundown:

1) The reason I was seeing that strange output from my $params array in my debug attempts is simply due to the fact that the function error_log doesn't like print_r so it truncates the output. So in fact my array values were making it through just fine to client_add - and not being mangled by SOAP as I was thinking.

2) So now I traced how far $params survived - and of course what was happening was that this part of klientadd() was clearing the $params array:

//* load the client template
if(isset($params['template_master']) and $params['template_master'])
{
$template=$app->db->queryOneRecord("SELECT * FROM client_template WHERE template_id=".intval($params['template_master']));
$params=array_merge($params,$template);
}

So now my question is: Why is $params['template_master'] set while $template is empty? What is this template stuff? How do I clear this $params['template_master'] variable which is causing this code to run and emptying out my $params array?

Whew man... I'm very glad I finally tracked this down :)


Update: BTW As of PHP 4.3.0, there is an optional second parameter to the print_r function which is a boolean dictating whether the output from print_r is actually output (default) - which breaks error_log - or returned as a string.

The code can be therefore slightly altered to something more like:


$aArray = array('one', 'two', 'three', 'four');
error_log(print_r($aArray, true));

[till]

try to change:

if(isset($params['template_master']) and $params['template_master'])

to:

if(isset($params['template_master']) and $params['template_master'] > 0)

What is this template stuff?

See ISPConfig > Clients

[zabersoft]

Excellent - thanks for the feedback. I understand what client templates is all about now ;)

I implemented your tweak and it works.

[zabersoft]

Hi till,

I just thought I'd let you know that I gave you bad information. I thought I had implemented your fix as described above originally - but as I was setting up our system on a fresh server today I noticed that I had in fact not.

On a virgin fresh debian / ISPConfig 3 installation (SVN checkout) I see that you have added this fix to the SVN. However the problem is still present.

They way I had fixed it before, was commenting out the client template code entirely (the whole if(isset($params['template_master'] ... statement)

I thought I had applied your fix before - but something must have gone awry and I was still running with my old "hack"

So, FYI this is still not fixed in the SVN.