Autorisation de l'utilisateur


Créer une politique
  • Générer une politique
  • Enregistrer une politique
    • Stratégie d'écriture
    • Méthodes stratégiques
    Ne contient pas de méthodes de modèle
  • Invité - Utilisateur
    • Filtre de politique
    Utiliser la stratégie pour autoriser les actions
  • via le modèle utilisateur
    • Via middleware
    • Via Controller Fonctions d'assistance
    • Via Blade Templates
    • IntroductionEn plus de fournir des services d'authentification utilisateur prêts à l'emploi, Laravel fournit également un moyen simple de gérer les actions d'autorisation des utilisateurs. Comme l'authentification des utilisateurs, la méthode d'autorisation de Laravel est simple. Il existe deux manières principales d'exploiter l'autorisation : les portes et les politiques.
    • Vous pouvez comparer les portes et les stratégies au routage et aux contrôleurs. Les portes fournissent une méthode d'autorisation simple basée sur la fermeture, tandis que les politiques sont similaires aux contrôleurs et implémentent l'authentification par autorisation en regroupant leur logique autour d'un modèle ou d'une ressource spécifique. Nous explorons d’abord les portes, puis examinons les stratégies. Lors de la création d’une application, vous n’avez pas à choisir entre utiliser exclusivement des portes ou utiliser uniquement des stratégies. La plupart des applications contiendront probablement à la fois des portes et des politiques, et elles fonctionneront correctement. Les portes sont principalement utilisées dans des endroits où les modèles et les ressources ne sont pas liés, comme pour afficher le panneau de l'administrateur. En revanche, les stratégies doivent être utilisées dans le cadre d’un modèle ou d’une ressource spécifique.
    • Portes

Writing Gates

Gates est une fonction de fermeture utilisée pour déterminer si l'utilisateur est autorisé à effectuer une action donnée, et la méthode typique consiste à utiliser Gate dans
AppProvidersAuthServiceProvider pour définissez-le. Les portes reçoivent toujours une instance utilisateur comme premier paramètre et peuvent recevoir des paramètres facultatifs, tels que le modèle Eloquent associé : AppProvidersAuthServiceProvider 中使用 Gate 来定义.  Gates 总是接收一个用户实例作为第一个参数,并且可以接收可选参数,比如相关的 Eloquent 模型:

/**
 * 注册任意用户认证、用户授权服务。
 *
 * @return void
 */
 public function boot(){ 
    $this->registerPolicies();    
    Gate::define('update-post', function ($user, $post) {  
          return $user->id == $post->user_id;  
       });
  }

Gates 也可以使用类似控制器方法 Class@method 风格的回调字符串来定义:

/**
 * 注册任意用户认证、用户授权服务。
 *
 * @return void
 */
 public function boot(){ 
    $this->registerPolicies();    
    Gate::define('update-post', 'App\Policies\PostPolicy@update');
   }

资源 Gates

你还可以使用 resource 方法去一次性的定义多个 Gate 方法:

Gate::resource('posts', 'App\Policies\PostPolicy');

上面的手动定义和以下的 Gate 定义效果是相同的:

Gate::define('posts.view', 'App\Policies\PostPolicy@view');
Gate::define('posts.create', 'App\Policies\PostPolicy@create');
Gate::define('posts.update', 'App\Policies\PostPolicy@update');
Gate::define('posts.delete', 'App\Policies\PostPolicy@delete');

默认情况下将会定义 view, create, update, 和 delete 方法。通过将一个数组作为第三个参数传给  resource 方法。你可以覆盖或者添加到默认的方法中。数组的键定义能力的名称,值定义方法的名称。例如,下面的代码将创建两个新的 Gate 定义 -  posts.imageposts.photo:

Gate::resource('posts', 'PostPolicy', [ 
   'image' => 'updateImage',    
   'photo' => 'updatePhoto',
 ]);

授权动作

使用 gates 来授权动作的时候, 你应该使用 allows 或者 denies 方法。 注意,不需要将当前已认证用户传递给这些方法。 Laravel 会自动处理好已经认证通过的用户,然后传递给 gete 闭包函数:

