Provided by: libcatalyst-plugin-authorization-acl-perl_0.16-1_all bug


       Catalyst::Plugin::Authorization::ACL - ACL support for Catalyst applications.


               use Catalyst qw/



                       sub { return $boolean },


       This module provides Access Control List style path protection, with arbitrary rules for
       Catalyst applications. It operates only on the Catalyst private namespace, at least at the

       The two hierarchies of actions and controllers in Catalyst are:

       Private Namespace
           Every action has its own private path. This path reflects the Perl namespaces the
           actions were born in, and the namespaces of their controllers.

       External Namespace
           Some actions are also directly accessible from the outside, via a URL.

           The private and external paths will be the same, if you are using Local actions.
           Alternatively you can use "Path", "Regex", or "Global" to specify a different external
           path for your action.

       The ACL module currently only knows to exploit the private namespace. In the future
       extensions may be made to support external namespaces as well.

       Various types of rules are supported, see the list under "RULES".

       When a path is visited, rules are tested one after the other, with the most exact rule
       fitting the path first, and continuing up the path. Testing continues until a rule
       explcitly allows or denies access.


       Arguments: $path, $rule

       Check the rule condition and allow access to the actions under $path if the rule returns

       This is normally useful to allow acces only to a specific part of a tree whose parent has
       a "deny_access_unless" clause attached to it.

       If the rule test returns false access is not denied or allowed. Instead the next rule in
       the chain will be checked - in this sense the combinatory behavior of these rules is like
       logical OR.

       Arguments: $path, \@roles

       Same as above for any role in the list.

       Arguments: $path, $rule

       Check the rule condition and disallow access if the rule returns false.

       This is normally useful to restrict access to any portion of the application unless a
       certain condition can be met.

       If the rule test returns true access is not allowed or denied. Instead the next rule in
       the chain will be checked - in this sense the combinatory behavior of these rules is like
       logical AND.

       Arguments: $path, \@roles

       Same as above for any role in the list.

       Arguments: $path

       Unconditionally allow or deny access to a path.

       Arguments: $path, $rule, [ $filter ]

       Manually add a rule to all the actions under $path using the more flexible (but more
       verbose) method:

               sub { ... }, # see FLEXIBLE RULES below
               sub {
                   my $action = shift;
                   # return a true value if you want to apply the rule to this action
                   # called for all the actions under "/foo"

       In this case the rule must be a sub reference (or method name) to be invoked on $c.

       The default filter will skip all actions starting with an underscore, namely "_DISPATCH",
       "_AUTO", etc (but not "auto", "begin", et al).

       Arguments: $c, $class, $action, $err

       Arguments: $c, $class, $action

       The default event handlers for access denied or allowed conditions. See below on handling
       access violations.

       Adds rules that permit access to the root controller ( "auto", "begin" and
       "end" unconditionally.


       The hook for rule evaluation



       When a rule is attached to an action the "distance" from the path it was specified in is
       recorded. The closer the path is to the rule, the earlier it will be checked.

       Any rule can either explicitly deny or explicitly allow access to a particular action. If
       a rule does not explicitly allow or permit access, the next rule is checked, until the
       list of rules is finished. If no rule has determined a policy, access to the path will be


       To apply a rule to an action or group of actions you must supply a path.

       This path is what you should see dumped at the beginning of the Catalyst server's debug

       For example, for the "foo" action defined at the root level of your application, specify
       "/foo". Under the "Moose" controller (e.g.  "MyApp::C::Moose", the action "bar" will be

       The "distance" a path has from an action that is contained in it is the the difference in
       the number of slashes between the path of the action, and the path to which the rule was


   Easy Rules
       There are several kinds of rules you can create without using the complex interface
       described in "FLEXIBLE RULES".

       The easy rules are all predicate list oriented. "allow_access_if" will explicitly allow
       access if the predicate is true, and "deny_access_unless" will explicitly disallow if the
       predicate is false.

       Role Lists
             __PACAKGE__->deny_access_unless_any( "/foo/bar", [qw/admin moose_trainer/] );

           When the role is evaluated the Catalyst::Plugin::Authorization::Roles will be used to
           check whether the currently logged in user has the specified roles.

           If "allow_access_if_any" is used, the presence of any of the roles in the list will
           immediately permit access, and if "deny_access_unless_any" is used, the lack of all of
           the roles will immediately deny access.

           Similarly, if "allow_access_if" is used, the presence of all the roles will
           immediately permit access, and if "deny_access_unless" is used, the lack of any of the
           roles will immediately deny access.

           When specifying a role list without the Catalyst::Plugin::Authorization::Roles plugin
           loaded the ACL engine will throw an error.

       Predicate Code Reference / Method Name
           The code reference or method is invoked with the context and the action objects. The
           boolean return value will determine the behavior of the rule.

               __PACKAGE__->allow_access_if( "/gorch", sub { ... } );
               __PACKAGE__->deny_access_unless( "/moose", "method_name" );

           When specifying a method name the rule engine ensures that it can be invoked using
           "can" in UNIVERSAL.

           You can use "undef", 0 and '' to use as a constant false predicate, or 1 to use as a
           constant true predicate.

   Flexible Rules
       These rules are the most annoying to write but provide the most flexibility.

       All access control is performed using exceptions -
       $Catalyst::Plugin::Authorization::ACL::Engine::DENIED, and
       $Catalyst::Plugin::Authorization::ACL::Engine::ALLOWED (these can be imported from the
       engine module).

       If no rule decides to explicitly allow or deny access, access will be permitted.

       Here is a rule that will always break out of rule processing by either explicitly allowing
       or denying access based on how much mojo the current user has:

               sub {
                   my ( $c, $action ) = @_;

                   if ( $c->user->mojo > 50 ) {
                       die $ALLOWED;
                   } else {
                       die $DENIED;


       There are two plugin methods that can be called when a rule makes a decision about an

           A no-op

           Looks for a private action named "access_denied" from the denied action's controller
           and outwards (much like "auto"), and if none is found throws an access denied

           Within an "access_denied" action this will immediately cause the blocked action to be
           executed anyway.

       This means that you have several alternatives:

   Provide an "access_denied" action
           package MyApp::Controller::Foo;

           sub access_denied : Private {
               my ( $self, $c, $action ) = @_;

                   if $you->mean_it eq "really";

       If you call "forcibly_allow_access" then the blocked action will be immediately unblocked.
       Otherwise the execution of the action will cease, and return to it's caller or end.

   Cleanup in "end"
           sub end : Private {
               my ( $self, $c ) = @_;

               if ( $c->error and $c->error->[-1] eq "access denied" ) {
                   $c->error(0); # clear the error

                   # access denied
               } else {
                   # normal end

   Override the plugin event handler methods
           package MyApp;

           sub acl_access_allowed {
               my ( $c, $class, $action ) = @_;

           sub acl_access_denied {
               my ( $c, $class, $action, $err ) = @_;

       $class is the controller class the $action object was going to be executed in, and $err is
       the exception cought during rule evaluation, if any (access is denied if a rule raises an


       Catalyst::Plugin::Authentication, Catalyst::Plugin::Authorization::Roles,


       Yuval Kogman <>


       castaway: Jess Robinson

       caelum: Rafael Kitover <>


       Copyright (c) 2005 - 2009 the Catalyst::Plugin::Authorization::ACL "AUTHOR" and
       "CONTRIBUTORS" as listed above.

       This library is free software; you can redistribute it and/or modify it under the same
       terms as Perl itself.