Laravel 6.x 認可

イントロダクションIntroduction

Laravelは組み込み済みの認証サービスに加え、特定のリソースに対するユーザーアクションを認可する簡単な手法も提供しています。認証と同様に、Laravelの認可のアプローチはシンプルで、主に２つの認可アクションの方法があります。ゲートとポリシーです。In addition to providing authentication[/docs/{{version}}/authentication] services out of the box, Laravel also provides a simple way to authorize user actions against a given resource. Like authentication, Laravel's approach to authorization is simple, and there are two primary ways of authorizing actions: gates and policies.

ゲートとポリシーは、ルートとコントローラのようなものであると考えてください。ゲートはシンプルな、クロージャベースのアプローチを認可に対してとっています。一方のコントローラに似ているポリシーとは、特定のモデルやリソースに対するロジックをまとめたものです。最初にゲートを説明し、次にポリシーを確認しましょう。Think of gates and policies like routes and controllers. Gates provide a simple, Closure based approach to authorization while policies, like controllers, group their logic around a particular model or resource. We'll explore gates first and then examine policies.

アプリケーション構築時にゲートだけを使用するか、それともポリシーだけを使用するかを決める必要はありません。ほとんどのアプリケーションでゲートとポリシーは混在して使われますが、それで正しいのです。管理者のダッシュボードのように、モデルやリソースとは関連しないアクションに対し、ゲートは主に適用されます。それに対し、ポリシーは特定のモデルやリソースに対するアクションを認可したい場合に、使用する必要があります。You do not need to choose between exclusively using gates or exclusively using policies when building an application. Most applications will most likely contain a mixture of gates and policies, and that is perfectly fine! 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

ゲートの記述Writing Gates

ゲートは、特定のアクションを実行できる許可が、あるユーザーにあるかを決めるクロージャのことです。通常は、App\Providers\AuthServiceProviderの中で、Gateファサードを使用し、定義します。ゲートは常に最初の引数にユーザーインスタンスを受け取ります。関連するEloquentモデルのような、追加の引数をオプションとして受け取ることもできます。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:

/**
 * 全認証／認可サービスの登録
 *
 * @return void
 */
public function boot()
{
    $this->registerPolicies();

    Gate::define('edit-settings', function ($user) {
        return $user->isAdmin;
    });

    Gate::define('update-post', function ($user, $post) {
        return $user->id === $post->user_id;
    });
}

コントローラのように、ゲートはClass@method形式のコールバック文字列を使い定義することも可能です。Gates may also be defined using a Class@method style callback string, like controllers:

/**
 * 全認証／認可サービスの登録
 *
 * @return void
 */
public function boot()
{
    $this->registerPolicies();

    Gate::define('update-post', 'App\Policies\PostPolicy@update');
}

アクションの認可Authorizing Actions

ゲートを使用しアクションを認可するには、allowsとdeniesメソッドを使ってください。両メソッドに現在認証中のユーザーを渡す必要はないことに注目しましょう。Laravelが自動的にゲートクロージャにユーザーを渡します。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('edit-settings')) {
    // 現在のユーザーは設定を変更できる
}

if (Gate::allows('update-post', $post)) {
    // 現在のユーザーはこのポストを更新できる
}

if (Gate::denies('update-post', $post)) {
    // 現在のユーザーはこのポストを更新できない
}

特定のユーザーがあるアクションを実行できる認可を持っているかを確認するには、GateファサードのforUserメソッドを使用します。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)) {
    // 渡されたユーザーはこのポストを更新できる
}

if (Gate::forUser($user)->denies('update-post', $post)) {
    // ユーザーはこのポストを更新できない
}

anyとnoneメソッドを使い、複数のアクションの許可を一度に指定できます。You may authorize multiple actions at a time with the any or none methods:

if (Gate::any(['update-post', 'delete-post'], $post)) {
    // ユーザーはポストの更新と削除ができる
}