if (Gate::allows('update-post', $post)) { 
   // 指定当前用户可以进行更新...
  }
if (Gate::denies('update-post', $post)) { 
   // 指定当前用户不能更新...
  }

如果你想判断一个特定的用户是否已经被授权访问某个动作, 你可以使用在  Gate 在 facade 的 forUser 方法:

if (Gate::forUser($user)->allows('update-post', $post)) {
    // 用户可以更新...
  }
if (Gate::forUser($user)->denies('update-post', $post)) {
    // 用户不能更新...
  }

Gate 拦截检查

有时,你可能希望将所有能力授予特定用户。所以你可以在所有其他授权检查之前使用 before 方法来定义运行的回调:

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

如果 before 回调方法返回的是非 null 的结果,则结果将被视为检查结果。

在每次授权检查后你可以使用 after 方法定义要执行的回调。 但是,你不能从 after 回调方法中修改授权检查的结果:

Gate::after(function ($user, $ability, $result, $arguments) { 
   //
});

before 检查类似,如果 after

php artisan make:policy PostPolicy

Les portes peuvent également utiliser une méthode de contrôleur similaire Class@method style de rappels String. pour définir :
php artisan make:policy PostPolicy --model=Post

Resource Gates

Vous pouvez également utiliser la méthode resource pour obtenir une Définissez plusieurs méthodes Gate :
<?php
    namespace App\Providers;
    use App\Post;use App\Policies\PostPolicy;
    use Illuminate\Support\Facades\Gate;
    use Illuminate\Foundation\Support\Providers\AuthServiceProvider as ServiceProvider;
    class AuthServiceProvider extends ServiceProvider{  
      /**
     * 应用的策略映射。
     *
     * @var array
     */ 
     protected $policies = [  
          Post::class => PostPolicy::class,  
       ];   
     /**
     * 注册任意应用认证、应用授权服务
     *
     * @return void
     */ 
   public function boot()   
    {     
       $this->registerPolicies();   
            //   
     }
   }
La définition manuelle ci-dessus a le même effet que la définition Gate suivante :

use Illuminate\Support\Facades\Gate;
Gate::guessPolicyNamesUsing(function ($modelClass) {
    // return policy class name...
 });

Par défaut, view, create, update et delete. En passant un tableau comme troisième paramètre à la méthode resource. Vous pouvez remplacer ou ajouter des méthodes par défaut. Les clés du tableau définissent les noms des capacités et les valeurs définissent les noms des méthodes. Par exemple, le code suivant créera deux nouvelles définitions de Gate - posts.image et posts.photo :

<?php
   namespace App\Policies;use App\User;
   use App\Post;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;   
     }
 }

Actions autorisées🎜🎜Lorsque vous utilisez des portes pour autoriser des actions, vous devez utiliser autorise ou refuse méthode. Notez que l’utilisateur authentifié actuel n’a pas besoin d’être transmis à ces méthodes. Laravel gérera automatiquement l'utilisateur authentifié puis le transmettra à la fonction de fermeture gete : 🎜
/**
 * 判断用户是否可以创建请求。
 *
 * @param  \App\User  $user
 * @return bool
 */
 public function create(User $user){ 
    //
 }
🎜 Si vous souhaitez déterminer si un utilisateur spécifique a été autorisé à accéder à une action, vous pouvez utiliser Gate forUser en façade : 🎜
<?php
     namespace App\Policies;
     use App\User;use App\Post;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;  
     }
  }
🎜🎜🎜
🎜

Gate Interception Check< /h4>🎜Parfois, vous souhaiterez peut-être accorder toutes les fonctionnalités à un utilisateur spécifique. Vous pouvez donc utiliser la méthode before pour définir un rappel qui s'exécute avant toutes les autres vérifications d'autorisation : 🎜
public function before($user, $ability){
    if ($user->isSuperAdmin()) { 
       return true; 
     }
 }
