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

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

NAME

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

SYNOPSIS

               use Catalyst qw/
                       Authentication
                       Authorization::Roles
                       Authorization::ACL
               /;

               __PACKAGE__->setup;

               __PACKAGE__->deny_access_unless(
                       "/foo/bar",
                       [qw/nice_role/],
               );

               __PACKAGE__->allow_access_if(
                       "/foo/bar/gorch",
                       sub { return $boolean },
               );

DESCRIPTION

       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 moment.

       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.

METHODS

allow_access_if
Arguments: $path, $rule

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

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.

allow_access_if_any
Arguments: $path, \@roles

Same as above for any role in the list.

deny_access_unless
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.

deny_access_unless_any
Arguments: $path, \@roles

Same as above for any role in the list.

allow_access
deny_access
Arguments: $path

Unconditionally allow or deny access to a path.

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

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

__PACKAGE__->acl_add_rule(
"/foo",
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).

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

acl_access_allowed
Arguments: $c, $class, $action

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

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

EXTENDED METHODS

   execute
       The hook for rule evaluation

   setup_actions

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 permitted.

PATHS

       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 output.

       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 "/moose/bar").

       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 applied.

RULES

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.

Constant
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:

__PACKAGE__->acl_add_rule(
"/foo",
sub {
my ( $c, $action ) = @_;

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

HANDLING DENIAL

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

       acl_access_allowed
           A no-op

       acl_access_denied
           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 exception.

       forcibly_allow_access
           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 ) = @_;

               ...
               $c->forcibly_allow_access
                   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 exception).

AUTHOR

       Yuval Kogman <nothingmuch@woobling.org>

CONTRIBUTORS

       castaway: Jess Robinson

       caelum: Rafael Kitover <rkitover@cpan.org>

COPYRIGHT & LICENSE

       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.

perl v5.34.0                                       2022-06-09             Catalyst::Plugi...horization::ACL(3pm)