Subversion Checkouts for Live WebApps Can Be Useful, but Dangerous
The web design and development blog Smashing Magazine published an article today about a problem when using a Subversion checkout to deploy files to a live webserver. In short, anyone could browse to a directory on your website, and see all the source code, including database connection information. (Don't worry, at SiteCrafting we don't do this. We have a much better system.)
The Smashing Magazine article includes tips on how to secure common web servers. Here's another way to secure a site using two simple htaccess rules.
Securing your site using htaccess is very easy, you just need to add these simple rules to the .htaccess file in your root directory:
RewriteRule (.*)\.svn/(.*) - [F]
This tells Apache to display a 403 forbidden message when trying to access a directory listing (if an appropriate index.html or index.php doesn't exist), or anytime someone tries to view any file under any .svn directory. (You really only need the Rewrite rules, but Options -Indexes is useful as well.)
Checkouts are really not intended to be used on a live web application. It's much more appropriate to use an export, because you shouldn't need to check in any files on a live site. However, it's incredibly useful to be able to update a live project to the most current version by only updating the recently changed files.
[dave@banana live-website]$ svn up
Updated to revision 93.
Wordpress, for example, uses checkout very effectively. Smart Wordpress developers will install a WP instance with
$ svn co http://core.svn.wordpress.org/tags/2.8.4 .
Later, when a new version is released, developers can then upgrade by doing something like this:
$ svn sw http://core.svn.wordpress.org/tags/2.8.5/ .
Considering how fast and often Wordpress gets hacked, it's a great idea to have the ability to instantly upgrade to the latest version.
The bottom line is that developers should be aware of the perils of using a SVN checkout. If they still chose to do it, they should take the proper steps to make sure their applications and their clients' data is not compromised.
by Dave Poole | 9/25/2009 10:21am