This object is in archive!
Expose the source server FQDN to /scripts/postrestoreacct
Needs Feedback
Currently the postrestoreacct hook script only receives the following parameters (taken from http://docs.cpanel.net/twiki/bin/view/SoftwareDevelopmentKit/ScriptHooks):
user — The new (local) cPanel usernameolduser — The old (remote) usernamedomain — The restored account's main domainuser_homedir
It would be very useful to us for various plugins if this script also received the source server's name (the server name or IP given when copying an account using WHM).
I like this idea 
cPanel, WebHost Manager and WHM are registered trademarks of cPanel, L.L.C. for providing its computer software that facilitates the management and configuration of Internet web servers.
Could you provide some use cases where you say knowing this information would be useful to plugins?
How would this information be used, and to what end?
Given that the "source" server cannot be stored with any reliable/guaranteed nature, I can't imagine what it would be used for and how it would be useful.
The only way I can think of to bring this information forward in all situations would be to store it as meta data within the cpmove. However, what do we store? The hostname? The IP address?
Due to staging servers, backup servers, and other situations where hostnames may be identical or spoofed for testing purposes, I can't see how I (as a developer utilizing this data) would ever be able to trust it and do something with it. Depending on what you do with it, it may even be a security risk since anyone could customize the "source" meta data to be anything and trip desired login in your restore hook.
I'd appreciate further information on the use cases where you see this information as useful and how you would use it, noting that its "trustworthiness" would be suspect at best.
Could you provide some use cases where you say knowing this information would be useful to plugins?
How would this information be used, and to what end?
Given that the "source" server cannot be stored with any reliable/guaranteed nature, I can't imagine what it would be used for and how it would be useful.
The only way I can think of to bring this information forward in all situations would be to store it as meta data within the cpmove. However, what do we store? The hostname? The IP address?
Due to staging servers, backup servers, and other situations where hostnames may be identical or spoofed for testing purposes, I can't see how I (as a developer utilizing this data) would ever be able to trust it and do something with it. Depending on what you do with it, it may even be a security risk since anyone could customize the "source" meta data to be anything and trip desired login in your restore hook.
I'd appreciate further information on the use cases where you see this information as useful and how you would use it, noting that its "trustworthiness" would be suspect at best.
Could you provide some use cases where you say knowing this information would be useful to plugins?
How would this information be used, and to what end?
Given that the "source" server cannot be stored with any reliable/guaranteed nature, I can't imagine what it would be used for and how it would be useful.
The only way I can think of to bring this information forward in all situations would be to store it as meta data within the cpmove. However, what do we store? The hostname? The IP address?
Due to staging servers, backup servers, and other situations where hostnames may be identical or spoofed for testing purposes, I can't see how I (as a developer utilizing this data) would ever be able to trust it and do something with it. Depending on what you do with it, it may even be a security risk since anyone could customize the "source" meta data to be anything and trip desired login in your restore hook.
I'd appreciate further information on the use cases where you see this information as useful and how you would use it, noting that its "trustworthiness" would be suspect at best.
Could you provide some use cases where you say knowing this information would be useful to plugins?
How would this information be used, and to what end?
Given that the "source" server cannot be stored with any reliable/guaranteed nature, I can't imagine what it would be used for and how it would be useful.
The only way I can think of to bring this information forward in all situations would be to store it as meta data within the cpmove. However, what do we store? The hostname? The IP address?
Due to staging servers, backup servers, and other situations where hostnames may be identical or spoofed for testing purposes, I can't see how I (as a developer utilizing this data) would ever be able to trust it and do something with it. Depending on what you do with it, it may even be a security risk since anyone could customize the "source" meta data to be anything and trip desired login in your restore hook.
I'd appreciate further information on the use cases where you see this information as useful and how you would use it, noting that its "trustworthiness" would be suspect at best.
We were trying to think of a way for an anti-spam plugin we use in WHM (that integrates with our spam filtering cluster via an API) to be smart enough to tell our spam cluster (via it's API) to remove the domains belonging to a freshly copied cpanel account from the source server's domain allocation list, and re-assign them to the new server. As the hook would only be used when doing internal account transfers, and user's would not be able to add domains belonging to other customers (due to clustered DNS) then the risks (outside of an XSS vuln) would seem limited.
We were trying to think of a way for an anti-spam plugin we use in WHM (that integrates with our spam filtering cluster via an API) to be smart enough to tell our spam cluster (via it's API) to remove the domains belonging to a freshly copied cpanel account from the source server's domain allocation list, and re-assign them to the new server. As the hook would only be used when doing internal account transfers, and user's would not be able to add domains belonging to other customers (due to clustered DNS) then the risks (outside of an XSS vuln) would seem limited.
Replies have been locked on this page!