2009-11-03

TWiki/Foswiki attchment access control

Finally got attachments protected in my TWiki installation. This solution is tested on TWiki 4.3.0 and 4.3.1, but should generally work with any TWiki 4.2.0+ and also any Foswiki version.

By default, neither TWiki nor Foswiki protects attachments from being accessed by anyone. All files reside in /path/to/wiki/pub/ and are accessible as http://teletubbyland/wiki/pub/%WEB%/%PAGE%/%FILENAME%. With open wiki, this is generally not a problem. However, unprotected attachments will become an issue if some webs need to have different levels of access.

Say, Po and Laa-Laa have their own closed web that noone else can read nor write into. Secret/WebHome page contains an attachment file.txt, that they expect to be hidden from others too. However, if Dipsy knows that this file exists, it can easily get it as http://teletubbyland/wiki/pub/Secret/WebHome/file.txt.

There are many options to protect the attachments, but both TWiki and Foswiki recommend using special viewfile script with Apache rewrite-module (here and here). With that, direct requests to attachments will be filtered to check if this particular user has a permission to access this particular file. Access permissions are inherited from the page this attachment is linked to.

The bad thing is, none of the configurations worked for me, so I've made some modifications I'd like to share.

Just in case, you need to enable rewrite-module. On Debian/Ubuntu it is done by running

a2enmod rewrite


You may also need to add view and viewfile to list of scripts that Apache will control access level for. Find this section in your Apache configuration file for wiki and fix it according to your needs:

<FilesMatch "(view|viewfile|attach|edit|manage|rename|save|upload|mail|logon|rest|.*auth).*">
require valid-user
</FilesMatch>


Then, make sure symlinks are enabled in the /path/to/wiki/pub/ directory:

Options +FollowSymLinks


Finally, let's do some optimization. Feeding every attachment URL to viewfile script can significantly slow down loading pages, so we should access some attachments directly instead. For example, TWiki (or System) web and Main/WebPreferences page attachments are visual elements (logo, CSS, etc.), so we exclude those paths from filtering:

RewriteCond %{REQUEST_URI} !^/+wiki/pub/(Main/WebPreferences|TWiki)/.+$


All the other attachments will be handled by viewfile script and only authorized users will get access to them.

RewriteRule ^/*(.*)$ /wiki/bin/viewfile/$1 [L,PT]


And putting it all together:

<Directory "/path/to/wiki/pub">
# Needed for Rewrite to work
Options +FollowSymLinks

# Gentlemen, start your engines
RewriteEngine on

# Allow direct access to files in TWiki web and on Main/WebPreferences page
RewriteCond %{REQUEST_URI} !^/+wiki/pub/(Main/WebPreferences|TWiki)/.+$

# Filter other file requests with `viewfile`
RewriteRule ^/*(.*)$ /wiki/bin/viewfile/$1 [L,PT]
</Directory>


Restart Apache and enjoy. And yes, read access logs every night before going to sleep (:

Useful links:


Update 2009-11-14:

You can also use ApacheConfigGenerator for TWiki and Foswiki to generate proper Apache directives, there's a checkbox saying 'Secure file attachments' or 'Control attachment access' -- thanks Peter and Anonymous.

Foswiki ApacheConfigGenerator allows all images (gif|jpe?g|ico) to be addressed directly, this is way too liberal for me. And PNG is missing by some reason.

Also in both cases rewrite rules are generated host-wide there, and I believe that narrowing their usage to one `/pub/` directory is better idea from the performance point of view.

------

Dear Foswiki guys, please don't use my blog to promote your project by throwing crap towards TWiki. Anyone who has ever heard Foswiki name already knows how it is different from TWiki and why was the fork created. No need to reemphasize it in every post or comment in the internets, or at least no advertising in my blog please. Anonymous, I removed your comment as its political part is totally irrelevant to attachment access control what this post is actually about. I hope you'll take it right. Technical part is added to post, and technical comments are always welcome. Thanks.

2 comments:

Anonymous said...
This comment has been removed by a blog administrator.
Juri Hudolejev said...
This comment has been removed by the author.