|Do you know where your variables are?|
Re: Persistent login session with restricted accessby Anneq (Vicar)
|on Oct 10, 2004 at 14:06 UTC||Need Help??|
I use CGI::Application and Template::Toolkit to do the heavy lifting. Instead of giving you the code, I'll give you a description of how I approached the same problem (http://artwest.ca). If you write it yourself, you'll have a much better understanding of it.
CGI::Application - setup():
My C::A setup() has two run modes, one for login/register validation and one for everything else. Also in setup(), I open up a config file and bring in some default variables.
CGI::Application - cgiapp_prerun():
First, an existing session is opened or a new one is created, depending on the presenence of a session cookie in the request. The new or existing session id is then set in the outgoing HTTP header. If the run mode is set to 'logout', the session param 'logged_in' is set to false, the user security level is set to the lowest, and the run mode is reset to default. If the run mode or any other desired query or session parameters are not set, they are now set to their default values. Lastly, a sub in a separate module is called to do things if the user selected to change one of their display preferences (e.g., font size or theme color).
C::A - validate():
This run mode calls a sepatare module to validate a login or registration request and retuns a message if errors occurred. The authentication module logs in or registers the user if appropriate. validate() then calls a sparate module to build the page, including any login or registration errors, and a web page is returned (the page returned depending on user's security level).
C::A - normal():
This method calls a sparate module to build the page, and a web page is returned (the page returned depending on user's security level).
I use TT for page layout and to automatically build navbars. With TT, its easy to place a login form (or a logout url) on every page. As well, if you store your registration information in tables, TT's DBI plugin simplifies administering registration information. TT has a great O'Reilly book that I would recommend purchasing. Having the reference has sped up my development time and reduced my pain significantly.
I use a simple table of security levels per each major content section. So the user must have the same or greater security level then the content section in order to view the requested page. To prohibit access to content other than through my index.cgi script, I use .htaccess files in protected directories.
I hope this gives you some idea where to start. Note, however, that I'm not a professional programmer or web developer so there are bound to be some security problems or better ways to do it.