🎜Si la méthode de rappel before renvoie un résultat non nul, le résultat seront considérés comme des résultats d’inspection. 🎜🎜Vous pouvez utiliser la méthode after pour définir un rappel à exécuter après chaque contrôle d'autorisation. Cependant, vous ne pouvez pas modifier le résultat de la vérification d'autorisation à partir de la méthode de rappel after : 🎜
if ($user->can('update', $post)) { 
   //
}
🎜Similaire à la vérification avant, si le après le rappel renvoie une valeur non nulle. Les résultats seront considérés comme des résultats d'inspection. 🎜🎜🎜🎜🎜🎜🎜 Créer une stratégie 🎜🎜🎜🎜🎜🎜🎜

Générer des politiques

Strategy est une classe qui organise la logique d'autorisation dans un modèle ou une ressource spécifique. Par exemple, si votre application est un blog, lorsque vous créez ou mettez à jour le blog, vous pouvez disposer d'un modèle Post et d'un PostPolicy correspondant pour autoriser les actions des utilisateurs. Post 模型和一个对应的 PostPolicy 来授权用户动作。

你可以使用 artisan 命令 artisan command 中的 make:policy artisan command 命令来生成策略。 生成的策略将放置在  app/Policies 目录中。如果在你的应用中不存在这个目录,那么 Laravel 将会为你自动生成:

use App\Post;if ($user->can('create', Post::class)) { 
   // 执行相关策略中的 "create" 方法...
 }

make:policy 命令会生成一个空的策略类。如果你想生成的类包含基本的 「CRUD」策略方法,你可以在执行命令的时候指定  --model 这个选项:

use App\Post;Route::put('/post/{post}', function (Post $post) {
    // 当前用户可以进行更新操作...
})->middleware('can:update,post');

{tip} 所有的策略会通过 Laravel 的  服务容器,来解析,允许你在策略构造器中对任何需要的依赖使用类型提示,并且自动注入。

注册策略

一旦策略存在,它就需要进行注册。新的 Laravel 应用中包含的 AuthServiceProvider 有一个 policies 属性,可以将各种模型对应到它们的策略中。注册一个策略将引导 Laravel 在授权动作访问指定模型的时候使用哪种策略:

Route::post('/post', function () {
    // 当前用户可以进行创建操作...
 })->middleware('can:create,App\Post');

策略自动发现

只要模型和策略遵循标准的 Laravel 命名约定,Laravel 就可以自动发现策略,而不是手动注册模型策略。具体而言,策略必须位于包含模型的目录下的 Policies 目录中。因此,例如模型可以放在 app 目录中,而策略可以放在 app/Policies 目录中。此外,策略名称必须与模型名称匹配,并具有 Policy 后缀。因此,User 模型将对应于 UserPolicy 类。

如果您想提供自己的策略发现逻辑,可以使用 Gate :: guessPolicyNamesUsing 方法注册自定义回调。通常,应该从应用程序的 AuthServiceProviderboot 方法调用此方法:

<?php
     namespace App\Http\Controllers;
     use App\Post;use Illuminate\Http\Request;
     use App\Http\Controllers\Controller;
     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);     
       // 当前用户可以更新博客...   
      }
  }

{note} 在 AuthServiceProvider

Vous pouvez utiliser la commande artisan make:policy dans la commande artisan artisan command pour générer la politique. Les politiques générées seront placées dans le répertoire app/Policies. Si ce répertoire n'existe pas dans votre application, Laravel le générera automatiquement pour vous :
/**
 * 创建一个新的博客
 *
 * @param  Request  $request
 * @return Response
 * @throws \Illuminate\Auth\Access\AuthorizationException
 */
 public function create(Request $request){ 
    $this->authorize('create', Post::class);  
    // 当前用户可以新建博客...
  }

La commande make:policy générera une classe de stratégie vide. Si la classe que vous souhaitez générer contient des méthodes de stratégie "CRUD" de base, vous pouvez spécifier l'option --model lors de l'exécution de la commande :

