| Name : perl-Abilities
| |
| Version : 0.5
| Vendor : obs://build_opensuse_org/devel:languages:perl
|
| Release : lp154.442.1
| Date : 2023-01-27 16:08:44
|
| Group : Development/Libraries/Perl
| Source RPM : perl-Abilities-0.5-lp154.442.1.src.rpm
|
| Size : 0.06 MB
| |
| Packager : https://www_suse_com/
| |
| Summary : Simple, hierarchical user authorization for web applications, with optio[cut]
|
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 ability-based
acccess control, a list of actions is assigned to every user, and they are
only allowed to perform these actions. Actions are not assigned by the
developer during development, but rather by the end-user during deployment.
This allows for much more flexibility, and also speeds up development, as
you (the developer) do not need to think about who should be allowed to
perform a certain action, and can easily grant access later-on after
deployment (assuming you\'re also the end-user).
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 ability-based
authorization system. Entities::User and Entities::Role are the user and
role classes that consume the Abilities role in the Entities distribution.
|
RPM found in directory: /packages/linux-pbone/ftp5.gwdg.de/pub/opensuse/repositories/devel:/languages:/perl:/CPAN-A/15.4/noarch |
