Of course Ovid's CGI Course would be a great way to start. You could write your own security module (or use any of the many available on CPAN), yet you could also just take a look at Apache's abilities to handle this (and some "easier" notes). If you use Apache, that is.

A login form's role is to _authenticate_ a user as one trusted to use resources behind the web form. The next step is to check whether a logged in user to is _authorized_ to access a particular resource. As your applications grow, you may find that some legitimate users should have access to some functions that should not be made available to others.

You'll need a way to secure the connection over which the authentication (and any subsequent transmittal of private data) takes place. And a way to preserve the session, that is, to know that the next http request from your authenticated and authorized user is just as legitimate as the last one.

I'm still experimenting with what approach I find easiest to work with.

For secure connections, I use apache-ssl for its encrypted connections. I earlier rejected the apache .htaccess methods suggested by another responder because it passes plain text tokens in the clear, before creating the ssl connection. I prefer my login screens protected by encryption. If the data is really worth protecting, then there is no sense in exposing it to the vulnerability of snooped passwords on the login screen.

For similar reasons, I mistrust cookies and hidden form values as they expose your session management to user manipulation. While I'll pass a token back and forth, it would not contain anything other than the session ID. Where security matters, I would choose to store all other session data on the server, related to the session ID.

My latest experiment with a secure login front end to a multi-function cgi script starts out:

use DBIx::UserDB;
use DBIx::SearchProfiles;
use CGI qw(:standard);
use CGI::SecureState;
use CGI::Carp qw(fatalsToBrowser);
use WWW::Authenticate_he;
[download]

-- Hugh

use CGI;
my $cgi = new CGI;

my $user = $cgi->param("username");
my $pass = $cgi->param("password");
my $valid = 0;

# Assuming usernames/passwords in a delimited text file
open(IN, "passwordFile") or die(...);
while(<IN>) {
  if( /^$user\:$pass$/ ) {
    $valid = 1;
    last;
  }
}
close(IN)

if(!$valid) {
  print "Sorry, you may not access this page.";
  exit;
}

#set authentication
#set a cookie here using javascript 
   or
#add hidden fields with login info
print "<input type='hidden' name='pass' value='...'>";
print "<input type='hidden' name='user' value='...'>";


Store usernames/passwords in a file as follows:
johndoe:myPassw0rd
user2:pass2
user3:pass3
etc
[download]

Your skeleton is most helpful in giving me an idea of the process when using Perl/CGI (Perl is the first language I am learning). The login does not have to be too secure as it is just for my family members to view my online photo album (and an excuse to learn/use Perl). I have not used cookies or hidden fields yet, but I have a Perl book that references them. Which would you recommend I try first (i.e. which is simple to put together). Thank you.

I personally use Apache2, with Mason, and mod_perl2, while mod_perl2 is only in dev it seems to perform just as well now as mod_perl.

My login script consists of a simple sql lookup on a users table. If found, I create a new session using Apache::Sesssion::Postgres and then set a cookie such that its value is the session's id.

Then in an autohandler in a folder named /auth_required/ or the like, I check for a cookie using Apache2::Cookie and then I check the cookie's value $cookie->value to make sure the value or session id does exist in my session table (you create this to use anthing Apache::Session::*). If all is there I move on.

I save the session to a global variable $S, and the user data to a global variable $U to eliminate the need to pass it explicitly to other mason components.