LaravelLaravel認可イントロダクションゲートゲートの記述アクションの認可ポリシーの作成ポリシーの生成ポリシーの登録ポリシーの記述ポリシーのメソッドモデルを持たないメソッドポリシーフィルタポリシーを使ったアクションの認可Userモデルによる認可ミドルウェアによる認可コントローラヘルパによる認可Bladeテンプレートによる認可イントロダクションLaravelは組み込み済みの認証サービスに加え、特定のリソースに対するユーザアクションを認可する簡単な手法も提供しています。認証と同様に、Laravelの認可のアプローチはシンプルで、主に2つの認可アクションの方法があります。ゲートとポリシーです。ゲートとポリシーは、ルートとコントローラのようなものであると考えてください。ゲートはシンプルな、クロージャベースのアプローチを認可に対してとっています。一方のコントローラに似ているポリシーとは、特定のモデルやリソースに対するロジックをまとめたものです。最初にゲートを説明し、次にポリシーを確認しましょう。ゲートとポリシーをアプリケーション上、相互に反する機能と捉えないことは重要です。ほとんどのアプリケーションでゲートとポリシーは混在して使われますが、それで正しいのです。管理者のダッシュボードのように、モデルやリソースとは関連しないアクションに対し、ゲートは主に適用されます。それに対し、ポリシーは特定のモデルやリソースに対するアクションを認可したい場合に、使用する必要があります。ゲートゲートの記述ゲートは、特定のアクションを実行できる許可が、あるユーザにあるかを決めるクロージャのことです。通常は、App\Providers\AuthServiceProviderの中で、Gateファサードを使用し、定義します。ゲートは常に最初の引数にユーザインスタンスを受け取ります。関連するEloquentモデルのような、追加の引数をオプションとして受け取ることもできます。});}アクションの認可ゲートを使用しアクションを認可するには、allowsメソッドを使ってください。allowsメソッドに現在認証中のユーザを渡す必要はないことに注目しましょう。Laravelが自動的にゲートクロージャにユーザを渡します。現在のユーザはこのポストを更新できる}特定のユーザがあるアクションを実行できる認可を持っているかを確認するには、GateファサードのforUserメソッドを使用します。渡されたユーザはこのポストを更新できる}ポリシー作成ポリシーの生成ポリシーは特定のモデルやリソースに関する認可ロジックを系統立てるクラスです。ブログアプリケーションの場合、Postモデルとそれに対応する、ポストを作成/更新するなどのユーザアクションを認可するPostPolicyを持つことになるでしょう。Artisanコマンドを使用し、ポリシーを生成できます。生成したポリシーはapp/Policiesディレクトリに設置されます。このディレクトリがアプリケーションに存在していなくても、Laravelにより作成されます。PostPolicymake:policyコマンドは空のポリシークラスを生成します。基本的な「CRUD」ポリシーメソッドを生成するクラスへ含めたい場合は、make:policyコマンド実行時に--modelを指定してください。サービスコンテナにより依存解決されるため、ポリシーのコンストラクタに必要な依存をタイプヒントすれば、自動的に注入されます。ポリシーの登録ポリシーができたら、登録する必要があります。インストールしたLaravelアプリケーションに含まれている、AuthServiceProviderにはEloquentモデルと対応するポリシーをマップするためのpoliciesプロパティを含んでいます。ポリシーの登録とは、指定したモデルに対するアクションの認可時に、どのポリシーを利用するかをLaravelへ指定することです。}}ポリシーの記述ポリシーのメソッドポリシーが登録できたら、認可するアクションごとにメソッドを追加します。指定したUserが指定Postインスタンスの更新をできるか決める、updataメソッドをPostPolicyに定義してみましょう。updateメソッドはUserとPostインスタンスを引数で受け取り、ユーザが指定Postの更新を行う認可を持っているかを示す、trueかfalseを返します。この例の場合、ユーザのidとポストのuser_idが一致するかを確認しましょう。}}必要に応じ、様々なアクションを認可するために、追加のメソッドをポリシーに定義してください。色々なPostアクションを認可するために、viewやdeleteメソッドを追加できます。ポリシーのメソッドには好きな名前を自由につけられることを覚えておいてください。ポリシーを--modelオプションを付け、Artisanコマンドにより生成した場合、view、create、update、deleteアクションが含まれています。モデルを持たないメソッドポリシーメソッドの中には、現在の認証ユーザのみを受け取り、認可するためのモデルを必要としないものもあります。この状況は、createアクションを認可する場合に、よく現れます。ブログを作成する場合、どんなポストかにはかかわらず、そのユーザが作成可能かを認可したいでしょう。createのように、モデルインスタンスを受け取らないポリシーメソッドを定義する場合は、モデルインスタンスを受け取る必要はありません。代わりに、その認証済みユーザが期待している人物かをメソッドで定義してください。ポリシー生成時に--modelオプションを使用している場合、「CRUD」に関連するポリシーメソッドはすでに定義済みです。特定のユーザには指定したポリシーの全アクションを許可したい場合があります。そのためには、beforeメソッドをポリシーへ定義してください。beforeメソッドはポリシーの他のメソッドの前に実行されるため、意図するポリシーメソッドが実際に呼び出される前に、アクションを許可する機会を提供します。この機能は主に、アプリケーションの管理者に全てのアクションを実行する権限を与えるために使用されます。}}ポリシーを使ったアクションの認可Userモデルによる確認Laravelアプリケーションに含まれるUserモデルは、アクションを認可するための便利な2つのメソッドを持っています。canとcantです。canメソッドは認可したいアクションと関連するモデルを引数に取ります。例として、ユーザが指定したPostを更新を認可するかを決めてみましょう。//}指定するモデルのポリシーが登録済みであれば適切なポリシーのcanメソッドが自動的に呼びだされ、論理型の結果が返されます。そのモデルに対するポリシーが登録されていない場合、canメソッドは指定したアクション名に合致する、ゲートベースのクロージャーを呼びだそうとします。モデルを必要としないアクションcreateのようなアクションは、モデルインスタンスを必要としないことを思い出してください。した場合は、canメソッドにはクラス名を渡してください。クラス名はアクションを認可するときにどのポリシーを使用すべきかを決めるために使われます。送信されたリクエストがルートやコントローラへ到達する前に、アクションを認可できるミドルウェアをLaravelは持っています。デフォルトでApp\Http\Kernelクラスの中でcanキーにIlluminate\Auth\Middleware\Authorizeミドルウェアが割り付けられています。あるユーザがブログポストを認可するために、canミドルウェアを使う例をご覧ください。現在のユーザはこのポストを更新できる})->middleware('can:update,post');この例では、canミドルウェアへ2つの引数を渡しています。最初の引数は認可したいアクションの名前です。2つ目はポリシーメソッドに渡したいルートパラメータです。この場合、暗黙のモデル結合を使用しているため、Postモデルがポリシーメソッドへ渡されます。ユーザに指定したアクションを実行する認可がない場合、ミドルウェアにより403ステータスコードのHTTPレスポンスが生成されます。モデルを必要としないアクションこの場合も、createのようなアクションではモデルインスタンスを必要としていません。した場合、ミドルウェアへクラス名を渡してください。クラス名はアクションを認可するときに、どのポリシーを使用するかに使われます。現在のユーザはポストを更新できる})->middleware('can:create,App\Post');コントローラヘルパによる認可Userモデルが提供している便利なメソッドに付け加え、App\Http\Controllers\Controllerベースクラスを拡張しているコントローラに対し、Laravelはauthorizeメソッドを提供しています。canメソッドと同様に、このメソッドは認可対象のアクション名と関連するモデルを引数に取ります。アクションが認可されない場合、authorizeメソッドはIlluminate\Auth\Access\AuthorizationException例外を投げ、これはデフォルトでLaravelの例外ハンドラにより、403ステータスコードのHTTPレスポンスへ変換されます。}}モデルを必要としないアクション既に説明してきたように、createのように、モデルインスタンスを必要としないアクションがあります。この場合、クラス名をauthorizeメソッドへ渡してください。クラス名はアクションの認可時に、どのポリシーを使用するのかを決めるために使われます。現在のユーザはブログポストを生成できる}Bladeテンプレートによる認可Bladeテンプレートを書くとき、指定したアクションを実行できる認可があるユーザの場合のみ、ページの一部分を表示したい場合があります。実際にポストを更新できるユーザの場合のみ、ブログポストの更新フォームを表示したい場合です。この場合、@canと@cannotディレクティブを使います。-->@endcannot両ディレクティブは@ifや@unless文を使う記述の、便利な短縮形です。上記の@canと@cannot文に対応するコードは以下のようになります。-->@endunlessモデルを必要としないアクション他の認可メソッドと同様に、アクションがモデルインスタンスを必要としない場合、@canと@cannotディレクティブへ、クラス名を渡すことができます。kawase(Translation).masterは過去のリポジトリです。注目:アイコン:ページ内リンク設置(リンクがないヘッダーへの移動では、リンクがある以前のヘッダーのハッシュをURLへ付加します。閉じる移動クリックで即時移動します。適用ボタンクリック後に、全項目まとめて適用されます。Scaffoldスカフォールド型枠生成スカフィールドLargeスクリーン表示幅640px80%90%100%インデントなし1rem2rem3rem本文フォントコードフォントフォント適用確認フォントの指定フィールドから、フォーカスが外れると、当ブロックの内容に反映されます。EnglishのDisplayもPreviewしてください。フォント設定時、表示に不具合が出た場合、当サイトのクッキーを削除してください。バックスラッシュを含むインライン\Code\Blockの例です。以下はコードブロックの例です。}}設定を保存する前に、表示が乱れないか必ず確認してください。CSSによるフォントファミリー指定の知識がない場合は、フォントを変更しないほうが良いでしょう。