Download the PHP package bbatsche/entrust without Composer

Entrust (Laravel4 Package)

Entrust is a succinct and flexible way to add Role-based Permissions to Laravel 4.

First and foremost I must give credit to the original developers of this package. Andrew Elkins (@andrewelkins) and Leroy Merlin (@zizaco) did excellent work on the fundamental design and functionality. My fork is intended to:

• Remove extra components not really relevant to role & permission management (in particular, Ardent).
• Add extra functionality I felt was useful and particularly suited to this package.
• Make integrating the package more flexible and dynamic (eventually).

Were my changes ever to be integrated back into the Zizaco version of this plugin, I think that would be lovely. Either way though, I hope to demonstrate some genuinely helpful features and options.

Contents

• Quick start
  • Required setup
• Configuration
  • User Relation to Roles
  • Models
    • Role
    • Permission
    • User
    • Non-Standard Table Names
      • Role Constructor
      • Permission Constructor
    • EntrustRole and EntrustPermission Classes
    • Soft Deleting
• Usage
  • Concepts
    • Checking for Roles & Permissions
    • User Ability
  • Controller Trait (and Filters)
  • Short Syntax Route Filter
  • Route Filter
• Troubleshooting
• License
• Additional Information

Quick start

PS: Even though it's not needed, Entrust works very well with Confide in order to eliminate repetitive tasks involving the management of users: account creation, login, logout, confirmation by e-mail, password reset, etc.

Take a look at Confide.

Required setup

In the require key of composer.json file add the following:

Run the Composer update command:

In your config/app.php add 'Bbatsche\Entrust\EntrustServiceProvider' to the end of the $providers array:

At the end of config/app.php add 'Entrust' => 'Bbatsche\Entrust\EntrustFacade' to the $aliases array:

Configuration

Set the property values in the config/auth.php (typically, these values are configured correctly out of the box but it is worth double checking). These values will be used by Entrust to refer to the correct user table and model.

You can also publish the configuration for this package to further customize table names and model namespaces:

User relation to roles

Now generate the Entrust migration:

It will generate the <timestamp>_entrust_setup_tables.php migration. You may now run it with the artisan migrate command:

After the migration, four new tables will be present:

• roles — stores role records
• permissions — stores permission records
• role_user — stores many-to-many relations between roles and users
• permission_role — stores many-to-many relations between roles and permissions

Models

Role

Create a Role model inside app/models/Role.php using the following example:

The Role model has three main attributes:

• name — Unique name for the Role, used for looking up role information in the application layer. For example: "admin", "owner", "employee".
• display_name — Human readable name for the Role. Not necessarily unique and optional. For example: "User Administrator", "Project Owner", "Widget Co. Employee".
• description — A more detailed explanation of what the Role does. Also optional.

Both display_name and description are optional; their fields are nullable in the database.

Permission

Create a Permission model inside app/models/Permission.php using the following example:

The Permission model has the same three attributes as the Role:

• name — Unique name for the permission, used for looking up permission information in the application layer. For example: "create-post", "edit-user", "post-payment", "mailing-list-subscribe".
• display_name — Human readable name for the permission. Not necessarily unique and optional. For example "Create Posts", "Edit Users", "Post Payments", "Subscribe to mailing list".
• description — A more detailed explanation of the Permission.

In general, it may be helpful to think of the last two attributes in the form of a sentence: "The permission display_name allows a user to description."

User

Finally, add the same same traits & role pattern to your user model. For example:

This will enable the relation with Role and add several methods to check for roles or permissions within your User model.

Don't forget to dump composer autoload

And you are ready to go.

Non-Standard Table Names

Entrust is configured by default to follow Laravel's naming conventions for table names, so data for your Role model is stored in a table called roles. If you change these defaults in Entrust's configuration, you need to reflect these changes in your models as well. This can be done simply by adding a constructor like the following:

Role Constructor

Permission Constructor

EntrustRole and EntrustPermission Classes

For easy of use (and backwards compatibility) Entrust includes abstract classes Bbatsche\Entrust\EntrustRole and Bbatsche\Entrust\EntrustPermission. Your Role and Permission models may simply extend these classes which in turn implement their respective interfaces and traits. They also include the aforementioned constructors. Depending on your needs, these may be simpler to implement in your models.

Soft Deleting

The default migration takes advantage of onDelete('cascade') clauses within the pivot tables to remove relations when a parent record is deleted. If for some reason you cannot use cascading deletes in your database, EntrustRoleTrait, EntrustPermissionTrait, and EntrustUserTrait include event listeners to manually delete records in relevant pivot tables. In the interest of not accidentally deleting data, the event listeners will not delete pivot data if the model uses soft deleting. However, due to limitations in Laravel's event listeners, there is no way to distinguish between a call to delete() versus a call to forceDelete(). For this reason, before you force delete a model, you must manually delete any of the relationship data (unless your pivot tables uses cascading deletes). For example:

