Hilari Web

34 🔑 Índice de Lección: Sincronizando Permisos a los Roles (Laravel 12 FullStack)

La lección 34 es crucial, ya que implementa la lógica del controlador para guardar y actualizar los permisos que se asignan a un rol específico, y luego comienza el proceso de restringir el acceso a los elementos de la interfaz, como el menú y las tarjetas del dashboard, basándose en esos permisos.

1. Lógica para Guardar y Sincronizar Permisos

Se completa la funcionalidad para procesar los permisos seleccionados desde la vista y asignarlos al rol.

• Creación del Método updatePermisos: Se implementa esta función en el RoleController para manejar la solicitud POST enviada desde el formulario de permisos [03:11].
  • Recepción de Datos: El método recibe el Request con los datos del formulario (incluyendo el array permisos[] con los IDs seleccionados) y el ID del rol a actualizar [03:21].
  • Sincronización (syncPermissions): Se utiliza el método syncPermissions de la librería Spatie para asociar los nuevos IDs de permisos al rol, eliminando automáticamente los permisos antiguos que no fueron seleccionados [03:36].
• Confirmación: Una vez sincronizados, el sistema redirige al usuario con un mensaje de éxito (Permisos asignados correctamente) [04:57].
• Prueba de Funcionalidad: Se verifica que, al seleccionar permisos para un rol (ej. Operador o Cajero) y guardar, la vista de permisos del rol refleje los checkboxes marcados [05:08].

2. Restricción de Elementos de la Interfaz (Vista)

Se inicia la restricción de visibilidad de los componentes en las vistas utilizando la directiva @can de Spatie.

2.1. Ajuste de la Caché

• Configuración de Expiración: Para que los cambios de permisos se reflejen de inmediato sin esperar 24 horas, se edita el archivo de configuración permissions.php, estableciendo el tiempo de expiración de caché en cero horas (0 hours) [07:30].
• Optimización del Sistema: Se recomienda ejecutar comandos de limpieza y optimización (cache:clear, config:clear, route:clear, view:clear, composer dump-autoload) para aplicar los cambios [12:18].

2.2. Restricción del Menú (Sidebar)

• Uso de @can: Se aplica la directiva @can para envolver los ítems del menú (admin.blade.php), haciendo que solo sean visibles si el usuario tiene el permiso específico para la ruta de índice de ese módulo [08:08].
  • Ejemplos: Se aplica a Roles, Usuarios, Espacios, y Ajustes [09:07].
• Resultado: El Operador, al no tener los permisos asignados a estos módulos, ve un menú reducido que solo muestra las opciones a las que tiene acceso (ej., Tickets y, tras la prueba, Tarifas) [10:01].

2.3. Restricción de Tarjetas del Dashboard

• Ocultar Estadísticas: Se extiende el uso de @can a la vista principal del dashboard (index.blade.php) para ocultar las tarjetas con estadísticas y contadores (como Roles Registrados, Usuarios, Espacios, etc.) [14:13].
  • Lógica: Cada tarjeta se oculta si el rol no tiene el permiso de index para el módulo correspondiente [14:33].
• Reportes: Las estadísticas generales (ingresos) también se restringen al permiso de reportes.index [20:05].
• Resultado Final en Dashboard: El Operador solo visualiza los contadores de Tickets (y otros módulos que se le asignen), más elementos básicos como la hora y el calendario, cumpliendo con su rol [20:51].

3. Problema Pendiente: Protección de Rutas (Middleware)

Aunque el menú y las vistas ya están restringidas, el video identifica una vulnerabilidad crítica:

• Acceso Directo: Un usuario sin el permiso, como el Operador, todavía puede acceder directamente a rutas sensibles si conoce la URL (ej., escribe /usuarios en la barra de direcciones) [21:44].
• Próximo Paso: El siguiente capítulo se enfocará en proteger todas las rutas en el archivo web.php utilizando middleware para evitar el acceso directo a URLs no autorizadas [22:20].