Gates provide a simple, Closure based approach to authorization while
policies, like controllers, group their logic around a particular model or resource.
Gates are most applicable to actions which are not related to any model or resource, such as viewing an administrator dashboard. In contrast, policies should be used when you wish to authorize an action for a particular model or resource.
Gates are Closures that determine if a user is authorized to perform a given action and are typically defined in the
App\Providers\AuthServiceProvider class using the Gate facade. Gates
always receive a user instance as their first argument, and may optionally receive additional arguments such as a relevant Eloquent model:
public function boot()
{
$this->registerPolicies();
Gate::define('update-post', function ($user, $post) {
return $user->id == $post->user_id;
});
Gate::define('update-post', 'App\Policies\
PostPolicy@update');
}
Authorizing Actions
To authorize an action using gates, you should use the allows or denies methods. Note that you are not required to pass the currently authenticated user to these methods. Laravel will automatically take care of passing the user into the gate Closure:
if (Gate::
allows('update-post', $post)) {
// The current user can update the post...
}
if (Gate::
denies('update-post', $post)) {
// The current user can't update the post...
}
If you would like to determine if a particular user is authorized to perform an action, you may use the forUser method on the Gate facade:
if (Gate::
forUser($user)->allows('update-post', $post)) {
// The user can update the post...
}
if (Gate::forUser($user)->denies('update-post', $post)) {
// The user can't update the post...
}
You may use the before method to define a callback that is run
before all other authorization checks:
boot function中で下記追加
Gate::
before(function ($user, $ability) {
if ($user->isSuperAdmin()) {
return true;
}
});
If the before callback returns a
non-null result that result will be considered the result of the check.
You may use the after method to define a callback to be executed after all other authorization checks:
Gate::
after(function ($user, $ability, $result, $arguments) {
if ($user->isSuperAdmin()) {
return true;
}
});
Generating Policies
php artisan make:policy PostPolicy
php artisan make:policy PostPolicy --model=Post
Registering Policies
class AuthServiceProvider extends ServiceProvider
{
/**
* The policy mappings for the application.
*
* @var array
*/
protected $policies = [
Post::class => PostPolicy::class,
];
Policy Auto-Discovery
Laravel can auto-discover policies as long as the model and policy follow standard Laravel naming conventions.
Any policies that are explicitly mapped in your AuthServiceProvider will take precedence over any potential auto-discovered policies.
class PostPolicy
{
/**
* Determine if the given post can be updated by the user.
*
* @param \App\User $user
* @param \App\Post $post
* @return bool
*/
public function update(User $user, Post $post)
{
return $user->id === $post->user_id;
}
}
Guest Users
By default, all gates and policies automatically return false if the incoming HTTP request was not initiated by an authenticated user. However, you may allow these authorization checks to pass through to your gates and policies by declaring an "optional" type-hint or supplying a null default value for the user argument definition:
public function update(?User $user, Post $post)
{
return $user->id === $post->user_id;
}
For certain users, you may wish to authorize all actions within a given policy. To accomplish this, define a before method on the policy. The before method will be executed before any other methods on the policy
public function before($user, $ability)
{
if ($user->isSuperAdmin()) {
return true;
}
}
If you would like to deny all authorizations for a user you should return false from the before method. If null is returned, the authorization will fall through to the policy method.
The before method of a policy class will not be called if the class doesn't contain a method with a name matching the name of the ability being checked.
Authorizing Actions Using Policies
if ($user->can('update', $post)) {
// Via The User Model
}
use App\Post;
if ($user->can('create', Post::class)) {
// Executes the "create" method on the relevant policy...
}
Laravel includes a middleware that can authorize actions before the incoming request even reaches your routes or controllers.
Route::put('/post/{post}', function (Post $post) {
// The current user may update the post...
})->middleware('can:update,post');
we're passing the can middleware two arguments. The first is the name of the action we wish to authorize and the second is the route parameter we wish to pass to the policy method.
Actions That Don't Require Model Instance
Route::post('/post', function () {
// The current user may create posts...
})->middleware('can:create,App\Post');
Via Controller Helpers
public function update(Request $request, Post $post)
{
$this->authorize('update', $post);
// The current user can update the blog post...
}
Via Blade Templates
@can('update', $post)
<!-- The Current User Can Update The Post -->
@elsecan('create', App\Post::class)
<!-- The Current User Can Create New Post -->
@endcan
@cannot('update', $post)
<!-- The Current User Can't Update The Post -->
@elsecannot('create', App\Post::class)
<!-- The Current User Can't Create New Post -->
@endcannot
