Why Do Web Applications Stink So Badly?

November 25th, 2008

So today, I happen to be looking at wikis for two small to mid-sized public proojects (MoinMoin and DokuWiki look like frontrunners right now — any suggestions?) Recently, I’ve also looked at blog and CMS software, and a host of other web apps. It’s as if these people have learned nothing about good software practices over the last 20 years.

Warning: Rant Ahead

So how many of you have been here before? You download WebApp X. It tells you to cd to your DocumentRoot and unzip/untar it there. At this point, most of them will tell you to chmod -R 777 the install directory. Some of the better ones, such as WordPress, will tell you to chmod it 777, or if that makes you nervous, to instead chown it to the user that your webserver runs as.

It is at this point that you realize that the Java-based programs ship with their own webserver that takes 2 minutes to load and uses 2GB of RAM, while the PHP-based programs want you to give them 32MB RAM per process, and probably modify your global PHP settings in a way that breaks some other PHP web app you’re already using.

As if that isn’t enough to scare you off, generally speaking, config files — including passwords to databases — are stored in the same directory, along with .htaccess files. Many of these programs are also downloading and updating plugins over the Internet, usually without any kind of cryptographic authentication, and overwriting their own program files in the process.

Oh, and this is a class of app that is notorious for security problems to start with, and makes your server known to billions of people via search engines.

Absolutely no opportunity for trouble here, of course! That sentence was dripping with sarcasm, in case you didn’t get it.

It also makes it almost impossible for people such as Debian maintainers to package up some webapps (such as just about every single one that uses Ruby on Rails) because there is just no sane way to make it behave with respect to the Filesystem Hierarchy Standard.

I’d love to see web app developers do a few simple things:

  1. Separate code from data
  2. Separate code from configuration
  3. Separate all of the above from the DocumentRoot to the greatest extent possible

I realize that some of this is purportedly to make things easier to install when you have FTP access only. But to me it seems just really poor design. I’ve written webapps, and it’s not that hard to do this part right.

Plus, doing the above right means that I no longer have to do something like use git on my WordPress installations because it’s too much of a hassle to apply security and plugin updates on all three separate ones otherwise.

Categories: Programming

Tags: , Leave a comment

