L'exemple de cet article décrit la méthode d'implémentation de la gestion des autorisations Laravel5. Partagez-le avec tout le monde pour votre référence, les détails sont les suivants :
Réflexions sur la gestion des autorisations
Récemment, j'ai utilisé Laravel pour concevoir le backend, et le backend doit avoir une gestion des autorisations. La gestion des autorisations est essentiellement divisée en deux parties, d'abord l'authentification, puis les autorisations. La partie authentification est très simple à réaliser, c'est-à-dire que l'administrateur se connecte et enregistre la session. Laravel est également livré avec Auth pour implémenter cela. La chose la plus gênante est l'authentification des autorisations.
L'authentification par autorisation consiste essentiellement à savoir qui a le pouvoir de gérer quoi. Il y a deux dimensions ici : Qui est la dimension utilisateur ? Dans la dimension utilisateur, la granularité de la gestion des autorisations peut être un utilisateur ou un regroupement d'utilisateurs. Si les utilisateurs sont regroupés, la logique impliquée est qu'un utilisateur peut appartenir à plusieurs groupes. ? D'un autre côté, lorsqu'on gère quelque chose, cette chose a la dimension des choses. Une page est une chose, et un élément sur une page est aussi une chose. Ou pour le dire plus largement, une fonction est une chose. Le plus important pour la gestion des autorisations est donc de confirmer la granularité de ces deux dimensions. Ce n’est plus une question technique, il faut en discuter.
Sur la base de la réflexion ci-dessus, la gestion des autorisations que je souhaite faire cette fois est basée sur les individus dans la dimension utilisateur. C’est juste que les autorisations de chacun sont différentes. Dans la dimension est-ouest, j'ai défini l'itinéraire sur la plus petite unité, c'est-à-dire défini la gestion des autorisations pour un seul itinéraire.
La réflexion suivante indique ce qu'il faut utiliser pour marquer les autorisations. Vous pouvez utiliser des bits, des caractères ou des nombres entiers. Plus tard, j'ai choisi les personnages en fonction de deux considérations : 1. Les personnages sont faciles à comprendre et faciles à rechercher dans la base de données. 2. Je n'ai pas eu besoin de rechercher des personnes ayant cette autorité selon une certaine autorité, c'est-à-dire qu'il y en avait. pas besoin de recherche inversée. L'utilisation de bits, le type entier, etc. n'a que peu d'importance.
Ensuite, réfléchissez à comment le combiner avec Laravel. Puisque je dois définir des autorisations d'accès pour chaque route, j'espère bien sûr le configurer dans la gestion du routage route.php de Laravel. La meilleure chose est d'avoir un paramètre pour définir l'autorisation lors de Route::get. L’avantage est que la configuration des autorisations est simple. Au moment de décider du routage, j'ai écrit le contrôle des autorisations de manière pratique. L'inconvénient est qu'il est également évident que vous ne pouvez écrire qu'une des trois méthodes de routage Laravel. Il s'agit de la méthode Route :: (méthode).
Une fois la décision prise, commençons.
Conception du routage
Le routage de base est comme ceci
Route::post('/admin/validate', ['uses' => 'AdminController@postValidate', 'permissions'=>['admin.validate', 'admin.index']]);
Ici, une fois l'action de routage de base définie, un attribut d'autorisations est défini. Cet attribut est conçu comme. un tableau Parce que par exemple, une demande de publication peut être déclenchée sur une certaine page ou sur une autre page, alors cette demande de publication doit avoir les autorisations de routage des deux pages.
Le contrôle des autorisations de admin.validate est utilisé ici. De cette façon, les autorisations peuvent être regroupées. L'administrateur concerne uniquement les groupes liés à l'administrateur. Dans la base de données, je stockerai un tableau à deux dimensions, [admin. ] => ['validate', 'index']; Quel est l'avantage de le stocker sous forme de tableau à deux dimensions au lieu d'une dimension ? Généralement, l'affichage en arrière-plan a deux dimensions, l'une est la barre d'onglets dans l'en-tête, et l'autre est la barre de navigation sur la gauche. C'est-à-dire que ce tableau bidimensionnel a une correspondance bidimensionnelle avec les colonnes d'onglet et de navigation en arrière-plan.
Conception du middleware
D'accord, nous allons maintenant installer le middleware et définir toutes les routes pour utiliser ce middleware
<?php namespace App\Http\Middleware; use Illuminate\Support\Facades\Session; use Closure; class Permission { /** * Handle an incoming request. * * @param \Illuminate\Http\Request $request * @param \Closure $next * @return mixed */ public function handle($request, Closure $next) { $permits = $this->getPermission($request); $admin = \App\Http\Middleware\Authenticate::getAuthUser(); // 只要有一个有权限,就可以进入这个请求 foreach ($permits as $permit) { if ($permit == '*') { return $next($request); } if ($admin->hasPermission($permit)) { return $next($request); } } echo "没有权限,请联系管理员";exit; } // 获取当前路由需要的权限 public function getPermission($request) { $actions = $request->route()->getAction(); if (empty($actions['permissions'])) { echo "路由没有设置权限";exit; } return $actions['permissions']; } }
La chose la plus importante ici est que la fonction getPermission obtient le définition de l'action de cette route à partir de $request->route()->getAction(), puis obtient les autorisations de routage définies dans route.php à partir du champ d'autorisations.
Ensuite, le middleware ci-dessus a :
admin−>hasPermission(admin−>hasPermission(permit);
Cela implique la conception du modèle.
Conception du modèle
<?php namespace App\Models\Admin; use App\Models\Model as BaseModel; class Admin extends BaseModel { protected $table = 'admin'; // 判断是否有某个权限 public function hasPermission($permission) { $permission_db = $this->permissions; if(in_array($permission, $permission_db)) { return true; } return false; } // permission 是一个二维数组 public function getPermissionsAttribute($value) { if (empty($value)) { return []; } $data = json_decode($value, true); $ret = []; foreach ($data as $key => $value) { $ret[] = $key; foreach ($value as $value2) { $ret[] = "{$key}.{$value2}"; } } return array_unique($ret); } // 全局设置permission public function setPermissionsAttribute($value) { $ret = []; foreach ($value as $item) { $keys = explode('.', $item); if (count($keys) != 2) { continue; } $ret[$keys[0]][] = $keys[1]; } $this->attributes['permissions'] = json_encode($ret); } }
Dans la base de données, j'ai stocké le tableau bidimensionnel au format json et utilisé les méthodes Attribute get et set de laravel pour terminer l'intégration de json dans la base de données et externe logique du programme. Ensuite, hasPermission semble très simple, jugez simplement in_array directement et tout ira bien.
Suivi
La logique de cette authentification par autorisation sera claire. Ensuite, si un onglet ou une navigation sur la page doit être affiché aux utilisateurs avec des autorisations différentes, il vous suffit de juger
@if ($admin->hasPermission('admin.index')) @endif
dans la vue pour déterminer si l'utilisateur peut voir l'onglet.
Résumé
Il s'agit d'une implémentation pas trop compliquée des autorisations utilisateur, mais je pense qu'elle peut répondre à la plupart des besoins en arrière-plan. Bien sûr, de nombreux points peuvent être optimisés.
Par exemple, l'autorisation peut-elle prendre en charge les expressions régulières ? Si hasPermission est stockée dans nosql ou pg, il n'est pas nécessaire d'effectuer une analyse des données json. s'il y a une autorisation ou autre ?
J'espère que cet article sera utile à la conception de programmes PHP basés sur le framework Laravel.
Pour des explications plus détaillées sur les méthodes de gestion des autorisations de Laravel5 et les articles connexes, veuillez faire attention au site Web PHP chinois !