|Just another Perl shrine|
I'm not sure exactly what type of answer you are looking for, but I'll see what I can do.
First off -- no, it doesn't seem like you are missing anything. Secondly, there's no need to redo what's already been done. Unless you really believe you can do it better. In which case, highly consider adding onto the existing solution instead of re-implementing it. When it comes down to it, most people would agree to do these things when creating web applications:
No one will argue this. If you aren't using CGI.pm, you're asking for trouble.. both from you application, and us because we'll yell at you ;-)
Apache::Session will help create and manage you're sessions. It'll create unique session id's for you, you don't have to worry about that. In fact, I don't one should ever try and create session ID's on your own, there are too many ways to do it incorrectly and insecurely :-) However, as far as I know, there isn't yet a module to manage expiring of sessions, you'll most likely have to do that on your own. But thats easy enough if you store the last time a person was at the site in your database. Next time they connect, if the time is more then 30 minutes or whatever, just redirect them to the login page.
Even people within your building are capable of sniffing passwords. There are tools that do all the work for them. I would highly recommend doing something.. anything.. to make sure the passwords are not sent in clear text. Even internally.
A point that I'll argue -- and there are definitely two (often religious) sides to this -- is that I feel one should always use some sort of templating system to create HTML templates when developing web applications. This seperates code from content. There are several available, HTML::Template and Template::Toolkit, to name 2. And then where CGI.pm comes in is to handle the input, sending out headers, and that sort of thing.
Perhaps there are times to use CGI.pm for generating content. But I personally feel that using CGI.pm for this purpose would create messy applications, even if they do end up creating correct HTML ;-) But the point to argue there is that there are plenty of HTML validators you could use to validate your HTML code if you wanted to use a template. But in the end, it's your choice :-)