Download the PHP package foothing/laravel-wrappr without Composer
On this page you can find all versions of the php package foothing/laravel-wrappr. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download foothing/laravel-wrappr
More information about foothing/laravel-wrappr
Files in foothing/laravel-wrappr
Package laravel-wrappr
Short Description Bind permissions to Laravel routes.
License MIT
Informations about the package laravel-wrappr
Laravel Wrappr
For Laravel 5.1 use 0.4.10 version
For Laravel 5.2 and up use the latest 0.x version
This is a Laravel 5 package that aims to simplify the process of binding routes to permissions and it is indepentent from a specific permissions handler, allowing to add route checks even if your permissions handler doesn't support this feature natively.
Also, it tries to put some effort in decoupling your app from the permission handler for what concerns basic operations.
There is a Lock integration ready to use.
I've plans to implement a Gate
integration as well, feel free
to drop a line if you're interested in this.
Usage example
A basic use case where you want to restrict route access to the
read.users
permission
Or, you can define custom route patterns that can help with dynamic urls, assuming you have defined a controller and want to split the access logic on its methods.
Assuming your controller provides the following routes
you can define a rule like the following to restrict access:
Contents
- Concept
- Install and setup
- Configure the providers
- Use within Laravel Router
- Use within custom routes
- Install routes with config file
- Install routes programmatically
- Setup the middleware
- A note on route processing order
- Middleware Response
- How to develop providers
- License
Concept
As it happens you may need to switch to another acl library at some time, so i've tried to put some effort into adding an abstract layer that would make your app more maintenaible. This package tries to abstract your app from the acl layer in 2 different ways:
- standard approach to route-based checks
- standard api to basic acl manipulation
In order to access permissions checks, a permissions provider that acts as a bridge with the acl library must be set. Also, a users provider is required in order to retrieve the authenticated user.
While the route checks are the main focus of this project, the acl manipulation feature tries to stay out of the way so you'll just use it at will.
Install and Setup
Composer install
Add the service provider in yourconfig/app.php
providers array.
Then publish package configuration and migration files
Configure the providers
Once you've published the config file you can
configure an users provider and a permissions provider accordingly
to your project setup.
This sample configuration will enable the integration with Lock
and Illuminate\Auth\Guard
.
In your config/wrappr.php
Use within Laravel Router
There are two use cases for this package, each implemented in
its own Middleware. Let's take a look to the default case.
First of all you need to setup the Middleware in your App\Http\Kernel
.
Add the following line:
Use the CheckRoute Middleware to control access to your routes like the following routes.php:
The CheckRoute
Middleware accepts 3 arguments:
- the required permission
- an optional resource name, i.e. 'user'
- an optional resource identifier (integer)
Example:
Also, the Middleware can handle your route arguments. Consider the following
When you pass a resource identifier within the brackets, the middleware will try to retrieve the value from the http request automatically.
Use with custom routes
When you're not able to fine-control at routes definition level, there's an alternative way of handling permissions. Think about a global RESTful controller like the following:
Assume that your controller applies a variable pattern to handle the routes, like for example
In this case you won't be able to bind permissions with the previous method, so
the CheckPath
middleware comes to help. In order to enable this behaviour you need
some additional setup step.
First step is to run the migration you previously published.
then you have the following two choices.
Install routes with config file
You can now configure the routes you would like to put under authorization control
In your config/wrappr.php
edit your routes
section:
Once you're done with your routes setup run the artisan command
Note that each time you change the routes configuration you should run the artisan command again in order to refresh them.
Install routes programmatically
Alternatively you can programmatically setup your routes using
the RouteInstaller
. In this case you won't need the artisan command.
Setup the middleware
Add the global Middleware to your App\Http\Kernel
like this
and you're all set.
A note on routes processing order
The Middleware will parse all incoming http requests to match your installed routes and it will react like the following
- if a route pattern is not found access is granted
- if a route pattern is found it will trigger the permissions provider that will perform the check
Once you've got your routes installed keep in mind that they will be processed in a hierarchical order, from the more specific to the more generic. Look at this example
This will result in the following behaviour
- if you request
foo/bar
route is not found hence access is allowed - if you request
api/foo
permissions bound to theapi/*
pattern will be applied - if you request
api/v1
permission bound to theapi/v1
pattern will be applied
and so on.
Middleware Response
Both the middleware implementation will return HTTP 401
on failure
with an additional X-Reason: permission
header that will come handy
when dealing with responses on the client side (i.e. an angular interceptor).
If you want your error responses to be redirected when the Middleware check fails, just set the redirect path in your wrappr.config
This value will be ignored when the http request is an ajax request.
How to develop providers
Extend Foothing\Wrappr\Providers\Permissions\AbstractProvider
.
You'll have the mandatory check()
method to implement, and other optional
methods you can implement or ignore at your choice.
License
All versions of laravel-wrappr with dependencies
illuminate/auth Version ~5.1
illuminate/database Version ~5.1
illuminate/cache Version ~5.1
foothing/laravel-repository Version >=0.7