"One approach is to nest CGI::Applications within each other. Then put authorization on the individual C::As"

I see that this would be the prefered way when your individual C::As implement a functionality which requires new run-modes anyways or you don't mind overwritting/rewriting some runmode with altered functionality. But that's exactly where my problem is:

In my guestbook example I want to come around having to overwrite or rewrite the view method, just to add that extra piece of information (showing the IP of the poster, and maybe adding a link to the "delete" run-mode). I don't see a way of accomplishing that with creating an additional C::A (but maybe I shouldn't be that lazy?)

Besides from that other C::A part my strategy in regards to authentification and authorization goes a very similar way as described in Re: Why CGI::Application?.
Instead of having the intance script calling another C::A, my instance script enables the accessible run-modes via the enable_rm_set('X', 'Y', 'Z') method. If a user tries to call one of the restricted run modes (rm=delete in this example), he run's into the same error as when calling it from a different C::A. In both cases, the C::A does not know the called run mode.

"In general I'd suggest that scattering authorization logic around is somewhat fragile"

Agreed, but in a case like this the only required steps is to check if a privileged "run-mode set" has been loaded and if authentification has been performed.

The first is set in the enable_rm_set() by setting $self->param("run-mode set" => '1').

The second is done only in the "delete" run-mode (out of laziness, to spare me copying the admin.pl to a secured and unsecured area on the webserver, and having to type the different links). It really should be placed into the setup() like this:

    if ($self->param('RESTRICTED')) {
        return _no_auth() unless defined($ENV{UserName});
    }
[download]

This should catch configuration mistakes in regards to authorization, e.g. if one forgot to enable access control to the admin.pl. This is following the logic of "if there was no authentification there can't be authorization, as we know it should be restricted in someway (not caring about the specific groups/users to be allowed)".

The only "scattering of authorization logic" happens in the view run mode when adding those extra bits of information for the admin mode:

if ($self->param('RESTRICTED')) {
    # add the infos for admins only
}
[download]

But that's the goal I am going for in this case.

In the end it seems to come down to:

Is there a way of achieving this (not having to overwrite/rewrite the view for that extra bit) without that bit of "authorization logic scattering"?

If not, is this prize to pay a fair one or shall I better forget about the first point at all?