database - relaciones - cómo restringir o filtrar el acceso a la base de datos según los atributos del usuario de la aplicación
relacion muchos a muchos laravel (4)
Acabo de implementar algo similar (REALbasic hablando con MySQL) en las últimas semanas para una extensión jerárquica de varias compañías a un paquete de contabilidad.
Existe un gran cuerpo de código existente que compone sentencias de SQL, por lo que tuvimos que aceptarlo y hacer una gran cantidad de auditorías para garantizar que las restricciones se incluyan en cada tabla, según corresponda. Una de ellas era la búsqueda relacionada donde las tablas de búsqueda normalmente solo se usaban en combinación con una tabla principal, pero para algunas GUI de mantenimiento se cargaba directamente la tabla de búsqueda.
Existe el peligro de revelar información implícita, como revelar que Acme Pornstars es cliente de alguna división de la compañía ;-)
La única solución para esa parte fue una construcción muy cuidadosa de los diagramas DB para mostrar todas las relaciones implícitas y una gran cantidad de código fuente de auditoría y almacenamiento, con comentarios cuidadosos para indicar las áreas que se habían aceptado como que no necesitaban restricciones adicionales.
El único patrón que he ideado para hacer esto más generalizado en el futuro es, en lugar de búsquedas explícitas de tipo region = currentRegionVar, usando un entityID arbitrario que es suministrado por una función global CurrentEntityForRole ("blah").
Esta abstracción permite compartir algunos datos e implementar pseudoentidades que representan otros límites de restricción.
No sé lo suficiente sobre Java y Spring para poder decirlo, pero ¿hay alguna manera de poder usar las vistas para proporcionar una búsqueda de una sola clave, donde las vistas están restringidas por el filtro de región?
El deseo de proporcionar agregaciones y posible intercambio de datos fue la razón por la que no bajamos por la ruta de la base de datos por separado.
He pensado demasiado en esto ahora sin una solución obviamente correcta. Puede ser una situación real de bosque para árboles, así que necesito la ayuda de Stack Overflow.
Estoy tratando de hacer cumplir el filtrado de bases de datos a nivel regional. Mi sistema tiene varios usuarios y cada uno está asignado a una oficina regional. Solo quiero que los usuarios puedan ver los datos que están asociados con su oficina regional.
Simplemente mi aplicación es: Aplicación Java -> JPA (hibernación) -> MySQL
La base de datos contiene objetos de todas las regiones, pero solo quiero que los usuarios puedan manipular objetos de su propia región. He pensado en las siguientes formas de hacerlo:
1) modificar todas las consultas de base de datos para que lean algo como select * from tablex donde region = "myregion". Esto es desagradable. No funciona bien con JPA, por ejemplo, el método entitymanager.find () solo acepta la clave principal. Por supuesto que puedo volverme nativo, pero solo tengo que perder una declaración seleccionada y mi seguridad se dispara
2) use un proxy mysql para filtrar los resultados. tipo de funky, pero luego el proxy mysql solo ve la llamada en bruto y realmente no sabe cómo debería filtrarlos (es decir, a qué región pertenece el usuario que realizó la solicitud). Ok, podría comenzar un proxy para cada región, pero comienza a ser un poco complicado ...
3) use esquemas separados para cada región. Sí, simple, estoy usando la primavera, así que podría usar RoutingDataSource para enrutar las solicitudes a través del origen de datos correcto (1 fuente de datos por esquema). Por supuesto, el problema ahora es un poco más adelante. Voy a querer filtrar por región y alguna otra categoría. Ohps.
4) ACL: no estoy seguro de esto. Si a hizo un select * from tablex; ¿Filtraría silenciosamente objetos a los que no tengo acceso o arrojaría una carga de excepciones de acceso?
¿Pero estoy pensando demasiado sobre esto? Esto parece ser un problema muy común. Debe haber alguna solución fácil que soy demasiado tonto para ver. Estoy seguro de que será algo cercano a / o en la base de datos ya que desea filtrar lo más cerca posible de la fuente, ¿pero qué?
¡No busco ser cuchareado - cualquier enlace, palabras clave, ideas, sugerencias de productos comerciales / de código abierto serían realmente apreciados! Gracias.
Buena pregunta.
Parece que el # 1 es el mejor ya que es el más flexible.
La región pasa a ser lo que está filtrando hoy, pero podría ser región + departamento + color de cabello mañana.
Si empiezas a descifrar demasiado los datos, parece que estarás trabando más duro de lo necesario para volver a unirlos todos para informar.
Estoy teniendo el mismo problema. Es difícil creer que una tarea tan común (filtrar una lista de entidades modelo basada en el perfil del usuario) no tenga una forma, un patrón o una mejor práctica "estándar" para hacerlo.
Encontré pgacl , un módulo PostgreSQL. Básicamente, hace su consulta como lo haría normalmente, y luego vira un predicado acl_access () para que funcione como un filtro.
Tal vez hay algo similar para MySQL.