Abilities
view release on metacpan or search on metacpan
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston MA 02110-1301 USA
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) 19xx name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the
appropriate parts of the General Public License. Of course, the
commands you use may be called something other than `show w' and `show
c'; they could even be mouse-clicks or menu items--whatever suits your
program.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the program, if
necessary. Here a sample; alter the names:
"Test::More" : "0",
"strict" : "0",
"warnings" : "0"
}
}
},
"release_status" : "stable",
"resources" : {
"homepage" : "https://github.com/ido50/Abilities",
"repository" : {
"type" : "git",
"url" : "https://github.com/ido50/Abilities.git",
"web" : "https://github.com/ido50/Abilities"
}
},
"version" : "0.5"
}
Abilities to perform certain actions can be given to a user
specifically, or via roles the user can assume (as in role-based access
control). For example, if user 'user01' is a member of role 'admin', and
this user wishes to perform some action, for example 'delete_foo', then
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. Furthermore, roles
can recursively inherit other roles; for example, the role 'mega_mods'
can inherit the roles 'mods' and 'editors'. Users of the 'mega_mods'
role will assume all actions owned by the 'mods' and 'editors' roles.
A commonly known use-case for this type of access control is message
boards, where the administrator might wish to create roles with certain
actions and associate users with the roles (more commonly called 'user
groups'); 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 type of access control
relieves the developer of deciding who gets to do what and passes these
decisions to the end-user, which might actually be necessary in certain
situations.
The "Abilities" module is implemented as a Moo role (which makes it
compatible with Moose code). In order to be able to use this mechanism,
applications must implement a user management system that will consume
this role. More specifically, a user class and a role class must be
implemented, consuming this role. Entities is a reference implementation
that can be used by applications, or just taken as an example of an
This file contains message digests of all files listed in MANIFEST,
signed via the Module::Signature module, version 0.70.
To verify the content in this distribution, first make sure you have
Module::Signature installed, then type:
% cpansign -v
It will check each file's integrity, as well as the signature's
validity. If "==> Signature verified OK! <==" is not displayed,
the distribution may already have been compromised, and you should
not run its Makefile.PL or Build.PL.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
lib/Abilities.pm view on Meta::CPAN
Abilities to perform certain actions can be given to a user specifically, or
via roles the user can assume (as in role-based access control). For example,
if user 'user01' is a member of role 'admin', and this user wishes to perform
some action, for example 'delete_foo', then 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. Furthermore, roles can recursively inherit other roles;
for example, the role 'mega_mods' can inherit the roles 'mods' and 'editors'.
Users of the 'mega_mods' role will assume all actions owned by the 'mods'
and 'editors' roles.
A commonly known use-case for this type of access control is message boards,
where the administrator might wish to create roles with certain actions
and associate users with the roles (more commonly called 'user groups');
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 type of access control relieves the developer
of deciding who gets to do what and passes these decisions to the
end-user, which might actually be necessary in certain situations.
The C<Abilities> module is implemented as a L<Moo role|Moo::Role> (which makes
it compatible with L<Moose> code). In order to be able to use this mechanism,
applications must implement a user management system that will consume this role.
More specifically, a user class and a role class must be implemented, consuming this role. L<Entities> is a reference implementation that can be used by applications, or
just taken as an example of an ability-based authorization system. L<Entities::User>
and L<Entities::Role> are the user and role classes that consume the Abilities
role in the Entities distribution.
( run in 0.745 second using v1.01-cache-2.11-cpan-df04353d9ac )