if (Gate::none(['update-post', 'delete-post'], $post)) {
    // ユーザーはポストの更新と削除ができない
}

認証か例外を投げるAuthorizing Or Throwing Exceptions

認証を試み、そのユーザーが指定したアクションの実行が許されていない場合は、自動的にIlluminate\Auth\Access\AuthorizationException例外を投げる方法を取るには、Gate::authorizeメソッドを使用します。AuthorizationExceptionは自動的に403 HTTPレスポンスへ変換されます。If you would like to attempt to authorize an action and automatically throw an Illuminate\Auth\Access\AuthorizationException if the user is not allowed to perform the given action, you may use the Gate::authorize method. Instances of AuthorizationException are automatically converted to 403 HTTP response:

Gate::authorize('update-post', $post);

// アクションが認証された…

追加コンテキストの指定Supplying Additional Context

認可アビリティのゲートメソッド（allows、denies、check、any、none、authorize、can、cannot）と認可Bladeディレクティブ（@can、@cannot、@canany）では２番めの引数として配列を受け取れます。これらの配列要素はゲートにパラメータとして渡されたもので、認可の可否を決定する際に、追加コンテキストとして利用できます。The gate methods for authorizing abilities (allows, denies, check, any, none, authorize, can, cannot) and the authorization Blade directives[#via-blade-templates] (@can, @cannot, @canany) can receive an array as the second argument. These array elements are passed as parameters to gate, and can be used for additional context when making authorization decisions:

Gate::define('create-post', function ($user, $category, $extraFlag) {
    return $category->group > 3 && $extraFlag === true;
});

if (Gate::check('create-post', [$category, $extraFlag])) {
    // このユーザーはポストを新規作成できる
}

ゲートレスポンスGate Responses

ここまでは、単純な論理値を返すゲートのみを見てきました。しかしながら、エラーメッセージを含んだ、より詳細なレスポンスを返したい場合もあるでしょう。そのためには、ゲートからIlluminate\Auth\Access\Responseを返します。So far, we have only examined gates that return simple boolean values. However, sometimes you may wish to return a more detailed response, including an error message. To do so, you may return a Illuminate\Auth\Access\Response from your gate:

use Illuminate\Auth\Access\Response;
use Illuminate\Support\Facades\Gate;

Gate::define('edit-settings', function ($user) {
    return $user->isAdmin
                ? Response::allow()
                : Response::deny('You must be a super administrator.');
});

認可レスポンスをゲートから返す場合、Gate::allowsメソッドはシンプルに論理値を返します。ゲートから返される完全な認可レスポンスを取得したい場合は、Gate::inspectを使います。When returning an authorization response from your gate, the Gate::allows method will still return a simple boolean value; however, you may use the Gate::inspect method to get the full authorization response returned by the gate:

$response = Gate::inspect('edit-settings', $post);

if ($response->allowed()) {
    // アクションは認可された…
} else {
    echo $response->message();
}

もちろん、アクションを許可できない場合、AuthorizationExceptionを投げるためにGate::authorizeメソッドを使うと、認可レスポンスが提供するエラーメッセージは、HTTPレスポンスへ伝わります。Of course, when using the Gate::authorize method to throw an AuthorizationException if the action is not authorized, the error message provided by the authorization response will be propagated to the HTTP response:

Gate::authorize('edit-settings', $post);

// アクションは認可された…

ゲートチェックのインターセプトIntercepting Gate Checks

特定のユーザーに全アビリティーへ許可を与えたい場合もあります。beforeメソッドは、他のすべての認可チェック前に実行される、コールバックを定義します。Sometimes, you may wish to grant all abilities to a specific user. You may use the before method to define a callback that is run before all other authorization checks:

Gate::before(function ($user, $ability) {
    if ($user->isSuperAdmin()) {
        return true;
    }
});

beforeコールバックでNULL以外の結果を返すと、チェックの結果とみなされます。If the before callback returns a non-null result that result will be considered the result of the check.

afterメソッドで、すべての認可チャック後に実行されるコールバックを定義することも可能です。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;
    }
});

