List Info

Thread: RFC: make ActionClass less ugly or implement Secure attribute in base Action




RFC: make ActionClass less ugly or implement Secure attribute in base Action
user name
2006-10-20 22:12:47

This afternoon, I implemented a Catalyst:ispatchT
ype::Secure, which  
filters actions and denies execution to actions with the
Secure  
attribute that are being executed over an insecure
connection (based  
on $c->req->secure).  mst "suggested" that
this would be better  
implemented as an ActionClass.

A first look of the Secure DispatchType is available at
http:// 
scsys.co.uk:8001/4608 ...though it is not ready for use.

While I agree that the ActionClass is an ideal venue for
"filters"  
such as this (which would overload match(), for example), I
can't  
quite bring myself to type "ActionClass('Secure')"
rather than just  
"Secure" every time I want to ensure an action is
only matched/ 
executed if the connection is being made over SSL.  It's
just too ugly!

I have two recommendations to propose:

(1) The Secure attribute should be implemented in the same
way as  
Args is, in the base Catalyst::Action::match function.  It
should  
take as an argument the action to forward to upon failure to
secure  
the connection, or no arguments if it should fail silently. 
It  
should not actually rewrite the URL and redirect to an HTTPS
server,  
but rather the action that it forwards to (in its argument)
should do  
that, which can be implemented by the user.

(2) If you do not want to implement the Secure attribute in
the core,  
I propose that ActionClasses be detected, in addition to
ActionClass 
('SomeName'), as an attribute with just their name.  For
example, if  
I created a really simple Secure ActionClass that just acted
as a  
filter, shown below, I could make an Action be of this
ActionClass by  
simple specifying: sub myaction : Global Secure { ... },
rather than  
having to type sub myaction : Global ActionClass('Secure') {
... }.

This would pose the potential for naming conflicts.  So,
when such  
conflicts arise, I propose that the first ActionClass that
matches  
the attribute be used.  When I say "first", I
mean: "Recurse down the  
tree of Catalyst:ispatchT
ype and Catalyst::Action inheritance, and  
prefer the DispatchTypes  before ActionClasses, and the
first  
ActionClass closest to the base C::Action" when parsing
the attributes.

Cheers,
Ido Rosen

A super-simplistic Secure ActionClass (untested):

   package Catalyst::Action::Secure;
   use base 'Catalyst::Action';

sub execute {
     my $self = shift;
     my ($controller, $c ) = _;

     if ($c->request->secure) { # if secure, proceed
without question.
       $self->NEXT::execute( _ );
       return 1;
     } else { return 0; }
}


_______________________________________________
Catalyst-dev mailing list
Catalyst-devlists.rawmode.org
http://lists.rawmode.org/mailman/listinfo/catalyst-dev

[1]

about | contact  Other archives ( Real Estate discussion Medical topics )