[cgiapp] authentication and authorization callbacks

[B. Estrade]

On Tue, Nov 06, 2012 at 03:32:13PM -0500, Mark Stosberg wrote:
> 
> > You call init in BUILD, but then explicitly run down the callback list in 
> > the run() method. What I am wondering is if you could bridge the gap to the 
> > other side that would allow one to munge around with the *ordered contents 
> > of %CLASS_CALLBACKS.
> > 
> > my %CLASS_CALLBACKS = (
> > #   hook name          package                 sub
> >     init      => { 'PSGI::Application' => [ 'init'    ] },
> >     prerun    => { 'PSGI::Application' => [ 'prerun'  ] },
> >     
> > # for example, add
> >     authentication  => { 'My::PSGI::Application' => [ 'authentication'  ] },
> >     authorization   => { 'My::PSGI::Application' => [ 'authorization'  ] },
> > 
> >     postrun   => { 'PSGI::Application' => [ 'postrun' ] },
> >     teardown  => { 'PSGI::Application' => [ 'teardown'] },
> >     load_tmpl => { },
> >     error     => { },
> > );
> > 
> > Instead of me having to reimplement the run() method to provide for custom
> > top level callbacks, would it be possible to craft run() so that it took
> > %CLASS_CALLBACKS as ordered (e.g., if %CLASS_CALLBACKS was tied with 
> > Tie::Hash::Indexed) ?
> > 
> > Right now, it seems like I'd have to reimplement the run(), when all I really wanted
> > to do was insert top level callback classes wrt the order in which they are run.
> 
> Brett, I think this existing functionality would provide what you want:
> 
>  PSGI::Application->new_hook('authorization');
>  PSGI::Application->add_callback('authorization', \&callback);

Kind of, but what it doesn't allow me to do is affect the order in
which the lifecycle hooks are executed.  I think that I would also
have to make a ->call_hook('authorization'), when what I really want
to do is not only create the 'authorization' hook, but add it as a
bona-fide lifecycle event like 'init', 'prerun', etc and choose at
what point after 'init' is executed.

> 
> That would register a hook named 'authorization', and register a
> callback to fire the same as it would as if it were in the built-in hash.
> 
> Or have I misunderstood the request?

You're close.

> 
> If need-be, we could make %CLASS_CALLBACKS, replaceable, but I want to
> be first be clear that there's a need.

That's really a subjective call, and not mine to make. I think that
ultimately it'd be nice to be make the run() method general enough to
where you can have a custom hook executed there in an order of your
choosing, without having to call ->call_hook('foo') explicitly in your
PAP instance.

So, maybe something like this:

 PSGI::Application->new_hook('authorization','before','prerun');
 PSGI::Application->add_callback('authorization', \&callback);

Then run() would know due to some ordered notion of the default hooks
that ->call_hook('authorization') would effectively get called
'before' the 'prerun' hook.

I think of the hooks as stacks that contain registered callback
methods. You get 'init', 'prerun', etc for free. And yes, you can
create your own "stack" and registered callbacks to them. However,
sometimes it would be really convenient if you could insert your own
custom hook into the list of those that are implicitly called - it
might particularly make it easier for plugins to better manage when
and what they execute.

Ultimately, I just want a way to create my own top level hook 
and not have to ->call_hook when I could just slide it into the
lifecycle of events itself.

Thanks for your consideration.

Brett

> 
>    Mark
> 
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://lists.openlib.org/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://lists.openlib.org/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
> 

--