Configuración de Shinobi

Configuración del paquete de roles Shinobi en Laravel

CREAR PERMISOS CON EL PAQUETE SHINOBI

Una vez instalado el paquete Shinobi como se muestra en la entrada Shinobi en Laravel  y después de haber comprobado que las tablas han sido creadas en la base de datos se puede comenzar a crear los permisos.

Los permisos se crean mediante un seeder: 

  1. <?php
  2. use Illuminate\Database\Seeder;
  3. use Caffeinated\Shinobi\Models\Permission;
  4. class PermissionTableSeeder extends Seeder
  5. {
  6. /**
  7. * Run the database seeds.
  8. *
  9. * @return void
  10. */
  11. public function run()
  12. {
  13. //Users
  14. Permission::create([
  15. "name" => "Navegar usuarios",
  16. "slug" => "users.index",
  17. "description" => "Lista y navega todos los usuarios del sistema",
  18. ]);
  19. Permission::create([
  20. "name" => "Ver detalle de usuario",
  21. "slug" => "users.show",
  22. "description" => "Ver en detalle cada usuario del sistema",
  23. ]);
  24. Permission::create([
  25. "name" => "Edición de usuarios",
  26. "slug" => "users.edit",
  27. "description" => "Editar cualquier dato de un usuario del sistema",
  28. ]);
  29. Permission::create([
  30. "name" => "Eliminar usuario",
  31. "slug" => "users.destroy",
  32. "description" => "Eliminar cualquier usuario del sistema",
  33. ]);
  34. //Roles
  35. Permission::create([
  36. "name" => "Navegar roles",
  37. "slug" => "roles.index",
  38. "description" => "Lista y navega todos los roles del sistema",
  39. ]);
  40. Permission::create([
  41. "name" => "Ver detalle de rol",
  42. "slug" => "roles.show",
  43. "description" => "Ver en detalle cada rol del sistema",
  44. ]);
  45. Permission::create([
  46. "name" => "Creación de roles",
  47. "slug" => "roles.create",
  48. "description" => "Ver en detalle cada rol del sistema",
  49. ]);
  50. Permission::create([
  51. "name" => "Edición de roles",
  52. "slug" => "roles.edit",
  53. "description" => "Editar cualquier dato de un rol del sistema",
  54. ]);
  55. Permission::create([
  56. "name" => "Eliminar rol",
  57. "slug" => "roles.destroy",
  58. "description" => "Eliminar cualquier rol del sistema",
  59. ]);
  60. }
  61. }

El código anterior muestra un ejemplo de un seeder con la creación de una serie de permisos donde cabe destacar que la información almacenada en el dato slug, es la más importante, puesto que es el que transmite el tipo de rol mientras que los otros dos campos solamente son descriptivos.

