Marcel Töpel
shared this idea
4 years ago
8
Votes
Login to Vote
WHMCS currently doesn't expose any Plesk related info on either server credentials or the subscription ID, which makes the automation of Plesk API methods very hard and some even impossible. I would like to propose two ideas to make the automation of Plesk servers more convinient when using an automation server that is outside of WHMCS.
1. Expose a field like "externalid" for a WHMCS subscription, that stores the Plesk subscription/site ID.
Right now there is no such field exposed in any WHMCS API endpoint (like "GetClientsProducts"). This makes all Plesk API calls that need the site ID impossible to call from an automatic process, as Plesk itself doesn't give the site ID for a known domain name (which is also not failproof). I don't know about cPanel, but this seems like it should be available with all server modules, so we can automate the corresponding APIs for a known WHMCS subscription.
2. Make Plesk API calls possible from the WHMCS API
Variant A: Expose the Plesk Module API credentials from the server configuration panel in the "GetServers" endpoint.
As of now there is no way of getting the allready defined API credentials that WHMCS uses to create a subscription in Plesk. This in turn means that we must configure those in another environment with some relation ID (like WHMCS server ID). "GetServers" should provide that information. If exposing credentials is to risky, if have another idea:
Variant B: Expose a pass through method to call Plesk API methods from the WHMCS API.
As a variant for the previous idea an endpoint could be added that passes data to the Plesk API and sets the credentials by itself. Desireably you would provide the server ID and a data package for the target API (plesk in this case). WHMCS would then construct an internal call to the target API and set the allready defined API credentials. This would be alot harder to develop than variant A, but more secure as credentials are not populated over an endpoint.
Let me know what you think.
1. Expose a field like "externalid" for a WHMCS subscription, that stores the Plesk subscription/site ID.
Right now there is no such field exposed in any WHMCS API endpoint (like "GetClientsProducts"). This makes all Plesk API calls that need the site ID impossible to call from an automatic process, as Plesk itself doesn't give the site ID for a known domain name (which is also not failproof). I don't know about cPanel, but this seems like it should be available with all server modules, so we can automate the corresponding APIs for a known WHMCS subscription.
2. Make Plesk API calls possible from the WHMCS API
Variant A: Expose the Plesk Module API credentials from the server configuration panel in the "GetServers" endpoint.
As of now there is no way of getting the allready defined API credentials that WHMCS uses to create a subscription in Plesk. This in turn means that we must configure those in another environment with some relation ID (like WHMCS server ID). "GetServers" should provide that information. If exposing credentials is to risky, if have another idea:
Variant B: Expose a pass through method to call Plesk API methods from the WHMCS API.
As a variant for the previous idea an endpoint could be added that passes data to the Plesk API and sets the credentials by itself. Desireably you would provide the server ID and a data package for the target API (plesk in this case). WHMCS would then construct an internal call to the target API and set the allready defined API credentials. This would be alot harder to develop than variant A, but more secure as credentials are not populated over an endpoint.
Let me know what you think.
3 Comments
Login to post a comment.
Thanks for your suggestion. Would I be right in my understanding that you'd like WHMCS to act as a proxy to the Plesk API?
The current scope of the WHMCS API in relation to modules is to facilitate execution of the module commands (create, suspend, change package etc).
well yes, but actually no. Before anything else, I would like to have (more) Plesk related data exposed in the API. For example lets assume I have a WHMCS set up with 2 Plesk servers acting as regional shared hosting containers in the USA and Canada. Furthermore lets assume I want to automatically create a mail address that the user has entered in a form within the checkout/configuration process. So he (the user) buys a website, enters a mail and expects it to be setup together. To accomplish this in theory I would need the Plesk server IP/domain (so I can construct the Plesks API URL), the Plesk API user, the Plesk API key and the subscription ID for some API calls (like creating a mailbox). This is of course >after< WHMCS has recieved an "AddOrder" call and installed an application on one of the regional servers. However WHMCS offers only the server IP for a subscription/client product config. So it's up to myself to configure the Plesk API credentials inside my automation application (outside WHMCS) and to resolve the domain name of the WHMCS subscription to a subscription (site) ID in Plesk. This involves at least 1 unnecessary step: resolving the subscription ID, because WHMCS needs the subscription ID itself to execute commands like "delete". I was expecting this ID to be inside the "externalID" field exposed by a WHMCS subscription object (ClientProductConfig). But I was wrong. So with this in mind it would also be pretty nice to have the API credentials of a Plesk server exposed over the WHMCS "GetServers" API or a possible new endpoint like "GetServerConfig". Because it would be awesome to have my servers configured on a central plattform rather than copying the settings over all involved scripts and systems.
And this all lead to Idea 2 Variant b): Instead of having to write the whole API connection and configuration to Plesk on my own, why not let WHMCS handle it with what it has already built in? WHMCS already calls many of the Plesk APIs and has amdin credentials configured. So it would just need to let me pass through some additional commands. But that's not what this thread was about. It's mainly to make working with the Plesk module easier and get rid of the additional configuration layers that are needed right now. Especially the need to resolve the domain name of a WHMCS subscription to a Plesk subscription ID, to call basic Plesk site related endpoints.
Thanks for such a detailed concept. At present the provisioning modules aren't designed to interact with external services in this way, so it'll be interesting to see if other users would find this beneficial.