Why Custom Features Should Be Installed by FTP
This content is under review. It may be out-of-date. If you have questions, please ask in the forums
People occasionally ask why we don't have an installation system to install features from the web browser. We do have an installation system but it requires you to upload the files by FTP and then visit the setup page.
There are very good reasons we do not do this kind of thing in mojoPortal content management system even though other CMS applications may do it.
In mojoPortal, you can remove features (so they are not available on the site) from the web UI under Administration > Advanced Tools > Features, but if you visit setup page they will come back so you also need to delete the features from under /Setup/applications/[featurename] using an FTP user with more permissions and this will prevent the setup page from re-configuring them. Actually there are two levels of feature installation, the Setup page only controls the main installation level which makes the features available in the master site, but in a multisite installation you can install or uninstall features in individual child sites on a site by site basis, so if you remove a feature from a child site it will not come back based on the setup page, that only happens in the master site. Similarly, if you install a new feature the Setup page only installs it in the master site if you want to make it available in child sites you would have to explicitly install it in the child site from the Site List/Site Settings for child sites. This also makes it possible if you want to charge your customers for specific extra features because you can control which features are enabled in child sites easily.
Some applications (other popular .NET CMSs for example) allow you to install features by uploading a .zip file and it unzips it and puts all the files where they need to go like DLL files go in the /bin folder. Some even allow you to install from over the web and will download the feature from a remote server and install it.
The reason we do not design it to work like that is because of security. It is a very bad idea for the /bin folder to be writable by the web process and even worse if application code is designed to download more executable code from the internet and install it. This opens up an attack surface that could be exploited for remote code execution. I'm sure the application logic in these systems is designed to protect from that by controlling it by roles and permissions who can install code. However, that means that application code is the only protection. It is much better to have additional protection by file system permissions that do not allow the web code to install any executable code. Therefore, while it might seem like a convenient feature to be able to install like that, it is not a good design from a security point of view. In my opinion, installing a feature should be done by FTP using a more privileged user than the one that the web application runs as. So applications designed like that cannot be hardened for security. These same applications (I'm not naming them but you can guess) also make the Web.config writable because they modify it from web code during setup, this is another really bad idea that opens up vulnerability.
No folder that has executable code or allows executable code should ever be writable by web code. Any folder that allows file uploads should be configured to not allow scripts or executable code. So we don't want any code in mojoPortal to be able to add executable code to the file system nor to delete executable code from the file system.
I am fully aware that we do not have the same convenience as some of these other applications for installing/uninstalling features but I think it is more important to have good security and to not design/develop in a way that opens up attack surface. Those applications require the entire web site to be writable from web code, a very bad idea in my opinion. As with many things in life, just because you can do something does not mean you should do it. When you install any web application and the instructions say that the entire web site must be writable, that should be a red flag.
So the feature you get in mojoPortal is the ability to sleep well at night knowing that your site is not designed this way and is less vulnerable to hacking than these other systems that have a convenient installation from the web page.