Remoting : Adding a site (ISPConfig + TheHostingTool Integration)

Discussion in 'Developers' Forum' started by jmontoya, Jun 14, 2010.

  1. jmontoya

    jmontoya ISPConfig Developer ISPConfig Developer

    Remoting : Adding a site (ISPConfig 3 + TheHostingTool Integration)

    So... I'm trying to integrate ISPConfig with thehostingtool (THT).

    I already did the user registration from THT to ISPCOnfig using the API.

    Now, I'm doing the registration of a site. I'm using this function:

    PHP:
    remoting::sites_web_domain_add()
    But the problem is that this function doesn't save the "document_root" field and all the "advanced" settings of the site. I check the file below (the site_web_domain_add() function is using that file to register their fields).

    PHP:
    interface/web/sites/form/web_domain.tform.php
    But I found that in that file there is a "if":
    PHP:
    if($_SESSION["s"]["user"]["typ"] == 'admin') {
     
    // code
    }
    So the question is: only admins can register that kind of information (document_root, system_user, system_user, etc )?

    I guess there are 2 possible solutions: Add a remoting user as a user (don't know if its possible) or to edit the condition to accept also remoting users?

    Or maybe I'm not using the correct function to add a site?

    What do you think?
     
    Last edited: Jun 14, 2010
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    Which ISPConfig version do you use?
     
  3. jmontoya

    jmontoya ISPConfig Developer ISPConfig Developer

    ISPConfig 3
     
  4. till

    till Super Moderator Staff Member ISPConfig Developer

    ISPConfig 3 is the name of the software. And whats the version?
     
  5. jmontoya

    jmontoya ISPConfig Developer ISPConfig Developer

    Latest version from SVN. Revision 1843.
     
  6. ivomendonca

    ivomendonca Banned

    1º Add a user(normal not remote) and save is id
    2º add a site using the user id

    a single remote user is all that you need.

    Adding a user and a site worked in 3.0.2.1
    Is not working now ?
     
    Last edited: Jun 15, 2010
  7. till

    till Super Moderator Staff Member ISPConfig Developer

    The problem occurs when you try to access settings that are reserved to the administrator user while using the ID of a normal client without this priveliges via the remote API. To force admin permissions to all remoting API operations,edit the file remoting_lib.inc.php line 169:

    $_SESSION["s"]["user"]["typ"] = $user['typ'];

    and change the line to:

    $_SESSION["s"]["user"]["typ"] = 'admin';

    I will change this in SVN.

    @ivomendonca:

    Adding the client with the remoting API works as well. No need to do this manually.

    This still works. But it can fail depending on the client ID.
     
  8. jmontoya

    jmontoya ISPConfig Developer ISPConfig Developer

    That will fix the problem great! :)
     
  9. holykim

    holykim New Member

    Hi All

    I had the same problem when I remotely created a web domain.

    Data recorded into the DB (web_domain table) but I can't find the advanced part such as system_user, system_group from the DB. I have changed the file remoting_lib.inc.php line 169 as Till recommended in the article at the above but I got another error.

    Error: documentroot_error_empty
    sysuser_error_empty
    sysgroup_error_empty
    allow_override_error_empty
    php_open_basedir_error_empty

    Can you please advise how to resolve this?

    //////////////////////////////////////////////////////////////////////////////////

    I have a second question related to remote access for using soap from the another server. I have got an error as below.

    Uncaught SoapFault exception: [HTTP] Could not connect to host in /var/www/vhosts/.....

    It worked with 3.0.2.1... I am not sure but I am guessing it came with the version 3.0.2.2 as I didn't change anything on my ISPConfig server. Can you please advise this also for me?

    Thanks in advance.

    Harry
     
  10. till

    till Super Moderator Staff Member ISPConfig Developer

    Set the values in the params array that you pass to the function.

    The error means that the soap script is unable to connect the the server. You should check the URL that you use in your soap client script and that you do not block the access with a firewall.
     
  11. holykim

    holykim New Member

    Thanks Till

    To set the values in the parameters, can you please tell me how to get the system_user starts with 'web'# ?


    The error means that the soap script is unable to connect the the server. You should check the URL that you use in your soap client script and that you do not block the access with a firewall.

    The URL is Ok. firewall means 8080 port that ispconfig uses?

    Cheers
    Harry
     
  12. till

    till Super Moderator Staff Member ISPConfig Developer

    Yure right, we have to set this in the API function on insert as the remote client can not know the correct value. Please file a bugreport for this so we can try to gtet it patched before the 3.0.3 release.

    Yes. Try to fetch the URL on the shell e.g. with lynx to see if it works.
     
  13. jmontoya

    jmontoya ISPConfig Developer ISPConfig Developer

    One question til::

    when I use the sites_web_domain_add remoting function

    the tform_actions:: onInsert function is not loaded. is this a bug?

    What should I do? Create a new function to do the job of the onInsert, or fixing the tform_actions class to load all onInsert, onLoad, onUpdate, etc functions?
     
    Last edited: Aug 2, 2010
  14. till

    till Super Moderator Staff Member ISPConfig Developer

    This is a known problem with the remoting functions. The remoting framework is not able to load the event functions at the moment. The ideal solution would be to load the onAfter* Evenet functions also on remoting calls (most of the other events are only useful for interface forms). But I'am not sure if there is a elegant way to do this. If not, then add the missing code to set the user, group and path to the sites_web_domain_add function in the remoting framework file.
     
  15. till

    till Super Moderator Staff Member ISPConfig Developer

    Just one addition. If it is not possible to load the event functions from the form file into the remoting framework, then there is one other alternative. There is a relatively new plugin based interface which is used currently only for the email filter function which works for the normal API and the remoting API. You find the only event based interface plugin in interface/lib/plugins/ directory. This event based system allows every plugin to bin itself to any event of any form in the interface. So the alternative can be to remove all event based code that has to be executed by the remoting framework as well form the "normal" event based interface forms to such a plugin. The plugins are loaded dynamically when a user logs into the interface, so if you want to test it with anew plugin, relogin to load the plugin.
     
  16. xaver

    xaver New Member

    Hi,

    i tryed a sites web domain add too.
    My problem was always i get the userid from the Root path back after i setup a user.
    And i had to update the Rootpath again. I tried a maker like [web_id] but i had no luck.

    Right now i build a new Function witch return the next webnumber and add the user.

    But maybe a example for adding a web domain would be great.

    THX
     
  17. till

    till Super Moderator Staff Member ISPConfig Developer

    We have to add some modifications to the remoting API as explained above to solve this.
     
  18. jmontoya

    jmontoya ISPConfig Developer ISPConfig Developer

    Ok. I did what you suggest: I create a new plugin like the mail_user_filter_plugin. It works fine, BUT... when I create a site, the ln -s is executed and I have something like this.

    www.test36.com -> /var/www/clients/client[client_id]/web[website_id]/

    Then the plugin updates the values in the database so I have something like this
    /var/www/clients/client45/web40/web.

    I know that the id 40 (in this example) is the domain_id so it must be insert first and then update the table. But the ln -s is "faster".
    Any suggestions?

    PHP:
        public function sites_web_domain_add($session_id$client_id$params)    {
                    global 
    $app;
                    if(!
    $this->checkPerm($session_id'sites_web_domain_add')) {
                            
    $this->server->fault('permission_denied''You do not have the permissions to access this function.');
                            return 
    false;
                    }
                    
    $affected_rows =  $this->insertQuery('../sites/form/web_domain.tform.php',$client_id,$params);
                    
    $app->plugin->raiseEvent('web_domain:web_domain:on_after_insert',$this);
                    return 
    $affected_rows;
            }

     
  19. till

    till Super Moderator Staff Member ISPConfig Developer

    I will see how we can solve that.
     
  20. till

    till Super Moderator Staff Member ISPConfig Developer

    I've submitted a small patch to SVN. Please try if it solves the problem.

    The main problem was that in tform_actions, the on_after_update event was rised before the datalog gets written wile we rised the evnt in the remoting frameowrk after the datalog was written. I've changed the remoting file now and added a parameter for the event_identifier to the insertQuery and updateQuery functions, so that the event gets rised now before the datalog got written, so everything that you modify now in the database for the current record gets included into the change for this record befor it gets executes on the server.

    Your example above should look now like this:

    Code:
    $affected_rows =  $this->insertQuery('../sites/form/web_domain.tform.php',$client_id,$params,'sites:web_domain:on_after_insert')
    
    The $app->plugin->raiseEvent line should be removed then.

    The event identifier is composed of the module name, the form name and then the event, so it should be:

    Code:
    sites:web_domain:on_after_insert
     
    Last edited: Aug 3, 2010

Share This Page