Re: Structuring multiple CGI::Application modules II

I think you've got your design backwards. You're trying to go to the home page first. Generally, the steps are:

User goes to the website.
User is presented with a login page.
User enters credentials (username/password, generally).
User hits submit.
Server validates credentials
1. If invalid, server re-sends login page with useful-ish error message
2. If valid, server sends home page. Server also sets cookie to indicate user has logged in successfully
All other pages check for existence of cookie. If cookie isn't there, redirect to login page.

This means that your cookie-checking method is in the base class. Your pages are in the child classes. cgiapp_prerun() will call your cookie-checking method to determine if it should redirect to the login page or not. The runmode method won't even be executed unless the cookie is there and has been verified.

Generally, one has one C::A child to do logging in, logging out, password changes, etc. Then, you have a few other C::A children that do actual content generation. So, you'd actually have two CGI scripts - one for login and one for show_survey. Both would inherit from your baseclass.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

Comment on Re: Structuring multiple CGI::Application modules II

Replies are listed 'Best First'.
Re^2: Structuring multiple CGI::Application modules II by Anonymous Monk on Jun 28, 2004 at 22:19 UTC
Thanks for the feedback. Evidently I haven't explained what I'd like to do well enough. The code fragments provided so far do not follow the design I want or are missing pieces that I need to understand the implementation. I want interchangeable C::As. Following your suggestions, The ideal 'base' module would provide optional Apache::Session support and private logging functions. There could be several 'login' C::As. I can think of at least three different authentication methods. The 'content' C::As don't know or care what type authentication is being used, only that the user is authorized. The problem is, the 'login' C::As must know what 'content' C::A to redirect to. I'm assuming that this will have to be done through either C::A parameters or CGI data passed through the CGI script that invokes the 'login' C::A. What would be the appropriate place to perform the redirect to the 'content' C::A? Create a 'content' runmode in the 'login' C::A and force that runmode once the login succeeds? It would seem that I should go back to my original code from my first post and move the redirect from teardown() to the end of my validate() sub as you did in your Re: Re: Re: Why CGI::Application? example. The only difference is that mine will be a redirect to a different C::A whereas yours was internal. I don't think the 'content' C::As needs to redirect to 'login'. Giving a "User not authenticated" message is sufficient. Based on these specs I don't think cgi_prerun or cgi_init methods are really necessary in my C::As, at least not for redirection.	[reply]
Re^3: Structuring multiple CGI::Application modules II by dragonchild (Archbishop) on Jun 29, 2004 at 02:30 UTC
The redirect can also be external. Just issue a 302 to the appropriate controller CGI script. Remember - C::A is just a fancy way of handling multiple requests in the same CGI script. If you read the rest of my replies in Why CGI::Application?, you'll see that I had some 4-5 different CGI scripts, each handling a different type of content, with a master script handling login functionality. So, do something like: Go to the login runmode. User enters credentials. The validate function does "The Right Thing"(tm). (Probably determined by a CGI parameter.) It then issues a 302 to the appropriate content-handling CGI script. This would be determined by a CGI parameter. ------ We are the carpenters and bricklayers of the Information Age. Then there are Damian modules.... sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon.* - flyingmoose I shouldn't have to say this, but any code, unless otherwise stated, is untested	[reply]


Welcome to the Monastery
	PerlMonks