“Entonces ... necesito una autorización simple. Algún tipo de rol de administrador, y tal vez el rol de editor / moderador. Ahora búscalo en google. Oh! ¡Ya hay paquetes listos para laravel!
zizaco / entrust ,
spatie / laravel-permission y otros! ¡Vamos a elegir algunos!
Así es como sucede todo. Luego, la migración del paquete agrega 5 etiquetas a la base de datos para almacenar roles, permisos y sus relaciones. Todas las reglas de autorización, como los roles
'admin' y
'editor' pueden hacer
'editar publicaciones' , se almacenan en estas tablas. Típicamente, un proyecto tiene muchas copias de la base de datos. Copias de desarrolladores, base (s) de prueba y producción. Como resultado, todas estas reglas de autorización se ven obligadas a sincronizarse entre bases de datos.
Conocí un par de proyectos donde había una copia principal de las reglas en la base de datos de producción y el resto copió todo desde allí.
La idea de usar la clase Seeder (
ejemplo ) es mucho mejor. Solo necesitas correr
php artisan db:seed AuthSeedery tiene la última versión de las reglas en la base de datos. Por lo tanto, esta clase de sembradora se convierte en una especie de Fuente Única de la Verdad. Bien, pero todavía hay muchos inconvenientes en este enfoque:
- Seeder debe ser lo suficientemente inteligente como para no solo crear roles y permisos y las conexiones entre ellos, sino también sincronizar versiones antiguas. Es decir eliminar o crear enlaces entre roles y permisos si es necesario.
- Las reglas se almacenan en la base de datos y se requiere una sincronización constante entre ellas. Cada cambio del requisito del formulario "los editores ya no deberían editar publicaciones, solo publicarlas" conduce a un cambio en la sembradora, la sincronización de la base de código a través de un git o algo así, y "¡NO OLVIDES INICIAR AuthSeeder!"
- Las reglas de autorización pueden ser complejas. Por ejemplo, una publicación puede ser editada no solo por editores o administradores, sino también por el autor de esta publicación. Por lo tanto, en lugar de un middleware simple:
['middleware' => ['permission:edit posts']]
los desarrolladores deben usar la autorización estándar de laravel:
class PostPolicy { public function edit(User $user, Post $post) { return $user->id == $post->owner_id || $user->hasPermissionTo('edit posts'); } }
Entonces, ¿quizás la forma más fácil no es la mejor?
Simplemente parece simple: coloque el paquete, ejecute la migración finalizada y listo. Desde el punto de vista del apoyo a proyectos a largo plazo, esta no es la mejor opción.
¿Intentamos analizar qué proyectos suelen necesitar? Sistema de juego de roles simple. Casi siempre un rol por usuario. Administrador Bueno, tal vez otro editor o moderador. Y estos roles tienen algunos permisos. ¡Vamos por el camino más directo! ¡Agregue un nuevo campo a la tabla de usuarios!
is_admin o
role . Luego, un par de ayudantes para la clase
Usuario :
class User { public function isAdmin(): bool {...} public function isEditor(): bool {...} }
Ahora permite. Laravel proporciona dos métodos básicos para describirlos:
puertas y
políticas . Usaré compuertas (todavía hay un pequeño truco con una función en una variable, pero para los amantes de la programación funcional no es un truco en absoluto):
$isAdmin = function (User $user) { return $user->isAdmin(); } $isEditorOrAdmin = function (User $user) { return $user->isAdmin() || $user->isEditor(); } Gate::define('foo-permission', $isAdmin); Gate::define('bar-permission', $isAdmin); Gate::define('editor-permission', $isEditorOrAdmin);
Si el proyecto necesita varios roles por usuario, simplemente agregue la tabla
user_roles y cambie los ayudantes de la clase
Usuario . ¡El contenido de la clase sembradora para * paquetes de confianza y esta autorización basada en código son casi idénticos! Pero las reglas ahora se almacenan simplemente en el código y no hay necesidad de sincronizarlas constantemente en las bases de datos.
No quiero decir que estos paquetes son inútiles. Este enfoque es muy útil en proyectos con un sistema de autorización complejo, donde el cliente mismo desea configurar roles más adelante. También hay proyectos con permisos dinámicos. Ejemplo: foro con subforos. Cada sub-foro puede tener sus propios moderadores, cada moderador tiene derechos definidos por el administrador en este sub-foro. Otro ejemplo es el telegrama y sus grupos. Hay lo mismo. Tales proyectos realmente necesitan un sistema de autorización complejo, almacenado en la base de datos, con todos sus problemas. Pero la mayoría de los demás no.
La situación con los paquetes para laravel se vuelve similar a la situación con los componentes para Delphi (recuerdan las personas mayores). Pusieron los paquetes sin dudarlo, realmente necesarios o no.
Entonces, tendría que calcular $ a + $ b en mi proyecto aquí. ¿Hay algún paquete laravel-sum?
PD: Pido disculpas por los permisos, pero no encontré una buena traducción precisa.