%PDF- %PDF-
Direktori : /var/www/html/bbw/farmaci/kritik-portale/vendor/zf-commons/zfc-rbac/docs/ |
Current File : /var/www/html/bbw/farmaci/kritik-portale/vendor/zf-commons/zfc-rbac/docs/01. Introduction.md |
# Introduction Welcome to the official documentation of ZfcRbac! In this part, the following questions will be answered: * Why should I use an authorization module? * What is the Rbac model? * How can I integrate ZfcRbac into my application? ## Why should I use an authorization module? The authorization part of an application is an essential aspect to secure your application. While the authentication part tells you who is using your website, the authorization answers if the given identity has the permission to perform specific actions. ## What is the Rbac model? Rbac stands for **role-based access control**. We use a very simple (albeit powerful) implementation of this model through the use of [this PHP library](https://github.com/zf-fr/rbac). > We are not using the official ZF2 Rbac component since ZfcRbac 2.0 as it has some design flaws. The library we are using here is actually a prototype for ZF3 Rbac component I've made specifically for ZfcRbac. The basic idea of Rbac is to use roles and permissions: * **Users** can have one or many **Roles** * **Roles** request access to **Permissions** * **Permissions** are granted to **Roles** By default, ZfcRbac can be used for two kinds of Rbac model: * Flat RBAC model: in this model, roles cannot have children. This is ideal for smaller application, as it is easier to understand, and the database design is simpler (no need for a join table). * Hierarchical RBAC model: in this model, roles can have children roles. When evaluating if a given role has a permission, this model also checks recursively if any of its child roles also have the permission. ## How can I integrate ZfcRbac into my application? ZfcRbac offers multiple ways to protect your application: * Using **Guards**: those classes act as "firewalls" that block access to routes and/or controllers. Guards are usually configured using PHP arrays, and are executed early in the MVC dispatch process. Typically this happens right after the route has been matched. * Using **AuthorizationService**: a complementary method is to use the `AuthorizationService` and inject them into your service classes to protect them from unwanted access. While it is advised to use both methods to make your application even more secure, this is completely optional and you can choose either of them independently. To find out about how you can easily make your existing application more secure, please refer to the following section: * [Cookbook: A real world example](/docs/07. Cookbook.md#a-real-world-application) ### Navigation * Continue to [the **Quick Start**](/docs/02. Quick Start.md) * Back to [the Index](/docs/README.md)