beforeチェックと同様に、afterコールバックからNULLでない結果を返せば、その結果はチェック結果として取り扱われます。Similar to the before check, if the after callback returns a non-null result that result will be considered the result of the check.

ポリシー作成Creating Policies

ポリシーの生成Generating Policies

ポリシーは特定のモデルやリソースに関する認可ロジックを系統立てるクラスです。たとえば、ブログアプリケーションの場合、Postモデルとそれに対応する、ポストを作成／更新するなどのユーザーアクションを認可するPostPolicyを持つことになるでしょう。Policies are classes that organize authorization logic around a particular model or resource. For example, if your application is a blog, you may have a Post model and a corresponding PostPolicy to authorize user actions such as creating or updating posts.

make:policy Artisanコマンドを使用し、ポリシーを生成できます。生成したポリシーはapp/Policiesディレクトリに設置されます。このディレクトリがアプリケーションに存在していなくても、Laravelにより作成されます。You may generate a policy using the make:policy artisan command[/docs/{{version}}/artisan]. The generated policy will be placed in the app/Policies directory. If this directory does not exist in your application, Laravel will create it for you:

php artisan make:policy PostPolicy

make:policyコマンドは空のポリシークラスを生成します。基本的な「CRUD」ポリシーメソッドを生成するクラスへ含めたい場合は、make:policyコマンド実行時に--modelを指定してください。The make:policy command will generate an empty policy class. If you would like to generate a class with the basic "CRUD" policy methods already included in the class, you may specify a --model when executing the command:

php artisan make:policy PostPolicy --model=Post

lightbulb">Tip!! 全ポリシーはLaravelの サービスコンテナにより依存解決されるため、ポリシーのコンストラクタに必要な依存をタイプヒントすれば、自動的に注入されます。{tip} All policies are resolved via the Laravel service container[/docs/{{version}}/container], allowing you to type-hint any needed dependencies in the policy's constructor to have them automatically injected.

ポリシーの登録Registering Policies

ポリシーができたら、登録する必要があります。インストールしたLaravelアプリケーションに含まれている、AuthServiceProviderにはEloquentモデルと対応するポリシーをマップするためのpoliciesプロパティを含んでいます。ポリシーの登録とは、指定したモデルに対するアクションの認可時に、どのポリシーを利用するかをLaravelへ指定することです。Once the policy exists, it needs to be registered. The AuthServiceProvider included with fresh Laravel applications contains a policies property which maps your Eloquent models to their corresponding policies. Registering a policy will instruct Laravel which policy to utilize when authorizing actions against a given model:

<?php

namespace App\Providers;

use App\Policies\PostPolicy;
use App\Post;
use Illuminate\Foundation\Support\Providers\AuthServiceProvider as ServiceProvider;
use Illuminate\Support\Facades\Gate;

class AuthServiceProvider extends ServiceProvider
{
    /**
     * アプリケーションにマップ付されたポリシー
     *
     * @var array
     */
    protected $policies = [
        Post::class => PostPolicy::class,
    ];

    /**
     * アプリケーションの全認証／認可サービスの登録
     *
     * @return void
     */
    public function boot()
    {
        $this->registerPolicies();

        //
    }
}

ポリシーの自動検出Policy Auto-Discovery

モデルポリシーをいちいち登録する代わりに、モデルとポリシーの標準命名規則にしたがっているポリシーを自動的にLaravelは見つけます。具体的にはモデルが含まれているディレクトリの下に存在する、Policiesディレクトリ中のポリシーです。たとえば、モデルがappディレクトリ下にあれば、ポリシーはapp/Policiesディレクトリへ置く必要があります。さらに、ポリシーの名前は対応するモデルの名前へ、Policyサフィックスを付けたものにする必要があります。ですから、Userモデルに対応させるには、UserPolicyクラスと命名します。Instead of manually registering model policies, Laravel can auto-discover policies as long as the model and policy follow standard Laravel naming conventions. Specifically, the policies must be in a Policies directory below the directory that contains the models. So, for example, the models may be placed in the app directory while the policies may be placed in the app/Policies directory. In addition, the policy name must match the model name and have a Policy suffix. So, a User model would correspond to a UserPolicy class.

