it's more the method I am struggling with.

So, you've got these great, well tested libraries of code, but you're having trouble getting them to all work together. Its the same problem we've all faced our first time trying to build a performant, reliable web service. Thankfully, the many before us have helped us solve this problem too.

Check out CGI::Application. This library provides a framework and conventions so the other libraries you've mentioned have a very basic use case. With this library, you get plugins like CGI::Application::Plugin::Authentication, so you almost don't even have to think about the seemingly simple / deceptively difficult task of authorizing a person to access a resource on the web. Heck, it even gives you a login form so you don't even have to write html. If the defaults suit your tastes, you're not even really writing code, you're just doing configuration.

In other words, you're looking at the right tools, but there are even more tools out there that make it easy to use these tools. Even if you're unsure how to use these tools right away, keep at it. Its a near certainty that using these tools are going to give you a cleaner, less buggy, more secure implementation.

Have you considered using HTTP auth? If you can't use cookies, it's quite a nice way of doing authentication. You can probably just tell Apache to do it and keep all the authentication stuff out of your Perl scripts. (Hardest part is teaching Apache your database structure so that it can check the passwords.)

HTTP auth can be implemented in Perl too, but CPAN seems to have a dearth of modules to do it for you. (There are some for Catalyst and Plack, but not classic CGI.)

HTTP auth can be implemented in Perl too, but CPAN seems to have a dearth of modules to do it for you. (There are some for Catalyst and Plack, but not classic CGI.)

Right, because classic CGI ( as in mod_cgi, http://tools.ietf.org/html/rfc3875 ) , doesn't provide for external programs to perform authentication (it will strip any Www-authenticate headers) -- its a limitation of CGI

You can work around it in apache by

compile Apache with -DSECURITY_HOLE_PASS_AUTHORIZATION option,

use mod_rewrite to pass the Authorization header to the application with the rewrite rule like following (see Plack::Middleware::Auth::Basic)

use mod_perl

use fastcgi configured with "-pass-header HTTP_AUTHORIZATION "

..timing out the users session...

Read the perldoc for CGI::Session, not just the first part of it, but the entire thing like the section on the expire() method.

...The problem I have then is ... and/or stopping anyone logging in with the same id....

CGI::Session stores things about the connecting session, hence you will know the IP address of the client that created the session and can, whenever validating that session on every subsequent request, check it again. If it is not the same then deny the request (see remote_addr() in the perldoc).

 if( not $foo->loggedInYouKnow ){
    $foo->NiceTryNoBypassSeeLoginPage();
} else {
    $foo->SeeSomePage();
}
[download]

Thanks for the replies.
I am still a little confused what would happen if someone opened another browser tab(while logged in to the site correctly) and typed in a URL of a page behind the login page. Because I can't store cookies and there wouldn't be any session ID in the URL wouldn't the page look for authencication again? Wouldn't this annoy the user?
Again, sorry for sounding dumb but I've been looking at this for most of the day and my brain is about to leak out of my eye sockets!

It may annoy the user, but it's the proper behavior (if this is the way you're doing authentication). If all you have to go on is URLs and maybe hidden fields in POSTs, then "another browser tab" is pretty much the same as "another browser" or "a browser on another computer" for all the state it's communicating up to your server.

HTTP doesn't really give you that many levers to pull on for tracking state between requests; it's either in the headers or in the body. "Encoded into the URL" counts as "headers", "hidden field in a POST" counts as "body", and about the only other thing you have is "cookie", which is a header. And cookie is the only one that the browser itself knows anything about between requests.

To me, that boils down to: If you're not able to use cookies, you'll need to figure out a way to spin this "annoyance" as a "feature".

Just to add to what mcdave said, if you are in an environment where no cookies are allowed then surely your users are aware of this so it's fair enough to tell them that opening a new tab or whatever won't work. I don't really understand why they would do this unless they knew how to construct the correct URL. Maybe they know the IDs of what they are looking for and want to tack that onto the end of the generic URL? If so then if you put the session id parameter before all other parameters in your URLs then the browser's auto-complete function will include it before the bit the user wants to replace - just might work.