My first Drupal Camp Toronto experience is sadly over. There was a whole lot to absorb and although I found that I did learn a few new things, the most beneficial part of the conference for me was the inspiration I gained from others. I met many kindred spirits and future partners in crime. It was really interesting to learn about some of the initiatives that others are pushing forward. Overall I would say that Drupal Camp Toronto 2012 was a great event and really well organized.
Setting Up Drupal 7's Private File System
By Mike Gifford
December 22, 2010
I just updated the docs on drupal.org and discovered that D7 will take care of the permissions.
I was working on my first Drupal 5 to 7 migration earlier today and ran into an issue with the file system I hadn't needed to define previously. Drupal 7 has both a public and private file system path that you can define. This is great for security as you can easily divide what files you want available to the anonymous public and which they should be denied access. Drupal can be used to control delivery to users with appropriate permissions.
This is great, but there aren't enough active descriptions out there of how to do this yet. The DrupalHandbook of the Drupal 7 File System is pretty clear, "Files in the private directory are not accessible directly through the web server; when private files are listed, the links are Drupal path requests," is pretty clear, but doesn't provide a practical example.
I posed the question on Twitter, "if a Drupal 7's root is /home/drupal & the public files are in /home/drupal/sites/example.com/files where should the Private file system path be?" Following up by stating that from purely a backup perspective it would be nice if all client files were just in /home/drupal/sites/example.com/private and Apache is used to exclude access.
Now a quick search on Apache can give anyone directions for how to do this. Fortunately, Apache should deny access to all files in this directory and to all sub-directories unless Apache is given other instructions. So by adding the following to our Apache config for each new Drupal 7 install: Order allow,deny Deny from all
and restarting Apache we know that no public user can access this directory or sub-directory without going through Drupal. We can easily test that users can't access this directory by adding a README.html file to the directory & verifying if you can browse to it. Mind you not everyone has root access to modify Apache instance. Fortunately, this can also be put in a .htaccess file (as per this post or this one) in your private directory to control access to your files:
Deny from all
Since so many Drupal sites assume that Apache's AllowOverride are enabled, just adding this file to your private directory should meet most site's needs.
There might be better ways to implement this, but I'm putting this forward for critique before putting it forward for the Handbook. Is there a more secure/robust way to approach this?