<?php
    namespace App\Http\Controllers;
    use App\Post;use Illuminate\Http\Request;
    use App\Http\Controllers\Controller;
    class PostController extends Controller{ 
       public function __construct() 
          {       
            $this->authorizeResource(Post::class, 'post');  
           }
     }
{tip} Toutes les stratégies passeront par le service de Laravel Le conteneur, pour l'analyse, vous permet d'utiliser des indices de type pour toutes les dépendances requises dans le constructeur de stratégie et de les injecter automatiquement.

Enregistrement des politiques

Une fois qu'une politique existe, elle doit être enregistrée. Le AuthServiceProvider inclus dans les nouvelles applications Laravel possède un attribut policies qui mappe divers modèles à leurs politiques. L'enregistrement d'une stratégie indiquera à Laravel quelle stratégie utiliser lors de l'autorisation d'actions pour accéder au modèle spécifié :
@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

Découverte automatique de la stratégie

🎜As tant que le modèle En suivant les conventions et stratégies de dénomination standard de Laravel, Laravel peut découvrir automatiquement les stratégies au lieu d'enregistrer manuellement les stratégies de modèle. Plus précisément, les stratégies doivent être situées dans le répertoire Policies sous le répertoire contenant le modèle. Ainsi, par exemple, les modèles peuvent être placés dans le répertoire app et les politiques peuvent être placées dans le répertoire app/Policies. De plus, le nom de la stratégie doit correspondre au nom du modèle et comporter le suffixe Policy. Par conséquent, le modèle User correspondra à la classe UserPolicy. 🎜🎜Si vous souhaitez fournir votre propre logique de découverte de politique, vous pouvez enregistrer un rappel personnalisé à l'aide de la méthode Gate::guessPolicyNamesUsing. Généralement, cette méthode doit être appelée à partir de la méthode boot du AuthServiceProvider de l'application : 🎜
@if (Auth::user()->can('update', $post))  
  <!-- The Current User Can Update The Post -->
@endif
@unless (Auth::user()->can('update', $post))   
 <!-- The Current User Can't Update The Post -->
@endunless
🎜{note} Explicitement dans le AuthServiceProvider Toutes les stratégies mappées auront priorité sur les stratégies de découverte automatique. 🎜🎜🎜🎜🎜🎜🎜🎜🎜Stratégie d'écriture🎜🎜🎜🎜🎜🎜🎜

Méthodes de stratégie

Une fois la politique d'autorisation enregistrée, vous pouvez ajouter des méthodes pour chaque action après autorisation. Par exemple, nous définissons une méthode update dans PostPolicy, qui déterminera si l'Utilisateur spécifié peut mettre à jour le Post spécifié. > Exemple. PostPolicy 中定义一个 update 方法,它会判断指定的 User 是否可以更新指定的 Post 实例。

update 方法接收 UserPost 实例作为参数,并且应该返回 true 或者 false 来表明用户是否被授权更新指定的 Post 。所以在这个例子中,我们需要判断用户的 id 是否和 post 中的 user_id 匹配。

@can('create', App\Post::class) 
   <!-- The Current User Can Create Posts -->
@endcan
@cannot('create', App\Post::class)   
      <!-- The Current User Can't Create Posts -->
@endcannot

你可以继续为这个授权策略定义额外的方法。比如,你可以定义 view 或者 delete 方法来授权 Post 的多种行为,还可以为自定义的策略方法起一个你自己喜欢的名字。

{tip} 如果在 Artisan 控制台生成策略时,使用 --model 选项,它会包含进去 viewcreateupdatedelete 动作方法。

不包含模型方法

一些策略方法只接收当前认证通过的用户作为参数,而不用传入与授权相关的模型实例。最常见的应用场景就是授权 create 动作。比如,如果你正在创建一篇博客,你可能希望先检查一下当前用户是否有权限创建它。

当定义一个不需要传入模型实例的策略方法时,比如 create 方法,它就是不接收模型实例作为参数。你应该定义这个方法只接收授权过的用户作为参数。

rrreee

访客用户