Comments Feed36 Comments

  1. Anonymous

    I think both the “please chmod to” disease and the “please use gems/eggs/CPAN” disease stem from the same problem: people used to an utter lack of decent package management and thus succumbing to NIH.

    Reply

  2. Simon

    Hi John.. as a wiki option, I’d be interested to know what you think of Zwiki.

    Reply

  3. Jon

    Have you considered ikiwiki (ikiwiki.info) ?

    Reply

    Logic Induction Reply:

    ikiwiki is as stupid as it gets. the /etc/ikiwiki requirement cannot be got away with. that means shared webhosting is completely out.
    The rest of CPAN requirements notwithstanding, the issue of creating a bunch of totally incomprehensible files; means there is “more than way” that the user will decide never to fix/debug or contribute to the project.

    ikiwiki will live till the current author is alive !

    Reply

  4. Gregor

    Dokuwiki is fantastic!

    Reply

  5. Kai Hendry

    Try ikiwiki.info. It’s sane software.

    Reply

  6. MJ Ray

    One of the big reasons for web apps stinking is a combination of most web hosts stinking (all customers on a server running PHP as www-data or nobody can mean that chmod 777 is the only way to write files), near-impossibility to get some customers to move to saner web hosts and webmasters-that-know-better not refusing those customers because we don’t think we can afford to.

    Oh and I’d try ikiwiki too :)

    Reply

  7. lloeki

    my webdev attempts in python (webpy, django) consists exactly of FHS-compliant/packageable/in-python-tree modules.
    php gets the fair share of bad points because while you could do (hack?) the above, it was designed to be like html… i.e static equiv dynamic… which is just plain wrong, and the whole of php feels just like that in so many areas I just can’t trust it, nor myself because it makes things so hard that I’m bound to make a mistake at some point.
    at least the framework (cakephp) I used for php webdev specifically mentions to chmod/chown only its tmp dir, used for some caching, and also mentions you could put both its core files (and then app-specific ones) outside the www tree.
    I found that a nice touch.

    Reply

  8. David Bremner

    Let me second or third the suggestion of looking at ikiwiki for things
    like blogs, particularly if you are working with version control.

    Reply

  9. John Goerzen

    Thanks for the suggestions, everyone. I’m going to be operating a wiki whose target audience is non-geeks (railroad passengers), so things like pretty themes, WYSIWYG editor, etc. are important. I haven’t looked at either ikiwiki or zwiki yet, though I thought that at least ikiwiki lacked the WYSIWYG editor.

    Reply

    dalesmcd Reply:

    Sounds like our requirements. We settled on the free open source edition of DekiWiki. We came close to going with Google Sites but turned away from that for other reasons.

    Reply

  10. trond

    Forum software is also very problematic on shared hosting. The one I used recommended 777 for installation directory. I of course was aware that 666 allowed write access for everyone, so I removed all these, in addition to chmod the config file with database login to my user only. It worked pretty well until some data I spotted some javascript being injected with NoScript in Firefox. The problem was that the forum software had chmod’ed files in cache/upload to 666.

    I wrote about this problem on the forum’s support forum, but instantly got attacked by putting the blame squarely on my webhost. In the end though, both my web-host ended up adding suphp and the forum software patching up the chmod usage in their code.

    Reply

  11. Phong

    Why should my rails app on my mac comply to your shittard filesystem standard? why should you care at all what it looks like under its toplevel directory?

    Reply

    John Goerzen Reply:

    This has nothing to do with random apps complying with a filesystem standard as distributed. It has everything to do with them being written so poorly that it is impossible to deploy them in a sane way, such as a way that complies with the FHS as an example.

    Reply

  12. Anno

    Totaly agree! And also get rid of all dependencies.
    Anyone tried to install trac on your server?
    It’s a dependency-chain like no other.
    1. Install python
    2. Install easyinstall(which requires setuptool)
    3. ….

    135. Install Trac
    -This is where the configuration starts :p

    Seriously, if your program requires a tool called easyinstall it’s by definition NOT easy.

    Reply

  13. jlouis

    I feel your pain…

    There is untapped resources in providing easy-to-install software for the benefit of pure system administration while still providing sanity to the rot.

    Reply

  14. PA

    If you feel adventurous, try something a bit different, e.g. Nanoki, a simple, elegant wiki engine implemented in Lua.

    Online demo:

    http://svr225.stepx.com:3388/nanoki

    Reply

  15. mark

    Nice rant, however I must point something out:

    “It also makes it almost impossible for people such as Debian maintainers to package up some webapps (such as just about every single one that uses Ruby on Rails) because there is just no sane way to make it behave with respect to the Filesystem Hierarchy Standard.”

    The Filesystem Hierarchy Standard sucks.
    The whole LSB extends the FHS. Guess how much it will suck.

    The idea that the FHS will at ANY TIME IN HISTORY make things EASIER is an illusion. People must realize it. Debian is lazy. They stick to the FHS and will never change it. So they split packages in order to fine-tune what a user wants, BUT THE USER IS FOREVER FORCED TO REMAIN IN THE FHS because anything else will not be supported by Debian. What does the splitting of packages give you as a user?

    Nothing.

    Oh, except a headache.

    And I agree, webapps do quite suck. I think the separation between webapps and normal apps should go away.

    Reply

  16. sc

    Um, I’m pretty sure Rails does all three things you mentioned. The config files are in the config directory, and the rails code is not contained in the webroot. What exactly are you taking issue with?

    Reply

  17. akash

    How can I avoid putting the database config file in the document root for any PHP application ?

    Reply

  18. GTAStud

    I couldn’t agree more on the chmod 777 aspect. I guess it’s to avoid dealing with millions of people not understanding the intricacies of file management, but should they be hosting webapps in the first place?

    Maybe what we need are web services that only host specific applications on domains. For example, instead of getting a shared hosting account for beginner wordpress users, maybe they could just get a wordpress hosting account. Then they wouldn’t need to install it, or maintain the security. Much like using wordpress.com but with their own domains.

    Reply

  19. rachel

    Webapps stink so bad because people who know better spend more time bitching in their weblogs than they do teaching n00bs or submitting patches.

    Reply

    John Goerzen Reply:

    Are you sure?

    I’ve submitted patches to Redmine (a Ruby on Rails app), I wrote PyGopherd (a multprotocol web/app server with plugins handled in a sane way) from scratch. Or did you miss the part where I mentioned that I’ve written web apps too?

    Something tells me that a patch to remove the mention of chmod 777 from WordPress would not be accepted.

    Reply

  20. Dave James

    Use ASP.NET, try Umbraco for an easy to install CMS. PHP stinks…

    Reply

  21. Moxley Stratton

    You brought up some really good points. Many of them however, are not the fault of web developers, but instead are the fault of history. If I write an open source application that I want to be widely adopted, I have to revert to bad practices such as requiring chmods (to allow writing files), and putting private files under document root (for those FTP-only web hosts that only give you access to the document root — that is, most of them). It is a trade-off an open source publisher must make to make the application usable to a wide audience.

    History has created an open source web stack that is ill-suited for deploying web application packages. The web server and application sever layers could use a lot of improvement. Try to direct your energies there. Many an open source web developer would be grateful.

    Reply

    John Goerzen Reply:

    You probably do have a point on PHP putting too much in the document root. But there’s nothing inherent in the rest of the stack that mandates that, or even in PHP that mandates a lot of it. Good point on those web hosts, though.

    Reply

  22. stephen

    i kind of had the impression that he was talking about web apps in general..

    oh, wait…

    Reply

  23. mario

    The chmod 777 issue can be avoided on professionally set up webservers. If the web server is running with mpm_perchild or PHP using (F)CGI/suexec, it’s less of an issue.

    Separating out the code into distributed directories (FHS) is not always possible due to the common PHP-with-HTML intermingling. Though, there are a few applications where it’s easy to accomplish. I’ve seen one of those Debian packages making sense actually.

    But, can you provide a shining example of how you’d package a web app? Seen a good one lately?

    (Personally I think it’s yet more troublesome that everyone clinches to SQL string concatenation, instead of using prepared statements.)

    Reply

  24. Ralph Allan Rice

    I would agree whole-heartedly. I think that web applications can be much improved if they worked right out of the box… like most system applications do. They need to have installer that works with minimal headaches, little or no configuration changes, and (literally) no external dependencies.

    Reply

  25. James

    “At this point, most of them will tell you to chmod -R 777 the install directory”

    This is why no one uses Linux.

    Reply

  26. James

    My mistake… I just realized it’s less of an issue just so long as the web server is running with mpm_perchild or PHP using (F)CGI/suexec.

    Reply

  27. Jacques Chester

    Welcome to my world. Try not to look at the rubbish strewn everywhere.

    My estimation is that systems designed to run inside VMs will eventually edge out systems which have to run on shared hosting.

    Reply

  28. Edward

    The problem is that the entry barrier for web development is pretty low. This means (relatively) stupid developers can also be productive and ‘get something done’. Stupid developers = stinky code. There you have it.

    Reply

  29. links for 2008-12-04 | Yostivanich.com

    [...] Why Do Web Applications Stink So Badly? | The Changelog Web applications need to " Separate code from data, Separate code from configuration, Separate all of the above from the DocumentRoot to the greatest extent possible" (tags: webdevelopment programming) [...]

  30. Daniel

    Hi,

    To all the posters expressing frustration trying to get Dokuwiki, Trac, etc. going, you may want to give BitNami a try (http://bitnami.org). It is free, we try our best to make the installation of the apps painless (to the point of including and configuring Apache, MySQL, etc. as part of the install) and to keep them secure

    Reply

  31. Adam Sjøgren

    I have recently found Hatta – http://hatta.sheep.art.pl/ – to be quite nice for a small, simple wiki.

    It does not have a “graphical” editor, though – but I like its simplicity and featureset (clean URLs, backed by Mercurial, clean HTML/CSS that is easy to modify).

    The author is really quick to update/respond to bug-reports etc.

    Reply

Leave a comment

 

Feed

http://changelog.complete.org / Why Do Web Applications Stink So Badly?