This is how we handle those phases within CGIP:

authenticate: the server does this for us, and gives us the userid;

authorize: create an authorize method that lets them through or doesn't and put it in app_enter since this is 'front door':

sub app_enter {
  my $self = shift;

# Check auth at the app-level. If they don't pass, they don't
# get in.

  if ( not $self->authorize() ){
    die [user_error => "Not authorized."];
  }

}
[download]

We have a die handler that will catch that error and put up a nice page. The die handler always calls the same default 'info_page' and displays the message you send. You may need something fancier, but this has served us so far.

As I mentioned in a post to your other topic, we put our validate hook in respond_per_app so we can allow CGIP handle the page dispatch.

So if we make it to respond_per_page, we know we're good and we can to the 'execute' part. For us, this usually means putting some data in the database. The last part of this method is to return the page object that you want to user to go to next. CGIP will then go to that page and try to render (and render_enter_per_page). So if you finish respond_per_page with something like:

  return $self->name_to_page('next_page_name');
[download]

CGIP will try to render that page next.