默认情况下,如果传入的 HTTP 请求不是经过身份验证的用户发起的,那么所有的 gates 和策略都会自动返回 false。 然而,你可以允许这些授权检查通过声明一个『可选的』类型提示或为用户参数定义提供 null

La méthode update reçoit les instances User et Post comme paramètres et doit renvoyer true ou false code> pour indiquer si l'utilisateur est autorisé à mettre à jour le Post spécifié. Ainsi, dans cet exemple, nous devons déterminer si l'id de l'utilisateur correspond au user_id dans la publication.

rrreeeVous pouvez continuer à définir des méthodes supplémentaires pour cette politique d'autorisation. Par exemple, vous pouvez définir les méthodes view ou delete pour autoriser divers comportements de Post, et vous pouvez également créer votre propre méthode de stratégie personnalisée Like. le nom.

{tip} Si vous utilisez l'option --model lors de la génération d'une stratégie dans la console Artisan, elle sera incluse dans view, create Méthodes d'action , update et delete.
🎜🎜
🎜🎜Ne contient pas de méthodes de modèle 🎜🎜Certaines méthodes de stratégie ne reçoivent que le authentification actuelle Transmettez l'utilisateur en tant que paramètre au lieu de transmettre l'instance de modèle liée à l'autorisation. Le scénario d'application le plus courant consiste à autoriser l'action create. Par exemple, si vous créez un blog, vous souhaiterez peut-être d'abord vérifier si l'utilisateur actuel est autorisé à le créer. 🎜🎜Lors de la définition d'une méthode de stratégie qui ne nécessite pas de transmission d'instance de modèle, telle que la méthode create, elle ne reçoit pas d'instance de modèle en tant que paramètre. Vous devez définir cette méthode pour accepter uniquement les utilisateurs autorisés comme paramètres. 🎜rrreee🎜🎜🎜
🎜🎜Utilisateurs invités🎜🎜Par défaut si la requête HTTP entrante n'est pas authentifiée Si initiée par un utilisateur, toutes les portes et politiques renverront automatiquement false. Cependant, vous pouvez autoriser la transmission de ces contrôles d'autorisation dans vos portes et politiques en déclarant un indice de type "facultatif" ou en fournissant une valeur par défaut null pour les définitions des paramètres utilisateur : 🎜rrreee🎜🎜🎜 🎜🎜🎜

Filtres de politique

Pour un utilisateur spécifique, vous souhaiterez peut-être autoriser toutes les actions via une politique spécifiée. Pour atteindre cet objectif, vous pouvez définir une méthode avant dans la stratégie. La méthode before sera exécutée avant toutes les autres méthodes de la politique, fournissant ainsi un moyen d'autoriser des actions autres que la méthode de politique spécifiée pour effectuer des jugements. Le scénario le plus courant pour cette fonctionnalité est que l'administrateur de l'application autorisée a accès à toutes les actions : before 方法。 before 方法会在策略中其它所有方法之前执行,这样提供了一种方式来授权动作而不是指定的策略方法来执行判断。这个功能最常见的场景是授权应用的管理员可以访问所有动作:

rrreee

如果你想拒绝某个用户所有的授权,你应当在 before 方法中返回 false 。如果返回值是 null ,那么授权会在这个策略中失败。

{note} 策略类的 before 方法不会被调用,如果该类不包含与被检查的功能名称相符的方法。

使用策略授权动作

通过用户模型

Laravel 内置的 User 模型包含两个有用的方法来授权动作: cancant。这个 can 方法需要指定授权的动作以及相关的模型。例如,判断是否授权一个用户更新指定的 Post 模型:

rrreee

如果指定模型的 「策略已被注册 」, can 方法会自动调用合适的策略并返回一个 boolean 值。如果没有策略注册到这个模型,can 方法会尝试调用和指定动作名称相匹配的基于闭包的 Gate。

不需要指定模型的动作

记住,一些动作,比如 create 并不需要指定模型实例。在这种情况下,可传递一个类名给 can 方法。这个类名将被用于判定使用哪种策略授权动作:

rrreee

通过中间件

