On every request to this script, authorize.
-- first look for and read the cookie, see previous. There should be at least two cookie values, user id and password (and you could do a third for the session id.)
-- if cookies are not present, look for form input values of user name and password.
if neither are present, return to log in screen.
-- if the cookie is present, the user id should be the numeric ID of the record; take this and the input values of the cookie set for password and compare against what you get from the database for password (see below.)
-- if the cookie is NOT present and the form values are present, you will be looking up not the record ID, but either the login name or email address and password, but also get the numeric record ID at this time. If this is found and validates, you now set the cookies using the record ID and the user password value (see below!) and next time it validates it will be using the cookie and won't need form values.
See important notes after #2 . . . .
I've always used the DBI module, there may be others but have never needed anything else. On any system with mySQL, it's always been in place, but you can install it via command line with: cpan DBI
About authentication: I'm by no means a "Security expert" but authenticating with passwords, whether you use a plain text or formal database, can take two "basic" forms.
The first, and probably easiest, is something you only want to do for low security, non-sensitive information. Do not do this if the login services are paid or contains any sensitive information.
On register, you create a record containing a unique numeric "user id," optionally a "login name," and email address, and a plain text password. There is only one reason you would ever do this: to allow a simple "retrieve password" function. If someone enters only the login name/email, you write a program that looks it up and emails them the login info. This has security vulnerabilities all over it, so it's very important you don't do this for anything serious. It's sufficient for say, portions of your portfolio you want to hide from the general public. Customer info, email addresses, no, not sufficient.
Only when the convenience of "retrieve password" is more important than security, which is rare.
When you set the cookie, you will set the md5 hash, or better yet, an md5 of the md5. :-)
You can't "decrypt" the md5. All you can do is compare one md5 against another:
testme -> md5 = 3skaffglgf56ffdkgdf
database -> 3skaffglgf56ffdkgdf
So in this scenario, you lose the retrieve password capability. This is fine. What you do is have a function that resets the password to something random and emails the end user the new password with instructions to reset it again after first login.
These are not "high security" methods and I'm posting them to lure better programmers into discussing their approaches. :-) It's been discussed that md5 is not all that secure, and is (relatively) easily broken by brute force attacks and there are more robust encryption methods. But for you as a beginner, it's easily accessible (part of the perl distro) and these provide a good foundation for you to start looking at a solid way to create a semi-secure login.
A last note on cookies themselves: Always make them expire, except in scenario 1, or make it an option to "remember me." The second is not a "great" idea . . . but sometimes user convenience wins out over security.