Una vez creados los permisos solo queda incorporarlo al método run() de la clase DatabaseSeeder y a continuación realizar una migración.

    1. <?php
    2. use Illuminate\Database\Seeder;
    3. class DatabaseSeeder extends Seeder
    4. {
    5. public function run()
    6. {
    7. $this->call([
    8. UserSeeder::class,
    9. PermissionTableSeeder::class,
    10. ]);
    11. }
    12. }

    Al haber realizado una migración anteriormente es posible que sea necesario añadir la opción fresh o refresh.

    1. php artisan migrate:refresh

    CREAR ROLES

    El siguiente paso es la creación de un UserSeeder y crear los roles que se necesiten para el proyecto. En caso de no tener claros los tipos de rol se debe añadir uno al menos para realizar las pruebas. En el código de abajo se muestra la creación de varios roles, el dato a destacar es que el rol admin de Shinobi es un tipo de rol especial que permite  disponer de acceso total.

    1. <?php
    2. use Illuminate\Database\Seeder;
    3. use Caffeinated\Shinobi\Models\Role;
    4. class UserSeeder extends Seeder
    5. {
    6. /**
    7. * Run the database seeds.
    8. *
    9. * @return void
    10. */
    11. public function run()
    12. {
    13. factory(App\User::class,22)->create([]);
    14. Role::create([
    15. "name" => "Admin",
    16. "slug" => "admin",
    17. "special" => "all-access"
    18. ]);
    19. Role::create([
    20. "name" => "Editor",
    21. "slug" => "editor",
    22. "description" => "Navegar, ver, crear, editar y eliminar",
    23. ]);
    24. Role::create([
    25. "name" => "Suscriptor",
    26. "slug" => "suscriptor",
    27. "description" => "Navegar y ver"
    28. ]);
    29. }
    30. }

    Una vez creados roles y permisos es necesario disponer del módulo auth. En caso de no tenerlo se instala. Este paquete incluye los módulos de registro y login de usuario.

    INSTALAR AUTH

    1. php artisan make:auth

    REGISTRAR MIDDLEWARES

    Lo siguiente es añadir las siguientes líneas al archivo Kernel situado en app/Http/Kernel.php en el array $routeMiddleware. Con esto se registran los middlewares que se encuentran en el paquete Shinobi.

    1. 'role' => \Caffeinated\Shinobi\Middleware\UserHasRole::class,
    2. 'permission' => \Caffeinated\Shinobi\Middleware\UserHasPermission::class

    Con los middlewares registrados es posible completar el archivo de rutas añadiendo los mismos valores slug de los permisos creados en la clase PermissionTableSeeder. A continuación se muestra una lista de rutas dentro del middleware auth. Las rutas añadidas dentro del middleware auth permiten el acceso solamente a usuarios logueados. Esta restricción de acceso es propia del módulo auth e independiente del paquete Shinobi. Para restringir mediante permisos es necesario adjuntar el método middleware a continuación de la ruta y pasando como argumento el permiso requerido, existe otra opción de implementar los middleware de Shinobi, que es pasándolos en el constructor del controlador tal como se muestra en la entrada personalizar Shinobi. 

    AÑADIR PERMISOS AL ARCHIVO DE RUTAS

    routes/web.php

    1. Route::middleware(["auth"])->group(function(){
    2. //Users
    3. Route::get("users","UserController@index")->name("users.index")
    4. ->middleware("permission:users.index");
    5. Route::put("users/{user}","UserController@update")->name("users.update")
    6. ->middleware("permission:users.edit");
    7. Route::get("users/{user}","UserController@show")->name("users.show")
    8. ->middleware("permission:users.show");
    9. Route::delete("users/{user}","UserController@destroy")->name("users.destroy")
    10. ->middleware("permission:users.destroy");
    11. Route::get("users/{user}/edit","UserController@edit")->name("users.edit")
    12. ->middleware("permission:users.edit");
    13. //Roles
    14. Route::post("roles/store","RoleController@store")->name("roles.store")
    15. ->middleware("permission:roles.create");
    16. Route::get("roles","RoleController@index")->name("roles.index")
    17. ->middleware("permission:roles.index");
    18. Route::get("roles/create","RoleController@create")->name("roles.create")
    19. ->middleware("permission:roles.create");
    20. Route::put("roles/{role}","RoleController@update")->name("roles.update")
    21. ->middleware("permission:roles.edit");
    22. Route::get("roles/{role}","RoleController@show")->name("roles.show")
    23. ->middleware("permission:roles.show");
    24. Route::delete("roles/{role}","RoleController@destroy")->name("roles.destroy")
    25. ->middleware("permission:roles.destroy");
    26. Route::get("roles/{role}/edit","RoleController@edit")->name("roles.edit")
    27. ->middleware("permission:roles.edit");
    28. });

    En el código superior se han restringido todos los métodos del crud de usuarios, es decir, que un usuario según su rol asignado puede tener acceso a uno, varios o todos los permisos dependiendo del alcance de ese rol.  

    De esta forma se restringe el acceso desde las rutas, pero todavía queda por restringir el acceso a las vistas. Para restringir de forma sencilla acceso a un botón, un enlace o una sección que el usuario no tiene acceso, Shinobi dispone de helpers que permiten restringir el acceso de forma visual.

    1. @can("users.index")
    2. <li >
    3. <a class="nav-link" href="{{ route('users.index') }}">Usuarios</a>
    4. </li>
    5. @endcan

    Nota: Recuerda que en los paréntesis se debe indicar el nombre del permiso y no de la ruta que pudiendo ser iguales puede llevar a confusión. Para entender mejor esta posible confusión es necesario observar más detenidamente el código de arriba correspondiente al archivo de rutas (routes/web.php). Al analizar los permisos uno a uno se contempla que algunos permisos están duplicados, es decir, que el mismo permiso sirve para dos rutas distintas. En concreto el método update y el método edit requieren del permiso users.edit permitiendo el acceso a las dos rutas. 

    CREAR CONTROLADOR DE USUARIOS

    Como el código de ejemplo mostrado anteriormente está dirigido a los métodos para usuarios, es necesario para las pruebas de roles disponer de tres requisitos: un controlador para los usuarios, un usuario registrado y un rol asociado a ese usuario.

    • En caso de haber comenzado el proyecto y no haberlo creado anteriormente se crea el controlador.
    1. php artisan make:controller UserController --resource
    • Para registrarse se puede navegar hacia la vista de bienvenida de Laravel welcome.php (que se accede navegando a la raíz del proyecto), o extraer el módulo y añadirlo a otra vista. El código de abajo muestra el fragmento de código que incluye Laravel 5.5, ya que desde Laravel 6 el módulo auth  no viene incluido por defecto.
    1. @if (Route::has('login'))
    2. <div class="top-right links">
    3. @auth
    4. <a href="{{ url('/home') }}">Home</a>
    5. @else
    6. <a href="{{ route('login') }}">Login</a>
    7. <a href="{{ route('register') }}">Register</a>
    8. @endauth
    9. </div>
    10. @endif
    • Para asociar el rol al usuario para las pruebas es necesario hacerlo de forma manual con cualquier gestor de base de datos. Se toma el id del usuario registrado en el paso anterior y se accede a la tabla role_user para insertar un nuevo registro. Al campo role_id añadimos el número 1 (rol Admin) y al campo user_id se añade el id del usuario. Las siguientes imágenes muestran la inserción mediante los desplegables que incluye el gestor phpMyAdmin.


















    Con el rol Admin asignado al usuario registrado, este usuario es considerado administrador con acceso total, es decir, puede acceder a cualquier ruta, requiera o no requiera permisos. El rol Admin dispone de un campo especial que permite tres posibles valores: all-access, no-access y null. Si el valor pasa a null el usuario deja de ser especial y se comporta como cualquier otro usuario dependiendo de los roles asignados.

    AÑADIR TRAIT

    El módulo está listo para asignarle los permisos a los usuarios, pero para que el sistema reconozca el sistema de roles es necesario añadir el archivo ShinobiTrait al modelo User  como viene añadido en el siguiente fragmento de código ( el código de color fucsia representa las líneas añadidas). 

    1. <?php
    2. namespace App;
    3. use Caffeinated\Shinobi\Traits\ShinobiTrait;
    4. use Illuminate\Notifications\Notifiable;
    5. use Illuminate\Foundation\Auth\User as Authenticatable;
    6. class User extends Authenticatable
    7. {
    8. use Notifiable,ShinobiTrait;
    9. protected $fillable = [
    10. 'name', 'email', 'password',
    11. ];
    12. protected $hidden = [
    13. 'password', 'remember_token',
    14. ];
    15. }

     Una vez configurado el sistema de roles junto al módulo auth es posible  crear los controladores y las vistas para que el administrador pueda manejar tanto las listas de usuarios como la de roles y así poder personalizar el sistema.

    Fuente: //www.youtube.com/channel/UCRByhHailXC3HqWL2QrYw7w

    Comentarios: 0

    Para poder comentar es necesario iniciar sesión



    Este dominio utiliza cookies de terceros para crear estadísticas y publicidad personalizada. Si continúa navegando está aceptando su uso