Download the PHP package qa-data/api-security without Composer
On this page you can find all versions of the php package qa-data/api-security. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download qa-data/api-security
More information about qa-data/api-security
Files in qa-data/api-security
Package api-security
Short Description API Security: provides authentication, authorization and a role-based access control management via ACL
License MIT
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package api-security
API Security: Access Control
Authentication & Authorization library for Nette.
- user login
- verifying user privileges
- how to create custom authenticators and authorizators
- Access Control List
It requires PHP version 8.1 and supports PHP up to 8.4.
Setup
DiAttibute is available on composer:
At first register compiler extension.
Authentication
Authentication means user login, ie. the process during which a user's identity is verified. The user usually
identifies himself using token. Verification is performed by the so-called authenticator. If the login
fails, it throws QaData\ApiSecurity\AuthenticationException.
And checking if user is logged in:
Authenticator
It is an object that verifies the login data, ie usually the token.
An authenticator is an object that implements the Authenticator interface with method authenticate(). Its task is
either to return the so-called identity or to throw an exception
QaData\ApiSecurity\AuthenticationException.
$onLoggedIn events
Object QaData\ApiSecurity\User has event $onLoggedIn, so you can add callbacks that are triggered after a successful
login or after the user logs out.
Identity
An identity is a set of information about a user that is returned by the authenticator and retrieved using
$user->getIdentity(). So we can get the id, token and roles.:
Identity is an object that implements the QaData\ApiSecurity\Identity interface, the default implementation is
QaData\ApiSecurity\SimpleIdentity.
Authorization
Authorization determines whether a user has sufficient privileges, for example, to access a specific resource or to perform an action. Authorization assumes previous successful authentication, ie that the user is logged in.
For very simple websites with administration, where user rights are not distinguished, it is possible to use the already
known method as an authorization criterion isLoggedIn(). In other words: once a user is logged in, he has permissions
to all actions and vice versa.
Roles
The purpose of roles is to offer a more precise permission management and remain independent on the token.
Authorizator
In addition to roles, we will introduce the terms resource and operation:
- role is a user attribute - for example moderator, editor, visitor, registered user, administrator, ...
- resource is a logical unit of the application - article, page, user, menu item, poll, presenter, ...
- operation is a specific activity, which user may or may not do with resource - view, edit, delete, vote, ...
An authorizer is an object that decides whether a given role has permission to perform a certain operation with
specific resource. It is an object implementing the QaData\ApiSecurity\Authorizator interface with only one
method isAllowed():
And the following is an example of use. Note that this time we call the method QaData\ApiSecurity\User::isAllowed(), not
the authorizator's one, so there is not first parameter $role. This method calls MyAuthorizator::isAllowed()
sequentially for all user roles and returns true if at least one of them has permission.
Both arguments are optional and their default value means everything.
Permission ACL
Nette comes with a built-in implementation of the authorizer, the QaData\ApiSecurity\Acl class, which offers a
lightweight and flexible ACL (Access Control List) layer for permission and access control. When we work with this
class, we define roles, resources, and individual permissions. And roles and resources may form hierarchies. To explain,
we will show an example of a web application:
guest: visitor that is not logged in, allowed to read and browse public part of the web, ie. read articles, comment and vote in pollsregistered: logged-in user, which may on top of that post commentsadministrator: can manage articles, comments and polls
So we have defined certain roles (guest, registered and administrator) and mentioned resources (article,
comments, poll), which the users may access or take actions on (view, vote, add, edit).
We create an instance of the Permission class and define roles. It is possible to use the inheritance of roles,
which ensures that, for example, a user with a role administrator can do what an ordinary website visitor can do (and
of course more).
We will now define a list of resources that users can access:
Resources can also use inheritance, for example, we can add $acl->addResource('perex', 'article').
And now the most important thing. We will define between them rules determining who can do what:
What if we want to prevent someone from accessing a resource?
Now when we have created the set of rules, we may simply ask the authorization queries:
The same applies to a registered user, but he can also comment:
The administrator can edit everything except polls:
