Re^2: Structuring multiple CGI::Application modules II

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.

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

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

Re^3: Structuring multiple CGI::Application modules II
by dragonchild (Archbishop) on Jun 29, 2004 at 02:30 UTC

Why CGI::Application?

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]