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.