Skip to content
Go to file

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time


    Catalyst::Plugin::Authorization::Abilities - Ability based authorization
    for Catalyst/DBIx::Class apps, based on

            # In (notice we do not use Authorization::Roles):

            use Catalyst qw/

            __PACKAGE__->config->{abilities}->{super_user_id} = 1; # this is the default

            # Anywhere in your code
            sub delete : Local {
                    my ( $self, $c ) = @_;

                    # check if the user can perform a certain action,
                    # such as delete_foo, throw error if not.

            # Checking roles is also provided
            sub display_user : Local {
                    my ( $self, $c ) = @_;
                    if ($c->check_user_roles(qw/admin editor/)) {
                            print "User belongs to the admin and editor roles.";
                    } else {
                            print "User doesn't belong to both the admin and editor roles.";

            # Checkout required database schemas under REQUIRED SCHEMA

    Ability based access control is an extension of the role based access
    control available through Catalyst::Plugin::Authorization::Roles. In
    this plugin, however, every user has a list of actions he is allowed to
    perform, and every restricted part of the application makes an assertion
    about the necessary abilities.

    Abilities to perform certain actions can be given to a user
    specifically, or via roles the user can assume. For example, if user
    'user01' is member of role 'admin', and this user wishes to perform some
    action, for example 'delete_foo', than they will only be able to do so
    if the 'delete_foo' ability was given to either the user itself or the
    'admin' role itself.

    Roles can inherit actions from other roles. For example, role
    'mega_mods' can inherit from roles 'mods' and 'editors'. Thus, users of
    the 'mega_mods' role will assume all actions owned by the 'mods' and
    'editors' roles, plus those specifically given to 'mega_mods'.
    Inheritance is recursive, so if 'mods', for example, inherits from
    'plain_users', then 'mega_mods' will also have anything the
    'plain_users' role has (NOTE: recursive inheritance is new in v0.30.0).

    With "check_user_ability()" and "assert_user_ability()", these
    conditionals are checked to grant or deny the user access to the
    required actions.

    This method of authorization allows for much more flexibility with
    regards to access control, such that roles and abilities can be
    added/edited/deleted using the application itself (via your own
    controllers!). This is useful for applications such as message boards,
    where the administrator might wish to create roles with certain actions
    and associate users with those roles. For example, the admin can create
    an 'editor' role, giving users of this role the ability to edit and
    delete posts, but not any other administrative action. So in essence,
    this plugin takes the control of who's able to do what from the
    developer and hands it to the end-user.

    Note that this plugin is not to be used in conjunction with
    Catalyst::Plugin::Authorization::Roles, and that it requires several
    tables to be present in the database/schema (see "REQUIRED SCHEMA").

            package MyApp::Schema::Result::Action;


                    { data_type => "INTEGER", is_nullable => 0, size => undef },
                    { data_type => "VARCHAR", is_nullable => 0, size => 128 },
                    { data_type => "TEXT", is_nullable => 1, size => undef },

   MyApp::Schema::Result::Role (changed in v0.30.0)
            package MyApp::Schema::Result::Role;


                    { data_type => "INTEGER", is_nullable => 0, size => undef },
                    { data_type => "VARCHAR", is_nullable => 0, size => 128 },
            __PACKAGE__->has_many(map_role_actions => 'MyApp::Schema::Result::RoleAction', 'role_id');
            __PACKAGE__->many_to_many(actions => 'map_role_actions', 'action');
            __PACKAGE__->has_many(map_role_roles => 'MyApp::Schema::Result::RoleRole', 'role_id');
            __PACKAGE__->many_to_many(roles => 'map_role_roles', 'role');

            package MyApp::Schema::Result::UserRole;


                    { data_type => "INTEGER", is_nullable => 0, size => undef },
                    { data_type => "INTEGER", is_nullable => 0, size => undef },
            __PACKAGE__->set_primary_key("user_id", "role_id");
            __PACKAGE__->belongs_to('role' => 'MyApp::Schema::Result::Role', 'role_id');

   MyApp::Schema::Result::RoleRole (new since v0.2, changed in v0.30.0)
            package MyApp::Schema::Result::RoleRole;


                    { data_type => "INTEGER", is_nullable => 0, size => undef },
                    { data_type => "INTEGER", is_nullable => 0, size => undef },
            __PACKAGE__->set_primary_key("role_id", "parent_id");
            __PACKAGE__->belongs_to('parent' => 'MyApp::Schema::Result::Role', 'role_id');
            __PACKAGE__->belongs_to('role' => 'MyApp::Schema::Result::Role', 'inherits_from_id');

            package MyApp::Schema::Result::RoleAction;


                    { data_type => "INTEGER", is_nullable => 0, size => undef },
                    { data_type => "INTEGER", is_nullable => 0, size => undef },
            __PACKAGE__->set_primary_key("role_id", "action_id");
            __PACKAGE__->belongs_to('role' => 'MyApp::Schema::Result::Role', 'role_id');
            __PACKAGE__->belongs_to('action' => 'MyApp::Schema::Result::Action', 'action_id');

            package MyApp::Schema::Result::UserAction;


                    { data_type => "INTEGER", is_nullable => 0, size => undef },
                    { data_type => "INTEGER", is_nullable => 0, size => undef },
            __PACKAGE__->set_primary_key("user_id", "action_id");
            __PACKAGE__->belongs_to('action' => 'MyApp::Schema::Result::Action', 'action_id');

            package MyApp::Schema::Result::User;


                    { data_type => "INTEGER", is_nullable => 0, size => undef },
            __PACKAGE__->has_many(map_user_role => 'MyApp::Schema::Result::UserRole', 'user_id');
            __PACKAGE__->many_to_many(user_roles => 'map_user_role', 'role');
            __PACKAGE__->has_many(map_user_action => 'MyApp::Schema::Result::UserAction', 'user_id');
            __PACKAGE__->many_to_many(actions => 'map_user_action', 'action');

  assert_user_ability( [ $user ], @actions )
    Checks that the user (as supplied by the first argument, or, if omitted,
    "$c->user") has the ability to perform all specified actions. It's
    enough for one action not to be granted for this method to deny ability.

    If the user has all actions, this method will return a true value. Users
    either get actions directory (UserAction in the schema), or via roles
    (UserRole), which can inherit other roles (RoleRole). Role inheritance
    is recursive (see "DESCRIPTION"" in " for more info).

    If for any reason the check fails ("$c->user" is not defined, the user
    is missing an appropriate action, etc.), an error is thrown.

    You can either catch these errors with an eval, or clean them up in your
    "end" action. See check_user_ability() for an alternative that simply
    returns false instead.

    This method automatically grants ability, no matter which actions were
    passed, to the super-user. This is probably the user who installed MyApp
    and is setting it up, so that they can create roles and assign actions
    (otherwise the installing user might have never been able to do
    anything). The super-user is identified by supplying a user ID to
    MyApp's config (see SYNOPSIS). This setting defaults to user ID 1.

  check_user_ability( [ $user ], @actions )
    Same as "assert_user_ability", but instead of throwing errors returns a
    boolean value.

  check_user_roles( [ $user ], @roles )
    Checks that the user (as supplied by the first argument, or, if omitted,
    "$c->user") belongs to the specified roles. Returns a true value only if
    user belongs to all roles specified, and false otherwise.

    Note that inherited roles are taken into account. For example, if user
    directly belongs to role 'x', which inherits from role 'y', which
    inherits from role 'z', then this method will return true for role 'z'.

    The following methods are only to be used internally.

  _user_has_action( $user, $action )
  _role_has_action( $role, $action )
  _user_takes_role( $user, $role )
  _role_takes_role( $role, $role_taken )
    Catalyst::Plugin::Authentication, Catalyst::Plugin::Authorization::Roles

    Ido Perlmuter, "<ido at>"

    Based on Catalyst::Plugin::Authorization::Roles by Yuval Kogman.

    Please report any bugs or feature requests to
    "bug-catalyst-plugin-authorization-abilities at", or through
    the web interface at
    ation-Abilities>. I will be notified, and then you'll automatically be
    notified of progress on your bug as I make changes.

    You can find documentation for this module with the perldoc command.

            perldoc Catalyst::Plugin::Authorization::Abilities

    You can also look for information at:

    *   RT: CPAN's request tracker


    *   AnnoCPAN: Annotated CPAN documentation


    *   CPAN Ratings


    *   Search CPAN


    Copyright 2009-2011 Ido Perlmuter.

    This program is free software; you can redistribute it and/or modify it
    under the terms of either: the GNU General Public License as published
    by the Free Software Foundation; or the Artistic License.

    See for more information.

You can’t perform that action at this time.