I don't use CGI::Application, but my approach would be to make the legacy code into CGI::Application::Pluggable instances and use a hacked ->cgiapp_prerun method to handle the login tangent depending on the target. "If it's in a module, it's not a hack".

That still leaves you with The One Class though, but maybe you can turn that inside out by making your authorization step into a plugin and using that plugin from the several legacy apps.

Disclaimer: I use basic authentication and TinyAuth to handle access to my apps, so I'm not really qualified to comment on how to put authentication into your application.

So, create a base class called My::App::WithLogin that inherits from My::App::Base which provides a cgiapp_prerun that checks for being logged in. Then, have your areas that require authn to use that. If they require a different kind of login, create another base class that inherits form My::App::WithLogin called My::App::WithSpecialLogin.

Remember - nothing says that all your children have to inherit from the same base class. You can have a hierarchy of base classes for the leaves that are all at the same conceptual level.

package Alex2::CGI::Admin;

use strict;
use warnings;

use base 'Alex2::CGI';

sub setup { 
    my $self = shift;
    $self->run_modes( [ 'main' ] );
    $self->start_mode( 'main' );
}

sub cgiapp_prerun { 
    my $self = shift;

    $self->SUPER::cgiapp_prerun( @_ );

    $self->run_modes( [ 'unauthorized' ] );

    unless( $self->user->admin or $self->user->group_admin ) { 
        $self->prerun_mode( 'unauthorized' );
    }

    # group admins can only use certain tools
    if ( $self->user->group_admin and !$self->allows_group_admin ) { 
        $self->prerun_mode( 'unauthorized' );
    }
}

....
[download]

Our CGI::Application app has a couple of main sections, so I made a base class for each that contains all of the housekeeping I need for that area's subclasses: setup, teardown, cgiapp_init, cgiapp_pre/postrun, etc. Our auth stuff is in cgiapp_prerun.

In each subclass, I then "use base" the appropriate area's parent class, which gets me the auth & housekeeping stuff, override any functions (setup, for example) that need to be tweaked for the subclass, and add all the meat for the particular area of the app that subclass handles.

(Sorry I don't have time to go into a lot of detail, but hopefully this will get you pointed in a useful direction. I'll be out of town from tomorrow through the weekend, but I'd be happy to provide more info when I return.)

Edit: I should add that when I do the auth checks in cgiapp_prerun, I simply redirect to the login page if necessary, stashing away the intended URL in the database so the user can be redirected there after they sign in. This way I can keep the login handling routines themselves in their own tidy little module.