http://qs321.pair.com?node_id=370354


in reply to Re: Structuring multiple CGI::Application modules II
in thread 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:
    1. Go to the login runmode.
    2. User enters credentials.
    3. The validate function does "The Right Thing"(tm). (Probably determined by a CGI parameter.)
    4. 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