Protect static files on Apache with OpenID

Fri, 18 Nov 2011 23:11:50 +0000

I moved from static HTML pages to web applications and back to static HTML files. There’s a lot to be said for the simplicity and portability of a bunch of files. Static site generators like Jekyll are increasingly popular; I’ve built a simple publisher that I use extensively.

Web apps give you something else, though, that are still useful on a static site. Access control. I’ve been resorting to htpasswd to protect static files, and it’s far from optimal. I don’t want to know or manage users’ passwords. I don’t want them to remember a new ID. I just want to allow specific people to log in via their Google Accounts. (OpenID is too confusing, and most people use Google anyway.)

The easiest option would be to use Google AppEngine. But their new pricing worries me. Hosting on EC2 is expensive in the long run. All my hosting is now out of a shared Hostgator server that offers Apache and PHP.

So, obviously, I wrote a library protects static files on Apache/PHP using OpenID.

Download the code

Say you want to protect /home/www which is accessible at http://example.com/.

Copy .htaccess and _auth/ under /home/www.
In .htaccess, change RewriteBase to /
In _auth/, copy config.sample.php into config.php, and
change $AUTH_PATH to http://example.com/
add permitted email IDs to function allow()

Now, when you visit http://example.com, you’ll be taken to Google’s login page. Once you log in, if your email ID is allowed , you’ll be able to see the file.

Feel free to try, or fork the code.

Comments

S Anand 19 Nov 2011 10:31 am: I could. But what I’ve learnt is that while the static content on this site has survived 14 years, moving from host to host, the same can’t be said of ANY of the apps I’ve written to create the site. I’ve moved from shell scripts to Perl to Python to node.js… and something else will come up. I can’t maintain this stuff. Fortunately, HTML will stay. So I’m making the content primary. I just have a bunch of static files, and that’s the key. This is an OPTIONAL library that sits on the side. Without it, the worst that’ll happen is that the content becomes public. But otherwise, all URLs will remain unbroken. That’s a big win with this approach. That’s also the reason I rejected AppEngine. For my volume of usage, pricing isn’t a serious issue. It’s simplicity.
Manu 19 Nov 2011 5:59 am: If you are willing to host it outside, then heroku allows one free instance per project.
S Anand 2 Dec 2011 10:09 pm: I too will probably stay on WordPress for a while. But recently, I’ve been creating quite a few microblogs for various topics, and find that the workflow of Markdown -> Dropbox -> PHP -> HTML far too compelling to ignore. It’s worked quite well from an ease of publishing perspective. I’m still ironing out few edges. Will publish once I do.
Thejesh GN 25 Nov 2011 11:56 am: I was planning to move to static using http://www.blogofile.com/ (python and variety of templating systems are supported). But I am still betting on wordpress for many things. One day I will probably move to static blog.
Christophe-Marie Duquesne 22 Dec 2013 12:53 pm: Hi, Your post inspired me to write a lighttpd magnet script that protects content regardless of its nature (static or dynamic). I use it:
- for protecting my (static) photo gallery and only giving access to people I select
- for protecting my (dynamic) rss reader and only giving access to myself
- for protecting my (dynamic) online file manager and only giving access to my girlfriend and myself. It is completely pluggable, and it sets the REMOTE_USER server variable so that user-aware applications can use this mechanism to authentify you. https://lighttpd-external-auth.chmd.fr/

Two Factor Authentication

Thu, 17 Mar 2005 12:00:00 +0000

Bruce Schneier on The Failure of Two-Factor Authentication. Two factor authentication replaces passwords with two things: something you have (e.g. a security token that changes numbers every minute) and something you know (e.g. password). Bruce says this won’t help against two new kinds of attacks we’re seeing:

Man-in-the-Middle attack. An attacker puts up a fake bank website and entices user to that website. User types in his password, and the attacker in turn uses it to access the bank’s real website. Done right, the user will never realize that he isn’t at the bank’s website. Then the attacker either disconnects the user and makes any fraudulent transactions he wants, or passes along the user’s banking transactions while making his own transactions at the same time.

Trojan attack. Attacker gets Trojan installed on user’s computer. When user logs into his bank’s website, the attacker piggybacks on that session via the Trojan to make any fraudulent transaction he wants.

Really stupid security policies

Sun, 27 Oct 2002 12:00:00 +0000

Really stupid security policies. On three sites (two Indian) that don’t take security seriously. via Ravikiran

Using digital signatures

Mon, 29 Jul 2002 12:00:00 +0000