Cómo estructurar las reglas de seguridad y la estructura de datos en Firestore para un acceso granular
Estoy construyendo una aplicación de tipo comunitario basada en Firestore donde los usuarios deberían tener un control granular sobre qué tipo de información comparten con quién.
Los usuarios pueden tener propiedades como nombre, fecha de nacimiento, etc., y para cada una de ellas pueden decidir compartirlas con uno de los siguientes grupos/roles:
- Privado
- Contactos
- Admin (administradores de organizaciones de las que el usuario es miembro)
- Organización (miembros de organizaciones a las que el usuario pertenece)
- Público (todos los usuarios de la aplicación)
Como los documentos en Firestore siempre se recuperarán en su totalidad, ya sé que de alguna manera tendré que segregar las propiedades del usuario por nivel de acceso.
Hasta ahora tengo dos enfoques:
Enfoque 1
- Almacena cada propiedad del usuario en un documento separado que contiene un campo “nivel de acceso”
- Almacena algunos “metadatos” en, por ejemplo, /user/12345/meta/roles, para que las reglas de seguridad puedan hacer referencia a esos documentos para validar el acceso
Beneficios:
– Estructura sencilla
– Flexibilidad
– (Casi) sin duplicación de datos
Desventajas:
– Muchas lecturas de documentos para obtener el perfil del usuario
Enfoque 2
- Almacena el perfil del usuario, por ejemplo, en /user/12345/profile/private y duplica la información “pública” en /user/12345/profile/public, y haz lo mismo para cada nivel de acceso.
Beneficios:
– Menos lecturas de documentos
Desventajas:
– Complejidad
– Se siente “incorrecto” duplicar tanta información
¿Alguien tiene experiencia con esto y alguna sugerencia o enfoque alternativo que pueda compartir?
Pregunta adicional:
Digamos que almaceno la lista de miembros de una organización en una subcolección, que solo es accesible para los miembros de la organización (por motivos de privacidad). ¿No significa eso que al consultar esa lista de miembros desde el lado del cliente, tengo que hacerlo “a ciegas”, es decir, no puedo saber si el usuario puede acceder a ese documento hasta que lo intente realmente? El hecho de que la consulta pueda fallar me diría que el usuario no es realmente miembro de esa organización.
¿Considerarías que este tipo de consulta configurada para el fracaso es una “mala práctica”? ¿Hay alguna alternativa que aún permita mantener la lista de miembros privada?
davy.ai
Para la primera pregunta, ambos enfoques tienen sus ventajas y desventajas. El enfoque 1 es fácil de estructurar y flexible, pero puede resultar en muchas lecturas de documentos para obtener el perfil completo de un usuario. El enfoque 2 reduce la cantidad de lecturas de documentos, pero introduce complejidad y la posibilidad de duplicación de datos.
Una alternativa podría ser utilizar subcolecciones para cada nivel de acceso, con una referencia al usuario en cada subcolección. Esto permitiría realizar consultas fácilmente sobre todos los usuarios con un cierto nivel de acceso, manteniendo el perfil del usuario en un solo documento. Sin embargo, este enfoque puede introducir complejidad en las reglas de seguridad y en las consultas.
En cuanto a la pregunta complementaria, no necesariamente es una mala práctica intentar una consulta que pueda fallar debido a las reglas de seguridad. Sin embargo, puede no ser el enfoque más eficiente. Una alternativa podría ser que el cliente primero consulte las membresías de la organización del usuario y luego utilice esa información para determinar a qué listas de miembros pueden acceder. Esto reduciría la cantidad de consultas fallidas y mejoraría el rendimiento. Otra alternativa podría ser utilizar Cloud Functions para recuperar la lista de miembros en nombre del cliente y solo devolver los datos si el usuario tiene los permisos necesarios.