Laravel 包含一个可以在请求到达路由或者控制器之前就进行动作授权的中间件。默认情况下, IlluminateAuthMiddlewareAuthorize 中间件被指定到你的 AppHttpKernel 类中的 can 键上。让我们用一个授权用户更新博客的例子来讲解一下 can 这个中间件的使用:

rrreee

在这个例子中,我们传给了 can 中间件两个参数。第一个参数是需要授权的动作名称,第二个参数是我们希望传递给策略方法的路由参数。在这种情况下,我们使用了「 隐式路由绑定」,一个 Post 模型会被传递给策略方法。如果用户不被授权访问指定的动作,这个中间件将会生成带有 403rrreee

Si vous souhaitez refuser toutes les autorisations à un utilisateur, vous devez renvoyer false< dans le avant< /code> méthode /code> . Si la valeur de retour est null , l'autorisation échouera dans cette stratégie.
{note} La méthode before d'une classe de stratégie ne sera pas appelée si la classe ne contient pas de méthode avec le nom de la fonction vérifiée. 🎜
🎜🎜
🎜

Utilisation des actions d'autorisation de stratégie🎜🎜
🎜🎜Par modèle utilisateur🎜🎜 Le modèle Utilisateur contient deux méthodes utiles pour autoriser des actions : can et cant. Cette méthode can doit spécifier l'action autorisée et le modèle associé. Par exemple, pour déterminer si un utilisateur est autorisé à mettre à jour un modèle Post spécifié : 🎜rrreee🎜Si les "politiques du modèle spécifié ont été enregistrées", < La méthode code>can appellera automatiquement la stratégie appropriée et renverra une valeur booléenne. Si aucune stratégie n'est enregistrée avec ce modèle, la méthode can tentera d'appeler une porte basée sur la fermeture qui correspond au nom d'action spécifié. 🎜
🎜

Pas besoin de spécifier les actions du modèle

🎜N'oubliez pas que certaines actions, telles que create, n'ont pas besoin de spécifier être spécifié instance de modèle. Dans ce cas, transmettez un nom de classe à la méthode can. Ce nom de classe sera utilisé pour déterminer quelle action d'autorisation de politique utiliser : 🎜rrreee🎜🎜
🎜🎜 Pass Middleware🎜🎜Laravel comprend un middleware qui peut autoriser des actions avant que la requête n'atteigne la route ou le contrôleur. Par défaut, le middleware IlluminateAuthMiddlewareAuthorize est attribué à la clé can dans votre classe AppHttpKernel. Utilisons l'exemple d'un utilisateur autorisé mettant à jour un blog pour expliquer l'utilisation du middleware can : 🎜rrreee🎜Dans cet exemple, nous avons passé deux paramètres au middleware can. Le premier paramètre est le nom de l'action qui nécessite une autorisation, et le deuxième paramètre est le paramètre de routage que nous souhaitons transmettre à la méthode de stratégie. Dans ce cas, nous utilisons une « liaison de route implicite » et un modèle Post sera transmis à la méthode stratégique. Si l'utilisateur n'est pas autorisé à accéder à l'action spécifiée, ce middleware générera une réponse HTTP avec le code d'état 403. 🎜🎜🎜

Pas besoin de spécifier des actions de modèle

De même, certaines actions comme create peuvent ne pas nécessiter d'instance de modèle. Dans ce cas, vous pouvez transmettre un nom de classe au middleware. Lors de l'autorisation de cette action, ce nom de classe sera utilisé pour déterminer quelle stratégie utiliser : create 这样的动作可能不需要模型实例。在这种情况下,你可以传一个类名给中间件。当授权这个动作时,这个类名将被用来判断使用哪个策略:

rrreee

通过控制器辅助函数

除了在 User 模型中提供辅助方法以外,Laravel 也为继承  AppHttpControllersController 这个基类的控制器提供了一个有用的 authorize 方法。就像 can 方法一样,这个方法需要接收你想授权的动作和相关的模型作为参数。如果这个动作没有被授权, authorize 方法会抛出一个 IlluminateAuthAccessAuthorizationException 的异常,然后 Laravel 默认的异常处理器会将这个异常转化成带有  403 状态码的 HTTP 响应。

