Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

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

by Anonymous Monk
on Jun 28, 2004 at 22:19 UTC ( #370354=note: print w/replies, xml ) Need Help??

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

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://370354]
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (3)
As of 2023-12-10 04:55 GMT
Find Nodes?
    Voting Booth?
    What's your preferred 'use VERSION' for new CPAN modules in 2023?

    Results (38 votes). Check out past polls.