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 it's 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 $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.

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

acl_add_rule $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).

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 begining 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( "/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 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.

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;
                        }
                }
        );

SEE ALSO

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

AUTHOR

Yuval Kogman, nothingmuch@woobling.org Jess Robinson

COPYRIGHT & LICENCE

        Copyright (c) 2005 the aforementioned authors. All rights
        reserved. This program is free software; you can redistribute
        it and/or modify it under the same terms as Perl itself.