[not a bug] unwanted user switching in client area

[Remitur]

Hello.

 

I wrote a hook, which is called from some action in client area and which, in some circumstances, creates a new user with localAPI "addclient"

 

The code included in hook is as follows:

 

$values["firstname"] = "Registrant of domain";

$values["lastname"] = $domain;

$values["companyname"] = "";

$values["email"] = $registrantemail;

$values["address1"] = "na";

$values["city"] = "na";

$values["state"] = "na";

$values["postcode"] = "00000";

$values["country"] = "IT";

$values["phonenumber"] = "000000000";

$values["password2"] = "djhguyt5%fccgfQgtWer";

$values["currency"] = "1";

$values["noemail"] = true;

$values["skipvalidation"] = true;

$temporaryclient=false;

$rescli = localAPI("addclient", $values, $adminuser);

 

 

The issue is that, after this hook has been called and it has generated the new user, the user currently connected in client area il logged out and he find himself logged in as the new user, just created!

 

That's to say:

 

* user1@mydomain.com log in to his client area

* he made an operation which cause the call of my hook

* my hook create the new user user2@otherdomain.com

* user1@mydomain.com find himself logged out from his account and logged in as user2@otherdomain.com

 

WHMCS 6.3.1

PHP Version 5.6.17

Edited June 10, 2016 by Remitur

[WHMCS Zoey]

Hello:

 

The "AddClient" internal API function is working as intended.

 

The AddClient API was expected to run in the admin context; when run in an administrator context the login state of the client area is not changed. As such, we do not consider this to be a bug.

 

However, you need a solution for your issue. Our recommendations are to:

 

1) Use the External API, which will not change the authenticated user for the client area, or

2) Create contacts for the client (via the AddContact API method) instead of creating fresh clients

 

If the above options do not work, you could also try saving the contents of $_SESSION, running the API command, and then restoring the contents of $_SESSION, which should restore the authenticated user of the client area after running the api. While this should work, it is not recommended at all, as it involves both running an admin API function in the context of a client as well as touching the session directly. We can't guarantee the $_SESSION workaround will work forever, nor would we be able to provide any support if you used this method. I highly recommend going with one of the two options above instead.

 

If you have any further questions, please feel free to contact our support department.