独自のポリシー発見ロジックを利用したい場合、Gate::guessPolicyNamesUsingメソッドでカスタムコールバックを登録します。通常このメソッドは、AuthServiceProviderのbootメソッドから呼び出すべきでしょう。If you would like to provide your own policy discovery logic, you may register a custom callback using the Gate::guessPolicyNamesUsing method. Typically, this method should be called from the boot method of your application's AuthServiceProvider:

use Illuminate\Support\Facades\Gate;

Gate::guessPolicyNamesUsing(function ($modelClass) {
    // ポリシークラス名を返す
});

Note: note AuthServiceProvider中で明確にマップされたポリシーは、自動検出される可能性のあるポリシーよりも優先的に扱われます。{note} Any policies that are explicitly mapped in your AuthServiceProvider will take precedence over any potential auto-discovered policies.

ポリシーの記述Writing Policies

ポリシーのメソッドPolicy Methods

ポリシーが登録できたら、認可するアクションごとにメソッドを追加します。たとえば、指定したUserが指定Postインスタンスの更新をできるか決める、updataメソッドをPostPolicyに定義してみましょう。Once the policy has been registered, you may add methods for each action it authorizes. For example, let's define an update method on our PostPolicy which determines if a given User can update a given Post instance.

updateメソッドはUserとPostインスタンスを引数で受け取り、ユーザーが指定Postの更新を行う認可を持っているかを示す、trueかfalseを返します。ですから、この例の場合、ユーザーのidとポストのuser_idが一致するかを確認しましょう。The update method will receive a User and a Post instance as its arguments, and should return true or false indicating whether the user is authorized to update the given Post. So, for this example, let's verify that the user's id matches the user_id on the post:

<?php

namespace App\Policies;

use App\Post;
use App\User;

class PostPolicy
{
    /**
     * ユーザーにより指定されたポストが更新可能か決める
     *
     * @param  \App\User  $user
     * @param  \App\Post  $post
     * @return bool
     */
    public function update(User $user, Post $post)
    {
        return $user->id === $post->user_id;
    }
}

必要に応じ、さまざまなアクションを認可するために、追加のメソッドをポリシーに定義してください。たとえば、色々なPostアクションを認可するために、viewやdeleteメソッドを追加できます。ただし、ポリシーのメソッドには好きな名前を自由につけられることを覚えておいてください。You may continue to define additional methods on the policy as needed for the various actions it authorizes. For example, you might define view or delete methods to authorize various Post actions, but remember you are free to give your policy methods any name you like.

lightbulb">Tip!! ポリシーを--modelオプションを付け、Artisanコマンドにより生成した場合、viewAny、view、create、update、delete、restore、forceDeleteアクションが含まれています。{tip} If you used the --model option when generating your policy via the Artisan console, it will already contain methods for the viewAny, view, create, update, delete, restore, and forceDelete actions.

ポリシーレスポンスPolicy Responses

これまで、シンプルな論理値を返すポリシーメソッドだけを見てきました。しかし、エラーメッセージを含むより詳細なレスポンスを返したいこともあります。それには、ポリシーメソッドからIlluminate\Auth\Access\Responseを返してください。So far, we have only examined policy methods that return simple boolean values. However, sometimes you may wish to return a more detailed response, including an error message. To do so, you may return an Illuminate\Auth\Access\Response from your policy method:

use Illuminate\Auth\Access\Response;

