Which isn't to say that there's not a better way, but this is a big factor to consider for any reasonably large web site. Which most sites aren't, so, there you go.

Using Apache:: modules doesn't imply any specific storage mechanism. It's about how you tie into the server's request pipeline, not about what you do once you're there.

Hello,

You argue that CGI-based authentication requires a lot of attention from the programmer, and that you need to ensure that you don't miss any execution path... But this all can be solved in the application desgin before you delve into the code.

Here's one of the ways I would tackle this:

You need users and groups of permission, even if you seem not to need groups, you need at least two groups: visitor, and user. The visitor group has the permission to read some pages only, it is the default group and only contains one user (the not-logged-in visitor). The "user" group has other types of permissions, and that's usually a logged in user.

In order to apply this, you need to always populate the permissions of the user on each request, so it will look like this:

# some initialization code.
$object->login();
# then you continue your application
$object->open_some_page();
# more stuff.
[download]

The login() method will check for parameters/cookies/etc.. and handle the sessions, AND it will populate some objects regarding the user login. ex: $object->{user}->{permission} contains the permission of the user.

Now wherever you need to perform operations that require permissions, you only need to check $object->{user}->{permission} cause you are sure that this contains the correct permissions wherever you are in the code, provided that you call login() as soon as you can.

Hope this gives you some more ideas to consider.

here is a good resource on web security and it covers the stuff you discussed in great detail http://www.technicalinfo.net/papers/index.html

On CGI authentication:

What you call CGI authentication, isn't. It is Query String or Post Data (usually with a Cookie for authentication of later requests) based. How the server deals with that data is up to the programmer, CGI is only one option. (Others include mod_perl).

On putting authentication outside the application logic:

While Basic/Digest authentication is typically handled outside the application, and Post/Get authentication is typically handled by the application, this isn't a hard and fast rule. Mod_perl, for instance, allows you to specify a Perl module to handle authentication, this is outside the application logic and handled on a seperate layer by the server.

On the ability to log out:

Post/Get based authentication doesn't provide the user with a way to log out. It provides the programmer with a way to log the user out. Basic/Digest authentication requires the browser programmer to provide a logout feature (and most don't, although I hear Opera does).

It might seem like more potential for security holes having Application-level users, but it's really easy to misconfigure the web server and ruin the web server level authentication. Especially if the web server's configuration file format is the one that sets the ease of management standard - at the bottom end, that is.

As others have pointed out, the inability to logout of HTTP sessions without closing all your browser windows really sucks.

$h=$ENV{HOME};my@q=split/\n\n/,`cat $h/.quotes`;$s="$h/."
."signature";$t=`cat $s`;print$t,"\n",$q[rand($#q)],"\n";
[download]