Usage

Concepts

Let's start by creating the following Roles and Permissions:

Next, with both roles created let's assign them to the users. Thanks to EntrustUserTrait this is as easy as:

Now we just need to add permissions to those Roles:

Checking for Roles & Permissions

Now we can check for a role with the is() method simply by doing:

If you would like to check multiple roles, you can use either isAny() or isAll() depending on whether you require just one of the roles, or all of them:

If you need more details about which roles failed, you can pass a variable to the second argument. After calling isAny() or isAll() the variable will be an array of roles that failed.

Similarly, if we want to check for a user's permissions we use the method can():

Just like with roles, there are methods for checking multiple permissions; canAny() and canAll():

These methods can also include a variable for tracking which specific permissions failed:

You can have as many Roles as you want for each User, and each Role can have as many Permissions as necessary.

The Entrust class has shortcuts to both is*() and can*() methods for the currently logged in user:

Note: Laravel Facades do not support pass by reference, meaning you cannot pass a second argument to the *Any() and *All() methods to find out exactly which permissions or roles failed. To do this, you must get an instance of the User object.

User ability

More advanced checking can be done using the ability() function. It takes in three parameters (roles, permissions, options):

• roles is a set of roles to check.
• permissions is a set of permissions to check.

Either of the roles or permissions variable can be a comma separated string or array:

This will check whether the user has any of the provided roles and permissions. In this case it will return true since the user is an admin and has the create-post permission.

The third parameter is an options array:

• validate_all is a boolean flag to set whether to check all the values for true, or to return true if at least one role or permission is matched.
• return_type specifies whether to return a boolean, array of checked values, or both in an array.

Here is an example output:

Controller Trait

Typically when you are creating a controller you will find that there are a set of roles or permissions you want to enforce on a per-action basis. Entrust includes a trait for your controllers that makes enforcing these rules quite simple. First, you must use the trait in your controller. For example, we could include it in a BaseController so that the feature is available in all the controllers for our application:

This trait includes two methods that can be used to filter requests to your controller, they are entrustPermissionFilter() and entrustRoleFilter(). To enable one or both of these filters in your controller, use the beforeFilter() method in the controller's constructor:

The required roles or permissions are specified in properties of your controller; either $entrustPerms or $entrustRoles. These properties should be associative arrays, with the key being the name of the controller action (or method), and the value being the roles or permissions required for that action. The roles and permissions can be either a string or an array of multiple values. For example:

Entrust will now automatically check against these roles or permissions for each method in the controller. If the current user does not have the required role or permissions, a 403 response will be returned.

The controller trait includes a couple of optional flags that control how it interprets the array of perms and roles. When the specified value is an array, Entrust assumes than any one of the entities is sufficient. To force Entrust to require all the values, set the property $entrustRequireAll to true in your controller. In addition, if an method is not specified in your array, the filters treats this as a "pass". To make Entrust require a role or permission to be specified for all actions, set the property $entrustAllowMissing to false. This setting may be useful as a security sanity check, meaning that if the role or permission for an action is not specified, then no user should be able to access it.

If you would like to do some additional handling after one of the filters fails you can create callback functions. Callback functions may be specified in one of three ways. First, you can create methods called entrustPermissionCallback() or entrustRoleCallback(). Second, you can create a closure and assign it to either $entrustPermisionCallback or $entrustRoleCallback properties of your controller. Or lastly, you can create the method separately and assign its name as a string to either of those properties. In any case, Entrust will call your callback function whenever one of the filters fails. It will pass the following to your function:

1. The controller method name
2. The permissions or roles that failed
3. The entire set of permissions or roles that were required
4. The Route object
5. The Request object

A sample callback function could look like the following:

Short syntax route filter

To filter a route by permission or role you can call the following in your app/filters.php:

Both of these methods accept a third parameter. If the third parameter is null then the return of a prohibited access will be App::abort(403), otherwise the third parameter will be returned. So you can use it like:

Furthermore both of these methods accept a fourth parameter. It defaults to true and checks all roles/permissions given. If you set it to false, the function will only fail if all roles/permissions fail for that user. Useful for admin applications where you want to allow access for multiple groups.

Route filter

Entrust roles/permissions can be used in filters by simply using the can and hasRole methods from within the Facade:

Using a filter to check for a role:

As you can see Entrust::hasRole() and Entrust::can() checks if the user is logged in, and then if he or she has the role or permission. If the user is not logged the return will also be false.

Troubleshooting

If you encounter an error when doing the migration that looks like:

Then it's likely that the id column in your user table does not match the user_id column in role_user. Match sure both are INT(10).

License

Entrust is free software distributed under the terms of the MIT license.

Additional information

Current library documentation can be found on GitHub Pages.

Any questions, feel free to contact me or ask here.

Any issues, please report here.