[Melbourne-pm] Web auth meth
scottp at dd.com.au
Mon Sep 15 19:52:17 PDT 2008
On 16/09/2008, at 12:10 PM, Toby Corkindale wrote:
> Also, are you happy with writing code (or using code) that is
> shackled to Apache and mod_perl? What if you need to scale up, and
> run it on lighttpd, IIS, litespeed, nginx, zeus, etc?
No. Don't do that :-)
Think of the mod_perl specific code just as triggers. This is the same
for writing mod_perl applications. You build your code so that it can
run independently. And test the same way. Then write the wrapper for
it in mod_perl. You can do the same for CGI, and then you can (in
theory) for all other servers.
The argument that says - "Do it yourself in your own code so it is
portable" does not stand up for two reasons:
* If that argument was true, then you should also write your own web
server and database and operating system. When do you stop.
* Just because you want to make it portable does not mean you couple
it into the rest of your code.
But you are talking here about portability - writing authentication
modules separately makes them not only more portable (well you can do
anything, you can make it less or more or dependt, or coupled - really
where you put it doesn't effect that much), but more importantly
You decided tomorrow that what this product needs is job tracking and
wiki - and you work out that "Trac" is really the best tool for the
job. You install it and realise - oohh Python - how am I going to
You now have four choices:
1. You already used/wrote apache module - you have nothing to do.
2. You authenticate in perl and hack Trac to accept the same cookie
3. You have the user log into the two systems separately
4. You don't have a joined database and you have to register separately.
I am sick of going to places like zimbra.com where I have to have
separate login & passwords for each of their Wiki (Media wiki), Job
tracker (Bugzilla), and Form (PHP Forums).
> I don't think this really applies to Apache-based authentication any
> differently than to non-apache-based auth though. I mean, just
> because Apache authentication is only available on Apache, and has
> to be tested using a more convoluted means, doesn't mean it's more
> secure than if you put effort into testing your other authentication.
Sorry I didn't mean to imply that. What I am talking about is
separation of code. 99% of the PHP code I have to implement uses their
own authentication system, built into the script. If one script misses
that important line at the start "check_auth();" - it goes through un-
authenticated (a bug I have many times fixed while integrating php
You can of course use auth modules in frameworks like Catalyst. These
are more secure than doing it in your own application, but you are
still running it in the same process, memory space etc - it is really
better to do authentication before that.
One final thing before summary - one of my integration tasks I had to
do involved a Java application on Tomcat. I had to provide it
authentication (single sign on to the existing products) and modify
the output (filter) - both were easy thanks to doing it in mod_perl.
* Separate security - completely from your code. Your code can't even
execute unless security passes
* Separate authentication from your application to allow you to mix
applications. Don't keep re-inventing the wheel by writing yet another
job tracking system just so you can use your authentication.
* Write reusable and testable code - the authentication module should
be potentially reusable by other bits of code, even in other languages.
* Avoid binding yourself to a system or language. If you write your
code to be portable (e.g. Perl on Windows & Linux & Mac) you find that
your code style and reliability improves. If you build your system
(eg. authentication) to depend on perl - that makes it hard when you
want to incorporate a good PHP, or Python module.
More information about the Melbourne-pm