/**
 * このユーザーにより、指定ポストが更新できるか判定
 *
 * @param  \App\User  $user
 * @param  \App\Post  $post
 * @return \Illuminate\Auth\Access\Response
 */
public function update(User $user, Post $post)
{
    return $user->id === $post->user_id
                ? Response::allow()
                : Response::deny('You do not own this post.');
}

ポリシーから認可レスポンスを返す場合、Gate::allowsメソッドはシンプルな論理値を返します。しかし、ゲートから完全な認可レスポンスを取得するには、Gate::inspectメソッドを使用します。When returning an authorization response from your policy, the Gate::allows method will still return a simple boolean value; however, you may use the Gate::inspect method to get the full authorization response returned by the gate:

$response = Gate::inspect('update', $post);

if ($response->allowed()) {
    // アクションは認可された…
} else {
    echo $response->message();
}

もちろん、アクションを許可できない場合、AuthorizationExceptionを投げるためにGate::authorizeメソッドを使うと、認可レスポンスが提供するエラーメッセージは、HTTPレスポンスへ伝わります。Of course, when using the Gate::authorize method to throw an AuthorizationException if the action is not authorized, the error message provided by the authorization response will be propagated to the HTTP response:

Gate::authorize('update', $post);

// アクションは認可された…

モデルを持たないメソッドMethods Without Models

ポリシーメソッドの中には、現在の認証ユーザーのみを受け取り、認可するためのモデルを必要としないものもあります。この状況は、createアクションを認可する場合に、よく現れます。たとえば、ブログを作成する場合、どんなポストかにはかかわらず、そのユーザーが作成可能かを認可したいでしょう。Some policy methods only receive the currently authenticated user and not an instance of the model they authorize. This situation is most common when authorizing create actions. For example, if you are creating a blog, you may wish to check if a user is authorized to create any posts at all.

createのように、モデルインスタンスを受け取らないポリシーメソッドを定義する場合は、モデルインスタンスを受け取る必要はありません。代わりに、その認証済みユーザーが期待している人物かをメソッドで定義してください。When defining policy methods that will not receive a model instance, such as a create method, it will not receive a model instance. Instead, you should define the method as only expecting the authenticated user:

/**
 * 指定されたユーザーがポストを作成できるかを決める
 *
 * @param  \App\User  $user
 * @return bool
 */
public function create(User $user)
{
    //
}

ゲストユーザーGuest Users

HTTPリクエストが認証済みユーザーにより開始されたものでなければ、すべてのゲートとポリシーは自動的にデフォルトとしてfalseを返します。しかし、「オプショナル」なタイプヒントを宣言するか、ユーザーの引数宣言にnullデフォルトバリューを指定することで、ゲートやポリシーに対する認可チェックをパスさせることができます。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:

<?php

namespace App\Policies;

use App\Post;
use App\User;

class PostPolicy
{
    /**
     * ユーザーにより指定されたポストが更新可能か決める
     *
     * @param  \App\User  $user
     * @param  \App\Post  $post
     * @return bool
     */
    public function update(?User $user, Post $post)
    {
        return optional($user)->id === $post->user_id;
    }
}

ポリシーフィルターPolicy Filters

特定のユーザーには指定したポリシーの全アクションを許可したい場合があります。それには、beforeメソッドをポリシーへ定義してください。beforeメソッドはポリシーの他のメソッドの前に実行されるため、意図するポリシーメソッドが実際に呼び出される前で、アクションを許可する機会を提供します。この機能は主に、アプリケーションの管理者にすべてのアクションを実行する権限を与えるために使用されます。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, giving you an opportunity to authorize the action before the intended policy method is actually called. This feature is most commonly used for authorizing application administrators to perform any action:

public function before($user, $ability)
{
    if ($user->isSuperAdmin()) {
        return true;
    }
}

ユーザーに対して全認可を禁止したい場合は、beforeメソッドからfalseを返します。nullを返した場合、その認可の可否はポリシーメソッドにより決まります。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.

