Hola. Un saludo a tod@s.
Les comento mi caso. Tengo tres tablas (Usuarios, Roles y Permisos) y una relación ManyToMany, que genera una cuarta tabla (roles_permisos), pero esta, por obvias razones no tiene entidad. La genera Doctrine.
Para esta aplicación quise llamar a los grupos que contienen los roles como Roles, y a los ROLES_ como permisos. Siendo así, Roles puede tener (n) cantidad de permisos y permisos puede pertenecer a (n) cantidad de Roles.
Al usuario le entrego un Role (un grupo de permisos). Adoptando así los permisos que son asignados al Role.
La aplicación guarda esta información, pero quiero acceder directamente al los permisos del usuario, por su role. Ejemplo:
$usuario = $this->getDoctrine->getManager()->getRepository("NombreBundle:User"); $permisosUsuario = $usuario->getRoles()->getPermisos();
Esto es lo que quiero hacer.
Mis dudas son: cómo puedo acceder a los permisos del role y cuál relación es más recomendada: many-to-many o one-to-one.
Gracias desde ya!
Respuestas
Disculpa que sea tan directo, pero en mi opinión estás resolviendo un problema innecesario. Tal y como se explica en el capítulo de Seguridad del libro de Buenas Prácticas de Symfony, las aplicaciones Symfony disponen de tres mecanismos principales para establecer los permisos de los usuarios:
- La más básica es usar los roles y guardarlos en la entidad del usuario dentro de la propiedad
roles. El valor de esta propiedad es un array que Symfony maneja automáticamente. Así que puedes definir ninguno, uno o más roles a un mismo usuario y puedes jugar con la jerarquía de roles para hacer cosas avanzadas. Lo mejor es que no tienes que hacer nada para que todo funcione bien. - Los security voters te permiten decidir, usando código PHP, si un usuario tiene permiso sobre un objeto. Puedes hacer cualquier cosa, así que es infinitamente más potente que los roles. De nuevo la ventaja es que Symfony ya se encarga de todo lo que hay que hacer, así que tu solo te tienes que centrar en escribir ese código PHP que decide si un usuario tiene permiso o no.
- Las ACL o listas de control de acceso son el mecanismo más avanzado. Son bastante complicadas de usar, configurar y mantener, así que te recomiendo que las evites a toda costa. Aún así, dan una granularidad infinita, ya que puedes definir los permisos para cada usuario y para cada objeto. De hecho, puedes incluso restringir qué métodos y qué propiedades de cada entidad puede ver cada usuario. Aún así, te aconsejo que las evites a toda costa.
@javiereguiluz
Gracias Javier. Realmente sí me estaba complicando la vida. Pero lo quería hacer para aprender más sobre Symfony.
Para esto, logré crear dos entidades: Usuarios y Grupos. Para relacionar Usuarios y Roles, se crea una relación Many-To-Many, siendo Usuarios el dueño de la relación y Grupos el "mapeador" o inverso. Todo bien hasta aquí.
Me surge un problema. Al crear los CRUD para las dos entidades, me pasa lo siguiente. En Usuarios se crea y se actualiza la información de los Grupos (roles); pero en los Grupos no pasa igual. No actualiza esta información. Sí aparecen los datos.
Según la documentación, sólo se puede actualizar y/o borrar información desde el dueño. ¿Sabrías como actualizar desde el inverso?
Saludos
@cristian_angulo
Como bien dices, Doctrine deja claro que la información no se puede actualizar desde el lado inverso (inverse side), solo desde el dueño (owning side):
Changes made only to the inverse side of an association are ignored. Make sure to update both sides of a bidirectional association (or at least the owning side, from Doctrine’s point of view).
Para solucionarlo, debes añadir a la entidad unos métodos especiales llamados adders y removers, ya que sus nombres empiezan por addXXX() y removeXXX(). En este artículo de la documentación de Symfony lo explican mejor y sobre todo, lo explican dentro del contexto de los formularios, que también tiene su cosa cuando lo juntas con este tipo de entidades.
@javiereguiluz