timmey, I am no expert on this as I just figured it out for myself, but I'll give it a shot. Please keep in mind that my site is in the development stage and is not being used yet. Nevertheless, here's what I'm doing. Perhaps other, experienced monks will correct anything wrong if I unwittingly lead you astray.
So my question is, where would i put the different stuff? in what subs? would i put it in cgi_prerun? Because i don't want to automatically redirect the unregistered users to a register page when they come to the page, they'll have to click the register button first.
I open my databases in setup(). As seen above in a previous post, cgiapp_prerun() is used for session and cookie creation. The only other time I alter session information is after a successful login or registration which sets the 'loggedin' session parameter to true. And that's all there is to session management on my site. teardown() is used to disconnect databases. And so far I have a runmode that validates logins and registrations and a runmode for all other pages.
There is a small box on each page of my site, that is used to display information about the current page or section, but also is used to allow logins and logouts. From that box, you can login, go to the register page, or to have your login reset if you forgot the details. Once you are logged in, the box displays a welcome (only directly after a login or registration), allows you to logout, or change your display preferences.
I put all the authentication stuff, namely form creation (login and registration), form validation and password digest generater in a separate authentication module. I fooled around with validation for a while until I came upon Data::FormValidator. D::FV greatly reduced my lines of code and made code maintenance way easy. Also, I don't make the user login after registering, I just set their session 'loggedin' param to true. Obviously the registration page code comes before the login code so it knows what to display in the the information box.
My database functions all go into the same module. Each database function is passed only one parameter, the CGI::Session object. This gives me access to the CGI.pm object, CGI::Session object, and database handles, when I need them. Once I stumbled upon this, things started coming together for me.
The whole page comes together with a separate module that pulls page components into a template for use with Template Toolkit. Every page is made up of a banner (with a site-wide navbar), footer, left navbar (section specific), and right information box. My section-specific navbars are created automatically based on information stored in a database. That makes it easier to add pages. Now I just create the page, and then add an entry to the database, specifying the applicable section, and other pages specific stuff.
In the same content database, I store an authorization level for each page. My cgi output module checks to see if the user's authz level matches or exceeds that of the page. To handle authz of newly registered users, they all get set to the lowest. And I get an email when a registration occurs. (Actually, the email thing is not yet implemented.) If I see an email address registered that belongs to one of our members or executive, I send them an email asking if they registered, and if so, I up their authorization level. Obviously we don't have a huge membership base or I would have to automate it.
and also, how do i store the session stuff in the mysql table? i mean, does the Driver:mysql take care of it? what if i want more fields? how do i store stuff in them?
Stupidly easy to use. Ahhh....once you figure it out, that is. I don't even bother with a database. Just tell it what tmp directory to use and it automatically creates a session file. If you change a session parameter, it automatically stores it. Incredible. If you want another field, add a parameter like so: $session->param(-name=>'new', -value=>'value');. One thing I'm still thinking about is when to get rid of old session files. I haven't looked into this much so can't help you there yet.