Hi Nasser,

Please when you post in the forums do not copy and paste from MS Word because this puts a bunch of invalid xml and style into your post and makes the page invalid. Please use a plain text editor instead or write directly in the editor of the forum.

Regarding un-installation, there are very good reasons we do not do this kind of thing in mojoPortal even though other apps may do it.

You can remove features (so they are not available in 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.

Some applications (the other 2 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. One of them even allows you to install from over the web and it 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 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 apps 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 apps 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.

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 convenient installation from the web page.

Best,

Joe

Hi Jamie,

I don't want to say disparaging things about other CMS systems, and I would not go so far to say they don't care about security, I'm sure they do care and have coded their systems to limit who can install features. I do think they draw the line for what is good enough security in a different place than where I draw it and I do think it should be a red flag when the installation instructions say to make sure the entire web site is writable.

I'm not sure the FAQ is where people would look for this information, instead I've created a page under the Architecture section of the documentation here:

http://www.mojoportal.com/why-custom-features-should-be-installed-by-ftp.aspx

Best,

Joe

Hi Nasser,

We already have a section where users could contribute skins or custom features.

http://www.mojoportal.com/communitydownloads.aspx

but that does not mean people will or do contribute high quality stuff, but the opportunity exists for people to share.

When you look at other systems you will see lots of things people have made because they were missing features in those systems, many of which features are not missing in mojoPortal therefore there is not a strong driver to cause others to implement it as there is when the feature is missing. I see modules for friendly urls was an add on feature in one popular CMS and only recently last year became a core feature of that CMS and things like that that have been included in mojoPortal from the beginning.

The quality of those plugins available for other systems varies quite a bit and though there may be thousands of plugins for other systems there are likely not very many high quality ones and the high quality ones often cost money and then users have to get support from a variety of vendors and also has to trust the security of the feature itself. And you will see in forums for these other systems when people complain about it being slow or not working they blame it on installing a bunch of junk features (there are some good features out there for other CMSs but there is also a lot of junk).

Security concerns for an operating system are quire different from a web site and not comparable in the same context. 

Skin management is something on our road map and will not require ftp because skin files are stored in the writable section of the file system beneath /Data and they do not have executable code so we will be able to upload skins from the web browser.

ftp is something completely different and not something to implement as a web site feature. Building an ftp client is a huge project unto itself but also mojoPortal has no knowledge of whether an ftp server is configured or not or what folders it is configured for. Trying to build all that in web site software is a recipe for security problems in addition to a huge amount of very difficult work. Trying to do that will only slow down development of mojoPortal. On cannot implement an ftp client with html, it would require a java applet or something like that and it will never be as robust as a real ftp client like FileZilla.

Myself, I think that mojoPortal development is happening at just the right speed and we continue to attract more and more users even though we don't always do things the same way as other projects but according to our own vision of how to do things.

Best,

Joe