This is slightly more complicated than it seems.
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;
WWW::Authenticate_he is my adaptation of WWW::Authenticate. I'd suggest you check out the DBIx modules listed above, as well as CGI::SecureState and WWW::Authenticate. Those just may prove useful to you.
-- Hugh
|