Un ACL est une entité qui permet de vérifier qu’un utilisateur à bien les permissions pour effectuer une certaine action sur une ressource. Les utilisateurs sont souvent liés à des groupes (ex: admin, owner, ...), qui eux même sont liés à des permissions (ex: user-create, user-delete, news-read, ... ).
Les permissions sont souvent limitées à quelques actions clés (CRUD par exemple). Mais certain ACL peuvent permettre des définitions plus complexes (par exemple les droits des utilisateurs sur les fichiers de l’OS Windows). Les groupes bénéficient parfois d’un système d’héritage permettant par exemple au groupe ‘admin’ d’hériter des permissions du groupe ‘owner’. Pour ce TP, afin de simplifier notre ACL, il n’y aura pas d’héritage. Néanmoins, l’implémentation proposée devrait être suffisante pour la majorité des besoins.
Voilà le diagramme de classes:
+----------+ +----------+ +-----------+
| users | | groups | role |ressources |
| |* *| |* | *| |
| +-------------+ +--------------+ |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
+----------+ +----------+ +-----------+
Créez les tables et modèles nécessaires. Lors de la création des tables n’oubliez pas les tables pivots ! Pour que l’ORM Eloquent puisse faire les jointures automatiquement ces tables pivots doivent avoir des noms bien particuliers. De plus, dans votre Model Groupet dans votre Model User implémentez la méthode suivante:
public function hasRole($roleLabel, $ressource)
Indiquant si un rôle a été attribuée au groupe (ou à l’utilisateur) pour la ressource en question. Cela permettra ainsi de faire la gestion des droits avec un simple if, par exemple:
if ($user->hasRole('read', 'news') {
...
}
Essayez simplement de tester votre ACL en protegeant une de vos méthodes REST du TP3. Par exemple, seedez votre base de données pour qu’un utilisateur aie tous les droits et qu’un autre n’aie que les droits de lecture et de création, mais pas de suppression ni de modification des news. Exemple de nom pour ces deux groupes: 'moderator', 'contributor'. Pour le nommage des ressources, et afin de faire la partie suivante plus facilement (création d'un middleware) il est important de faire un bon choix. Celui de nommer les ressources de la même manière que Laravel nomme ses routes vers les actions REST des controllers semble être une bonne idée pour implémenter un futur automatisme dans un middleware. (Rappel: vous trouverez la description de ce nommage ici).
Une fois votre test effectué, réaliser un middleware capable d'automatiquement tester si l'utilisateur connecté a les droits d'effectuer l'action demandée. Pour ce faire, vous pouvez demander à l'artisan de créer le squelette du fichier avec la commande suivante:
php artisan make:middleware AclRestDans ce fichiers, implémentez votre gestion des droits. Pour vous aider, voici le code qui vous permettera de récupérer dans votre middleware le nom de la route actuelle:
$actionData = $request->route()->getAction();
list($resource, $action) = explode('.', $actionData["as"]);
Pour rendre votre middleware accessible à votre controller, n'oubliez pas de le rajouter dans le fichier Kernel.php. Puis utilisez le en l'ajoutant dans le constructeur de votre controlleur REST du TP3.