Abilities
view release on metacpan or search on metacpan
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The license agreements of most software companies try to keep users
at the mercy of those companies. By contrast, our General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. The
General Public License applies to the Free Software Foundation's
software and to any other program whose authors commit to using it.
You can use it for your programs, too.
When we speak of free software, we are referring to freedom, not
price. Specifically, the General Public License is designed to make
sure that you have the freedom to give away or sell copies of free
software, that you receive source code or can get it if you want it,
that you can change the software or use pieces of it in new free
programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
For example, if you distribute copies of a such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must tell them their rights.
We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License Agreement applies to any program or other work which
contains a notice placed by the copyright holder saying it may be
distributed under the terms of this General Public License. The
Each version is given a distinguishing version number. If the Program
specifies a version number of the license which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
the license, you may choose any version ever published by the Free Software
Foundation.
8. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
9. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
possible use to humanity, the best way to achieve this is to make it
free software which everyone can redistribute and change under these
terms.
To do so, attach the following notices to the program. It is safest to
attach them to the start of each source file to most effectively convey
the exclusion of warranty; and each file should have at least the
"copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) 19yy <name of author>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 1, or (at your option)
any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
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.
{
"abstract" : "Simple, hierarchical user authorization for web applications, with optional support for plan-based (paid) services.",
"author" : [
"Ido Perlmuter <ido@ido50.net>"
],
"dynamic_config" : 0,
"generated_by" : "Dist::Zilla version 4.300031, CPAN::Meta::Converter version 2.120921",
"license" : [
"perl_5"
],
"meta-spec" : {
"url" : "http://search.cpan.org/perldoc?CPAN::Meta::Spec",
"version" : "2"
---
abstract: 'Simple, hierarchical user authorization for web applications, with optional support for plan-based (paid) services.'
author:
- 'Ido Perlmuter <ido@ido50.net>'
build_requires:
Moo: 0
Test::More: 0
strict: 0
warnings: 0
configure_requires:
ExtUtils::MakeMaker: 6.30
dynamic_config: 0
generated_by: 'Dist::Zilla version 4.300031, CPAN::Meta::Converter version 2.120921'
Makefile.PL view on Meta::CPAN
use strict;
use warnings;
use 5.006;
use ExtUtils::MakeMaker 6.30;
my %WriteMakefileArgs = (
"ABSTRACT" => "Simple, hierarchical user authorization for web applications, with optional support for plan-based (paid) services.",
"AUTHOR" => "Ido Perlmuter <ido\@ido50.net>",
"BUILD_REQUIRES" => {
"Moo" => 0,
"Test::More" => 0,
"strict" => 0,
"warnings" => 0
},
"CONFIGURE_REQUIRES" => {
"ExtUtils::MakeMaker" => "6.30"
},
NAME
Abilities - Simple, hierarchical user authorization for web
applications, with optional support for plan-based (paid) services.
VERSION
version 0.5
SYNOPSIS
package User;
use Moose; # or Moo
with 'Abilities';
my $user = MyApp->get_user('username'); # $user is a User object
# check if the user is able to do something
if ($user->can_perform('something')) {
do_something();
} else {
die "Hey you can't do that, you can only do " . join(', ', keys %{$user->abilities});
}
DESCRIPTION
Abilities is a simple yet powerful mechanism for authorizing users of
web applications (or any applications) to perform certain actions in the
application. This is an extension of the familiar role-based access
control that is common in various systems and frameworks like Catalyst
(See Catalyst::Plugin::Authorization::Roles for the role-based
implementation and Catalyst::Plugin::Authorization::Abilities for the
ability-based implementation that inspired this module).
As opposed to role-based access control - where users are allowed access
to a certain feature (here called 'action') only through their
association to a certain role that is hard-coded into the program - in
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
ability-based authorization system. Entities::User and Entities::Role
are the user and role classes that consume the Abilities role in the
Entities distribution.
CONSTRAINTS
Generally, an ability is a yes/no option. Either the user can or can't
perform a specific action. At times, this might not be flexible enough,
and the user's ability to perform a certain action should be
constrained. For example, a user might be granted the ability to edit
posts in a blog, but this ability should be constrained to the user's
posts only. The user is not to be allowed to edit posts created by other
name = Abilities
author = Ido Perlmuter <ido@ido50.net>
license = Perl_5
copyright_holder = Ido Perlmuter
[@IDOPEREL]
lib/Abilities.pm view on Meta::CPAN
package Abilities;
# ABSTRACT: Simple, hierarchical user authorization for web applications, with optional support for plan-based (paid) services.
use Carp;
use Hash::Merge qw/merge/;
use Moo::Role;
use namespace::autoclean;
our $VERSION = "0.5";
$VERSION = eval $VERSION;
=head1 NAME
Abilities - Simple, hierarchical user authorization for web applications, with optional support for plan-based (paid) services.
=head1 VERSION
version 0.5
=head1 SYNOPSIS
package User;
use Moose; # or Moo
lib/Abilities.pm view on Meta::CPAN
# check if the user is able to do something
if ($user->can_perform('something')) {
do_something();
} else {
die "Hey you can't do that, you can only do " . join(', ', keys %{$user->abilities});
}
=head1 DESCRIPTION
Abilities is a simple yet powerful mechanism for authorizing users of web
applications (or any applications) to perform certain actions in the application. This is an
extension of the familiar role-based access control that is common in
various systems and frameworks like L<Catalyst> (See L<Catalyst::Plugin::Authorization::Roles>
for the role-based implementation and L<Catalyst::Plugin::Authorization::Abilities>
for the ability-based implementation that inspired this module).
As opposed to role-based access control - where users are allowed access
to a certain feature (here called 'action') only through their association
to a certain role that is hard-coded into the program - in ability-based
acccess control, a list of actions is assigned to every user, and they are
lib/Abilities.pm view on Meta::CPAN
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.
=head2 CONSTRAINTS
Generally, an ability is a yes/no option. Either the user can or can't perform
a specific action. At times, this might not be flexible enough, and the user's
ability to perform a certain action should be constrained. For example, a user
might be granted the ability to edit posts in a blog, but this ability should
be constrained to the user's posts only. The user is not to be allowed to edit
lib/Abilities/Features.pm view on Meta::CPAN
# check if the customer has a certain feature
if ($customer->has_feature('ssl_encryption')) {
&initiate_https_connection();
} else {
&initiate_http_connection();
}
=head1 DESCRIPTION
This L<Moo role|Moo::Role> extends the ability-based authorization
system defined by the L<Abilities> module with customer and plan management
for subscription-based web services. This includes paid services, where
customers subscribe to a plan from a list of available plans, each plan
with a different set of features. Examples of such a service are GitHub
(a Git revision control hosting service, where customers purchase a plan
that provides them with different amounts of storage, SSH support, etc.)
and MailChimp (email marketing service where customers purchase plans
that provide them with different amounts of monthly emails to send and
other features).
lib/Abilities/Features.pm view on Meta::CPAN
provided with the features of these plans. The users from the Abilities
module will now be children of the customers. They still go on being members
of roles and performing actions they are granted with, but now possibly
only within the scope of their parent customer, and to the limits defined
in the customer's plan. Plans can inherit features from other plans, allowing
for defining plans faster and easier.
Customer and plan objects are meant to consume the Abilities::Features
role. L<Entities> is a reference implementation of both the L<Abilities> and
L<Abilities::Features> roles. It is meant to be used as-is by web applications,
or just as an example of how a user management and authorization system
that consumes these roles might look like. L<Entities::Customer> and
L<Entities::Plan> are customer and plan classes that consume this role.
Just like in L<Abilities>, features can be constrained. For more info,
see L<Abilities/"CONSTRAINTS">.
More information about how these roles work can be found in the L<Entities>
documentation.
=head1 REQUIRED METHODS
( run in 0.845 second using v1.01-cache-2.11-cpan-5c0b1e786e0 )