Some words of introduction
PHPWG is a pretty mature application. It has all the little features that one might expect from a (more than) decent PHP gallery. One of them is a simple form of access control, simple but efficient. The administrator can create users and groups in order to decide WHO can see WHAT.
There are two authentication schemes available. You can either decide to let your web server do all the hard work for you, or leave everything to PHP. The first solution offers probably the best security1 but isn't always available. That was the case for my gallery. Although using Apache's authentication was an option, the user administration was trickier and more importantly, passwords had to be saved in clear form in a text file, which was plainly unacceptable!
The PHP scheme works (apparently) fine, but has a terrible flaw. Since all authentication is web server-independent, the images are accessible to everyone, so even if PHPWG forbids you to see some categories and their content, nothing can stop you from just bypassing the whole application and getting to the image you want to see. All you need to know is the path to a category, or the image itself. So if one of your users publishes the link to one of your private images2 only a restricted number of people can normally access, your image will quickly become public3.
Presentation
Although some tricks could prevent some people from trying to see your gallery without having the necessary rights (by guessing the names of your categories for instance), there is no way to be really sure that access to your data is in good hands.
The only feasible solution was to completely block any direct access to your images4 and leave all the work to PHP. Therefore, instead of giving the link to your images, you give a link to a PHP file5 with an id which uniquely identifies the image that the user wants to see. getFile.php then checks if access is authorized (this part is still done by PHPWG), and if so, opens the image and sends all the data to the user's browser.
PHPWG developers are no PHP beginners, they knew that such a solution was feasible, but didn't bother to implement it because they feared that the consequences on performance would be far from negligible. That is a valid point, but one might argue that rarely is PHPWG used on massive galleries, with thousands of users. Even on web servers that provide their hosting services for free6, where some measure is expected from webmasters to keep resources' needs to average levels, many are those who, in my humble opinion, are willing and can afford to pay the costs for this little "extra" security.
Installation
Installing a module for phpwebgallery is a tricky process because the user has to manually edit the files himself. However, an install file is provided and by following the guidelines7 of the developing team, it should be rather straightforward.
A sample htaccess file is provided along with the module and should be moved to the galleries directory after being renamed .htaccess
Current state
As of version 0.3-1, the getFile.php script is rather complete and covers (normally) all of PHPWG functionalities. There is an exception though: thumbnails for images to be added to PHPWG can be created directly on the hosting server (if the necessary libraries are available). Since these images' information is not yet in the database, there is no (easy at least) way to show them, therefore the resulting thumbnails will not be showed. I considered this inconvenience as being a rather minimal one and after all the user is highly recommended to create thumbnails on his own computer8, therefore I didn't get in the trouble to fix this.
From what I understand (after reading a couple of posts of PHPWG developers on the forum), once the module will be stable enough, the performances will be measured and evaluated so as to see if its functionalities should be included in the core.
Future work
One nice feature of PHPWG is the ability to store images on another web server and import them in your collection9. We can only expect to find PHP on the distant web server, no database whatsoever can be used.
After some quick thinking, I seem to have found a solution to the problem that should be optimal on terms of latency and while not entirely securing the images on the secondary web server, should protect them for 99.9% of the cases. I'm no security expert whatsoever, but I was inspired by existing security protocols, therefore I suppose that I didn't overlook a trivial fact that would make my solution obsolete. Anyway, all of this is just theory, I will however start coding this in the following weeks because I find the challenge very tempting.
Links
Here is a list of links that might be useful:
- PHPWG extensions page
- secureImages extension download page
Notes
1 not talking from experience, but it's more likely to have a security hole in your PHP code, than Apache's mod_auth module having a problem
2 let's say he puts an entry in his blog like: Hey check this cool image at http://iacp.free.fr/gallery/galleries/this_is_a_fictionnal_category/with_a_fictionnal_image.jpg
3 and with all the web crawlers that roam all over the Internet, your little secret picture wont be secret for long
4 that is achieved by the web server, for instance with a little .htaccess file at the root of your gallery when working with Apache
5 from now on, we will refer to it as getFile.php
6 as it is the case with the host used for this page, as of the writing of the article
7 only available in french
8 with a good graphics application, the results can also be quite better than the ones obtained with the GD/GD 2 library
9 no actual copying of the file is made, you just point your user to the images on the other web server