rrreee

不需要指定模型的动作

和之前讨论的一样,一些动作,比如 create 并不需要指定模型实例的动作。在这种情况下,你可以传递一个类名给 authorize 方法。当授权这个动作时,这个类名将被用来判断使用哪个策略:

rrreee

授权资源控制器

如果你使用的是 资源控制器,那么你就可以在控制器构造方法里使用 authorizeResource 方法。该方法会把合适 can 中间件附加到资源控制器相应的方法中。

authorizeResource 方法接收模板类名作为第一个参数,包含模型 ID 的路由 / 请求参数的名称作为其第二个参数:

rrreee

{提示} 你可以使用带有 --model 选项的 make:policy 命令去快速生成基于给定模型的策略类::php artisan make:policy PostPolicy --model=Post

通过 Blade 模板

当编写 Blade 模板时,你可能希望页面的指定部分只展示给授权访问指定动作的用户。比如,你可能希望只展示更新的表单给有权更新博客的用户。在这样情况下,你可以使用 @can@cannot 等一系列指令:

rrreee

这些指令是编写 @if@unless 语句的捷径。 @can@cannotrrreee

Grâce aux fonctions auxiliaires du contrôleur

🎜En plus de fournir des méthodes auxiliaires dans le modèle User, Laravel fournit également des contrôles qui héritent de la classe de base de AppHttpControllersController L'auteur fournit une méthode authorize utile. Tout comme la méthode can, cette méthode prend en paramètres l'action que vous souhaitez autoriser et le modèle associé. Si cette action n'est pas autorisée, la méthode authorize lèvera une exception de IlluminateAuthAccessAuthorizationException, puis le gestionnaire d'exceptions par défaut de Laravel convertira cette exception en exception avec 403 < /code> Code d'état pour la réponse HTTP. 🎜rrreee
🎜🎜Pas besoin de spécifier les actions du modèle🎜🎜Comme indiqué précédemment, certaines actions, telles que create, n'ont pas besoin de spécifier un action d’instance de modèle. Dans ce cas, vous pouvez transmettre un nom de classe à la méthode authorize. Lors de l'autorisation de cette action, ce nom de classe sera utilisé pour déterminer quelle stratégie utiliser : 🎜rrreee
🎜🎜Autoriser le contrôleur de ressources🎜🎜Si vous utilisez un contrôleur de ressources, alors vous pouvez utiliser la méthode authorizeResource dans le constructeur du contrôleur. Cette méthode attachera le middleware can approprié à la méthode correspondante du contrôleur de ressources. La méthode 🎜🎜authorizeResource reçoit le nom de la classe de modèle comme premier paramètre, et le nom du paramètre route/request contenant l'ID du modèle comme deuxième paramètre : 🎜rrreee
🎜{Tip} Vous peut utiliser Utilisez la commande make:policy avec l'option --model pour générer rapidement une classe de stratégie basée sur un modèle donné : php artisan make:policy PostPolicy - -model=Publier. 🎜
🎜🎜
🎜

Modèles Via Blade

🎜 Lors de l'écriture de modèles Blade, vous souhaiterez peut-être que des parties spécifiques de la page soient affichées uniquement aux utilisateurs autorisés à accéder à des actions spécifiques. Par exemple, vous souhaiterez peut-être afficher les formulaires mis à jour uniquement aux utilisateurs autorisés à mettre à jour leur blog. Dans ce cas, vous pouvez utiliser une série d'instructions telles que @can et @cannot : 🎜rrreee🎜Ces instructions sont écrites par @if et @unless
. Les instructions @can et @cannot sont respectivement converties en instructions suivantes : 🎜rrreee🎜🎜

Actions sans modèle

Comme la plupart des autres méthodes d'autorisation, si l'action ne nécessite pas d'instance de modèle, vous pouvez transmettre le nom de la classe à la directive @ can@ cannot :

rrreee
Cet article est apparu pour la première fois sur le site Web LearnKu.com.