Note: note クラスがチェックするアビリティと一致する名前のメソッドを含んでいない場合、ポリシークラスのbeforeメソッドは呼び出されません。{note} 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

Userモデルによる確認Via The User Model

Laravelアプリケーションに含まれるUserモデルは、アクションを認可するための便利な２つのメソッドを持っています。canとcantです。canメソッドは認可したいアクションと関連するモデルを引数に取ります。例として、ユーザーが指定したPostを更新を認可するかを決めてみましょう。The User model that is included with your Laravel application includes two helpful methods for authorizing actions: can and cant. The can method receives the action you wish to authorize and the relevant model. For example, let's determine if a user is authorized to update a given Post model:

if ($user->can('update', $post)) {
    //
}

指定するモデルのポリシーが登録済みであれば適切なポリシーのcanメソッドが自動的に呼びだされ、論理型の結果が返されます。そのモデルに対するポリシーが登録されていない場合、canメソッドは指定したアクション名に合致する、ゲートベースのクロージャを呼びだそうとします。If a policy is registered[#registering-policies] for the given model, the can method will automatically call the appropriate policy and return the boolean result. If no policy is registered for the model, the can method will attempt to call the Closure based Gate matching the given action name.

モデルを必要としないアクションActions That Don't Require Models

createのようなアクションは、モデルインスタンスを必要としないことを思い出してください。そうした場合は、canメソッドにはクラス名を渡してください。クラス名はアクションを認可するときにどのポリシーを使用すべきかを決めるために使われます。Remember, some actions like create may not require a model instance. In these situations, you may pass a class name to the can method. The class name will be used to determine which policy to use when authorizing the action:

use App\Post;

if ($user->can('create', Post::class)) {
    // 関連するポリシーの"create"メソッドが実行される
}

ミドルウェアによる認可Via Middleware

送信されたリクエストがルートやコントローラへ到達する前に、アクションを認可できるミドルウェアをLaravelは持っています。デフォルトでApp\Http\Kernelクラスの中でcanキーにIlluminate\Auth\Middleware\Authorizeミドルウェアが割り付けられています。あるユーザーがブログポストを認可するために、canミドルウェアを使う例をご覧ください。Laravel includes a middleware that can authorize actions before the incoming request even reaches your routes or controllers. By default, the Illuminate\Auth\Middleware\Authorize middleware is assigned the can key in your App\Http\Kernel class. Let's explore an example of using the can middleware to authorize that a user can update a blog post:

use App\Post;

Route::put('/post/{post}', function (Post $post) {
    // 現在のユーザーはこのポストを更新できる
})->middleware('can:update,post');

この例では、canミドルウェアへ２つの引数を渡しています。最初の引数は認可したいアクションの名前です。２つ目はポリシーメソッドに渡したいルートパラメータです。この場合、暗黙のモデル結合を使用しているため、Postモデルがポリシーメソッドへ渡されます。ユーザーに指定したアクションを実行する認可がない場合、ミドルウェアは403ステータスコードのHTTPレスポンスを生成します。In this example, 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. In this case, since we are using implicit model binding[/docs/{{version}}/routing#implicit-binding], a Post model will be passed to the policy method. If the user is not authorized to perform the given action, a HTTP response with a 403 status code will be generated by the middleware.

モデルを必要としないアクションActions That Don't Require Models

この場合も、createのようなアクションではモデルインスタンスを必要としません。このようなケースでは、ミドルウェアへクラス名を渡してください。クラス名はアクションを認可するときに、どのポリシーを使用するかの判断に使われます。Again, some actions like create may not require a model instance. In these situations, you may pass a class name to the middleware. The class name will be used to determine which policy to use when authorizing the action:

Route::post('/post', function () {
    // 現在のユーザーはポストを更新できる
})->middleware('can:create,App\Post');

コントローラヘルパによる認可Via Controller Helpers

Userモデルが提供している便利なメソッドに付け加え、App\Http\Controllers\Controllerベースクラスを拡張しているコントローラに対し、Laravelはauthorizeメソッドを提供しています。canメソッドと同様に、このメソッドは認可対象のアクション名と関連するモデルを引数に取ります。アクションが認可されない場合、authorizeメソッドはIlluminate\Auth\Access\AuthorizationException例外を投げ、これはデフォルトでLaravelの例外ハンドラにより、403ステータスコードのHTTPレスポンスへ変換されます。In addition to helpful methods provided to the User model, Laravel provides a helpful authorize method to any of your controllers which extend the App\Http\Controllers\Controller base class. Like the can method, this method accepts the name of the action you wish to authorize and the relevant model. If the action is not authorized, the authorize method will throw an Illuminate\Auth\Access\AuthorizationException, which the default Laravel exception handler will convert to an HTTP response with a 403 status code:

<?php

namespace App\Http\Controllers;

use App\Http\Controllers\Controller;
use App\Post;
use Illuminate\Http\Request;

class PostController extends Controller
{
    /**
     * 指定したポストの更新
     *
     * @param  Request  $request
     * @param  Post  $post
     * @return Response
     * @throws \Illuminate\Auth\Access\AuthorizationException
     */
    public function update(Request $request, Post $post)
    {
        $this->authorize('update', $post);

        // 現在のユーザーはブログポストの更新が可能
    }
}

モデルを必要としないアクションActions That Don't Require Models

すでに説明してきたように、createのように、モデルインスタンスを必要としないアクションがあります。この場合、クラス名をauthorizeメソッドへ渡してください。クラス名はアクションの認可時に、どのポリシーを使用するのかを決めるために使われますAs previously discussed, some actions like create may not require a model instance. In these situations, you should pass a class name to the authorize method. The class name will be used to determine which policy to use when authorizing the action:

/**
 * 新しいブログポストの生成
 *
 * @param  Request  $request
 * @return Response
 * @throws \Illuminate\Auth\Access\AuthorizationException
 */
public function create(Request $request)
{
    $this->authorize('create', Post::class);

    // 現在のユーザーはブログポストを生成できる
}

リソースコントローラの認可Authorizing Resource Controllers

リソースコントローラを活用している場合、コントローラのコンストラクタの中で、authorizeResourceメソッドを使用できます。このメソッドはリソースコントローラのメソッドへ適切なcanミドルウェア定義を付加します。If you are utilizing resource controllers[/docs/{{version}}/controllers#resource-controllers], you may make use of the authorizeResource method in the controller's constructor. This method will attach the appropriate can middleware definitions to the resource controller's methods.

authorizeResourceメソッドは最初の引数にモデルのクラス名を受け取ります。モデルのIDを含むルート／リクエストパラメータ名を第２引数に受け取ります。The authorizeResource method accepts the model's class name as its first argument, and the name of the route / request parameter that will contain the model's ID as its second argument:

<?php

namespace App\Http\Controllers;

use App\Http\Controllers\Controller;
use App\Post;
use Illuminate\Http\Request;

class PostController extends Controller
{
    public function __construct()
    {
        $this->authorizeResource(Post::class, 'post');
    }
}

次のコントローラメソッドが、対応するポリシーメソッドにマップされます。The following controller methods will be mapped to their corresponding policy method:

lightbulb">Tip!! 指定するモデルのポリシークラスを手っ取り早く生成するには、--modelオプションを付けmake:policyコマンドを実行します。php artisan make:policy --model=Post{tip} You may use the make:policy command with the --model option to quickly generate a policy class for a given model: php artisan make:policy PostPolicy --model=Post.

Bladeテンプレートによる認可Via Blade Templates

Bladeテンプレートを書くとき、指定したアクションを実行できる認可があるユーザーの場合のみ、ページの一部分を表示したい場合があります。たとえば、実際にポストを更新できるユーザーの場合のみ、ブログポストの更新フォームを表示したい場合です。この場合、@canと@cannot系ディレクティブを使います。When writing Blade templates, you may wish to display a portion of the page only if the user is authorized to perform a given action. For example, you may wish to show an update form for a blog post only if the user can actually update the post. In this situation, you may use the @can and @cannot family of directives:

@can('update', $post)
    <!-- 現在のユーザーはポストを更新できる -->
@elsecan('create', App\Post::class)
    <!-- 現在のユーザーはポストを作成できる -->
@endcan

@cannot('update', $post)
    <!-- 現在のユーザーはポストを更新できない -->
@elsecannot('create', App\Post::class)
    <!-- 現在のユーザーはポストを更新できない -->
@endcannot

これらのディレクティブは@ifや@unless文を使う記述に対する、便利な短縮形です。上記の@canと@cannot文に対応するコードは以下のようになります。These directives are convenient shortcuts for writing @if and @unless statements. The @can and @cannot statements above respectively translate to the following statements:

@if (Auth::user()->can('update', $post))
    <!-- 現在のユーザーはポストを更新できる -->
@endif

@unless (Auth::user()->can('update', $post))
    <!-- The 現在のユーザーはポストを更新できない -->
@endunless

指定するリスト中の認可アビリティをユーザーが持っているかを判定することもできます。@cananyディレクティブを使用します。You may also determine if a user has any authorization ability from a given list of abilities. To accomplish this, use the @canany directive:

@canany(['update', 'view', 'delete'], $post)
    // 現在のユーザーはポストとの更新、閲覧、削除ができる
@elsecanany(['create'], \App\Post::class)
    // 現在のユーザーはポストを作成できる
@endcanany

モデルを必要としないアクションActions That Don't Require Models

他の認可メソッド同様に、アクションでモデルインスタンスが必要でない場合、@canと@cannotディレクティブへクラス名を渡すことができます。Like most of the other authorization methods, you may pass a class name to the @can and @cannot directives if the action does not require a model instance:

@can('create', App\Post::class)
    <!-- 現在のユーザーはポストを更新できる -->
@endcan

@cannot('create', App\Post::class)
    <!-- 現在のユーザーはポストを更新できない -->
@endcannot

追加コンテキストの指定Supplying Additional Context

認可アクションにポリシーを使う場合、数多くの認可関数やヘルパで第２引数に配列を渡せます。配列の第１要素はどのポリシーを呼び出すべきか決定するために使われます。残りの配列要素は、ポリシーメソッドへのパラメータとして渡されたもので、認可の可否を決定する際に追加のコンテキストとして利用できます。例として、次のような追加の$categoryパラメータを持つ、PostPolicyメソッド定義を考えてみましょう。When authorizing actions using policies, you may pass an array as the second argument to the various authorization functions and helpers. The first element in the array will be used to determine which policy should be invoked, while the rest of the array elements are passed as parameters to the policy method and can be used for additional context when making authorization decisions. For example, consider the following PostPolicy method definition which contains an additional $category parameter:

/**
 * このユーザーが指定されたポストを更新できるか判断する
 *
 * @param  \App\User  $user
 * @param  \App\Post  $post
 * @param  int  $category
 * @return bool
 */
public function update(User $user, Post $post, int $category)
{
    return $user->id === $post->user_id &&
           $category > 3;
}

認証済みのユーザーが指定ポストを更新できるかの判断を試みる時、次のようにこのポリシーメソッドを呼び出せます。When attempting to determine if the authenticated user can update a given post, we can invoke this policy method like so:

/**
 * 指定ポストの更新
 *
 * @param  Request  $request
 * @param  Post  $post
 * @return Response
 * @throws \Illuminate\Auth\Access\AuthorizationException
 */
public function update(Request $request, Post $post)
{
    $this->authorize('update', [$post, $request->input('category')]);

    // 現在のユーザーは、このブログポストを更新できる…
}