Prevent FTP Account Manager "Delete Account" from Deleting Core Web Files
Summary:
When deleting an FTP account it is also possible to delete the home directory assigned to the FTP account. The user should be informed when this directory is the same as a website document root. Ideally the user should be prevented from removing the directory, and its contents, when it is the document root.
Original request:
Hi Guys,
While I get that this is only an option provided to users when deleting account, users aren't always the most tech savvy bunch ... when an account root is pointed to say "public_html", it will proceed to wipe out all files in public_html. Some level of "tool rights" logic should be added here, maybe to say if it's associated with an active add-on domain or core folders like "public_html" that the files cannot be removed from said tool.
We are a very small hosting company compared to most and we see this happen at least once a month to one of our users which means us digging out a back-up and doing a partial restore, thus eating valuable staff time.
Please code in some additional common sense to prevent user stupidity :).
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.
In X3 the user can easily delete everything with a single button click. For Paper Lantern we changed this to require an additional opt-in to remove the directory and its contents. As the conversation here shows there is still room for improvement.
Informing the user of additional consequences of removing the directory will help in deciding whether to take that action.
In X3 the user can easily delete everything with a single button click. For Paper Lantern we changed this to require an additional opt-in to remove the directory and its contents. As the conversation here shows there is still room for improvement.
Informing the user of additional consequences of removing the directory will help in deciding whether to take that action.
In X3 the user can easily delete everything with a single button click. For Paper Lantern we changed this to require an additional opt-in to remove the directory and its contents. As the conversation here shows there is still room for improvement.
Informing the user of additional consequences of removing the directory will help in deciding whether to take that action.
In X3 the user can easily delete everything with a single button click. For Paper Lantern we changed this to require an additional opt-in to remove the directory and its contents. As the conversation here shows there is still room for improvement.
Informing the user of additional consequences of removing the directory will help in deciding whether to take that action.
@Kenneth, I wouldn't really call a prompt protection.
Case scenario:
As a cPanel user, I create a new FTP account for a developer, pointing it to the public_html folder. The developer does his work, and as the account is no longer required, I go into "FTP Accounts", and remove the account. As I am not horribly tech savvy, I choose the option to delete the account and associated files. This will delete the public_html folder and all sub-folders/contents.
What I am suggesting here is that this is a horrible thing that the software allows for. Just like if I attempt to delete a sub-domain that is associated with an add-on domain, it will produce an error. A similar set of rights should be added here, namely checking the folder paths for any add-on domain / sub-domain / parked domain / (etc) , along with the base public_html folder path, if any of these match up to what is going to be deleted, don't do it.
If this is still unclear please let me know.
@Kenneth, I wouldn't really call a prompt protection.
Case scenario:
As a cPanel user, I create a new FTP account for a developer, pointing it to the public_html folder. The developer does his work, and as the account is no longer required, I go into "FTP Accounts", and remove the account. As I am not horribly tech savvy, I choose the option to delete the account and associated files. This will delete the public_html folder and all sub-folders/contents.
What I am suggesting here is that this is a horrible thing that the software allows for. Just like if I attempt to delete a sub-domain that is associated with an add-on domain, it will produce an error. A similar set of rights should be added here, namely checking the folder paths for any add-on domain / sub-domain / parked domain / (etc) , along with the base public_html folder path, if any of these match up to what is going to be deleted, don't do it.
If this is still unclear please let me know.
Hi Kenneth,
See attached image, that would be the ideal situation.
Hi Kenneth,
See attached image, that would be the ideal situation.
A better message may be "This folder cannot be removed via this tool as it's in use by domain.com."
A better message may be "This folder cannot be removed via this tool as it's in use by domain.com."
Please describe a scenario where a user would want to actually do this ?
Please describe a scenario where a user would want to actually do this ?
Kenneth,
I suppose that can/will certainly happen, but I don't see any reason why the FTP account tool needs to assist in removing these files. That said, if the user has already removed the site from the add-on/sub-domains/etc then there would be no block present on the FTP tool from deleting the directory.
All that said, per your case scenario, it would be far better to present a delete option to that end within the removal of the sub-domain / add-on domain and not via the FTP accounts manager.
Kenneth,
I suppose that can/will certainly happen, but I don't see any reason why the FTP account tool needs to assist in removing these files. That said, if the user has already removed the site from the add-on/sub-domains/etc then there would be no block present on the FTP tool from deleting the directory.
All that said, per your case scenario, it would be far better to present a delete option to that end within the removal of the sub-domain / add-on domain and not via the FTP accounts manager.
Equally, imagine a situation where you have the following deployment scenario:
domain.com public_html (main cPanel account)
sub.domain.com public_html/sub (sub-domain of main account)
myname.com public_html/myname.com (add-on domain)
thisname.com public_html/thisname.com (add-on domain)
You have an FTP account that is pointed to 'public_html' , delete it with the checkbox / remove files. It will wipe out all websites.
This option simply has too much power for non-tech savvy users.
Equally, imagine a situation where you have the following deployment scenario:
domain.com public_html (main cPanel account)
sub.domain.com public_html/sub (sub-domain of main account)
myname.com public_html/myname.com (add-on domain)
thisname.com public_html/thisname.com (add-on domain)
You have an FTP account that is pointed to 'public_html' , delete it with the checkbox / remove files. It will wipe out all websites.
This option simply has too much power for non-tech savvy users.
Thanks for the input!
Thanks for the input!
Perhaps limit cpanel FTP management to paths it actually created. That way only WHM could terminate account or intentionally delete /public_html or paths not created by cP.
Perhaps limit cpanel FTP management to paths it actually created. That way only WHM could terminate account or intentionally delete /public_html or paths not created by cP.
Replies have been locked on this page!