Title: Clientexec 7.2.2 — How can a Snapin securely execute customer-initiated server plugin actions?

[HostOncilla]

Hi everyone,


I’m developing a custom Plesk Manager Snapin for Clientexec 7.2.2, using the existing Plesk10 server plugin.


The aim is to extend the customer’s hosting package with additional management features, including:

• DNS Management (view, add, edit and delete records)
• Email account management
• Other Plesk hosting management features in the future

The Snapin is already integrated into the customer’s hosting package, and the DNS Management interface is working. It can retrieve and display the customer’s existing Plesk DNS records.


The problem


I’m struggling to establish the correct way for a customer-facing Snapin to execute backend actions securely.


Customer GET requests to registered Snapin views work correctly, but attempts to execute POST requests or invoke Snapin actions have failed.


Here is what we’ve established:

1. addMappingView() works and successfully renders custom customer-facing pages.
2. A POST request to a working mapped view returned HTTP 200 with an empty response body, whereas GET rendered the page correctly.
3. Attempts to invoke actions through fuse=admin&action=doplugin&controller=plugin&type=snapin resulted in redirects rather than executing the intended handler.
4. The existing Plesk10 server plugin doesn’t appear to declare Registered Actions For Customer.
5. Other server plugins, such as SolusVM, use Registered Actions For Customer and methods such as doauthenticateClient($args).
6. Some Clientexec core controllers are ionCube-encoded, making it difficult to trace the request-dispatch process.

What I need help understanding


1. Customer-facing Snapin actions


What is the officially supported way for an authenticated customer to submit a POST request to a Snapin backend handler in Clientexec 7.2.2?

• What URL, controller and action should be used?
• Can addMappingAction() handle customer POST requests?
• How should the action be registered and invoked?
• What parameters are required?
• What response format is expected (HTML, JSON, redirect, etc.)?
• Is there a working example of a customer-facing Snapin performing an AJAX POST request?

2. Server plugin customer actions


How does Clientexec invoke methods declared through Registered Actions For Customer?


For example, if a server plugin declares authenticateClient and implements doauthenticateClient($args), how is that method invoked from a customer’s product page?


I’d particularly appreciate a working example showing the correct request URL, HTTP method, parameters and response handling.


3. Authentication, authorization and CSRF protection


How should we securely verify:

• The customer is logged in.
• The hosting package belongs to that customer.
• The package uses the correct Plesk10 server plugin.
• The customer is authorized to perform the requested operation.
• The POST request passes Clientexec’s CSRF protection.

Does Clientexec perform these checks automatically for customer server-plugin actions, or must the Snapin implement some of them?


4. Accessing the hosting package and server configuration


From a customer-facing Snapin action, what is the supported way to obtain the relevant hosting package object, package ID, associated server configuration and domain?


Can the Snapin safely call methods on the existing Plesk10 plugin, or should it use another supported Clientexec API?


5. Recommended architecture


For a Snapin that adds DNS and email management to an existing Plesk10 hosting package, which approach is recommended?

• Implement backend actions directly inside the Snapin.
• Register additional customer actions in the Plesk10 server plugin.
• Use another supported Clientexec extension mechanism.

I’d prefer not to modify the production Plesk10 plugin unless necessary, since it already handles provisioning and other essential hosting operations.


6. Working code example


If possible, could someone provide a minimal working example for Clientexec 7.2.2 showing:

• A button on a customer’s hosting package page.
• An authenticated POST request.
• A backend PHP handler.
• Verification that the customer owns the hosting package.
• A simple JSON response such as {"success":true,"message":"Action executed"}.

The example doesn’t need to make any changes to Plesk. I just need to establish the correct, secure customer-to-backend communication mechanism.


What already works


The customer-facing interface, Plesk DNS record retrieval, and registered GET views are working. DNS modifications are intentionally disabled until the backend action mechanism and its security requirements are confirmed.


Any documentation, working code examples, or guidance from developers familiar with Clientexec 7.2.x would be greatly appreciated.


Thanks in advance!