25 Sep
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:
Options -Indexes
RewriteEngine on
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
U index.php
U about.php
A images/picture-of-dave.png
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.
Coding Techniques, From the Workbench, Odds 'n Ends, Security
by Dave Poole | 9/25/2009 10:21am
by Dave Poole | 9/25/2009 10:21am
Glad you pointed this out. It is always something people forget when publishing data on the web. It can also accidentally be uploaded when copying files to an FTP. Your suggestion also fixes this problem.
An alternative idea is to remove the .svn folders after checking out to a web server. This is likely better then just hiding the svn folders, but is not always something you can do. Either way, this is bad stuff to publish to the world.
Left by | Sep 25, 2009
It's more current -ish than tags. It will give you all the upadtes for that branch until the next branch comes out. So right now branches/2.5/ will get you v2.5.2 alpha. You can set up cron to svn up for you every night. Then, the only svn sw you have to do is at branch changes. This is the one I hit.If you're feeling froggy, you can always hit trunk/. That gives you the developement version. Which works. Sometimes. But if set up cron to svn up for you every night, there's no input from you, except for the occasional database update.In the end, though, I agree with you, Andy. They need a stable trunk we can point to and forget about it. I cannot think of any reason not to, and I can also think of no reason to have the current system! :-
Left by Sekhar | Aug 29, 2012