Laravel acl through users, roles and permissions
Simple package that enforces Access Control List using Eloquent.
- Console Commands
- Config File
- More Information
Many, many times, it was a good decision to name routes after views. It allowed me to easily identify which view should be called in a certain controller method, it also, worked the opposite way, while exploring the views, in most cases i could easily identify which controller was loading that view.
Using a similar logic, this package works by naming permissions same as these routes and views. The basic idea is to load all permissions from cache or database on each request and attach each a closure that checks if the requesting user has at least a role that contains this permission. Then, when a user requests a protected by acl middleware route, two checks are performed.
- The requesting user is authenticated.
- The named route, whose name is the same as the permission name (slug property in fact), is part of the loaded permissions, and if so, if the authenticated user has a role that contains the requested permission.
If any of these checks fail, a "permission denied" page or message is returned.
Allows a basic ACL to be performed in a "per role" level on routes.
This means, when any user requests an ACL protected route, the route name will need to exists in any of the requesting user roles in order to allow access.
This ACL does not intend to provide a "per user" protection to route. You can achieve that by using the Ultraware/Roles middlewares or by using policies.
Make sure to read all the process in order to correctly install this package.
- Laravel 5.4
- Ultraware/Roles package
There is no need to follow the installation process on Ultraware/Roles package if not already done.
Any installation steps needed are covered in this guide.
Make sure to check Ultraware/Roles package documentation for usage guide.
Pull this package in through Composer
composer require automaticko/acl
After updating composer, add the service provider to the
providers array in
'providers' => [ ... /** * Third Party Service Providers... */ Automaticko\ACL\ACLServiceProvider::class, ],
You can publish the package config file to your application.
Run these commands inside your terminal.
php artisan vendor:publish --provider="Automaticko\ACL\ACLServiceProvider" --tag=config
Make sure to check Ultraware Ultraware/Roles package documentation for publish options.
There are 3 environment variables used in the acl config file (config file doesn't need to be published in order for these to work).
|ACL_ENABLED||True||Enable acl middleware|
|ACL_IMPORT_ENABLED||True||Enable acl:import command|
|ACL_EXPORT_ENABLED||True||Enable acl:export command|
Ultraware/Roles package offers the way to publish its migrations, although this is not needed nor recommended by this package.
In order to run the Ultraware/Roles migrations just run
php artisan migrate
This uses the default users table which is in Laravel. You should already have the migration file for the users table available and migrated.
As per Ultraware/Roles package documentation, you should
HasRoleAndPermission trait and also implement
HasRoleAndPermission contract inside your
This package uses
ACL middleware. Any route that need to be ACL protected, should use it or belong to a group of
routes that uses it.
The config file contains several sections and values that are required for acl to correctly work.
Many of the options there are self explanatory or have a comment that will help you understand and modify it as
you need. The
The ACL package provides commands to import and export roles and permissions from a config file to database and vice versa.
It happened to me that in many situations, while and app was already deployed in a production environment, the client asked for a specific rol/permission to be added or a new feature which included one or many roles/permissions, or simply a route that previously had a permission or none now needed to have a different one. Sometimes, in these cases, creating a migration to insert these permissions/roles or modifying routes middleware was not something wanted/could do.
Import command was created for these situations. It does NOT intend to replace the process of inserting/updating/deleting roles/permissions but to just give a relatively easy way to do it.
When this command run, the
import section of the
config/acl.php file is loaded and permissions and roles are
inserted, updated or deleted from db.
The following statement applies to permissions or roles
- If its present in
config/acl.phpbut its not present in db, is inserted.
- If its present in
config/acl.phpand is present in db, is updated if has any change.
- If is not present in
config/acl.phpand is present in db, is deleted from db.
In the same section,
import, inside the subsection
roles, each role should contain a
which should list all the permissions belonging to that role.
For each of these roles permissions.
- If is present in
permissionssection and not in db, is inserted into db creating a relation between the current role and permission.
- If is present in
permissionssection and already in db, is ignored.
- If not is present in
permissionssection (at this point the permission was deleted from db if existed), is ignored and a warning is displayed by the command telling you about it.
The command to run is
php artisan acl:import --force --v
The --force and --v options are optional
- --force do as it says and forces the import, ignoring the
- --v makes the command more verbose.
Sometimes as well, i was developing a new feature that required many permissions/roles, which i had
inserted/updated/deleted from db, to be present on production.
Tinkering with db in production was not what i felt safe, so the
export command was created.
Again, this command does NOT intend to replace the process of inserting/updating/deleting roles/permissions but
to just give a relatively easy way to do it.
export command does the opposite of the
import command. It reads database and write permission, roles and permission
config/acl.php overwriting it but respecting the values it previously had.
Any statement stored in
config/acl.php will be converted to the value that holds at the moment the command
In example. If
'enabled' => !(1 * 1), ...
The file will be generated containing
'enabled' => false, ...
Which is the value of
!(1 * 1)
In this way, you can push this config file to production and run the
import command there to update permissions/roles.
There are no tests so far. PRs are welcome.
This package is free software distributed under the terms of the MIT license.