Por ejemplo, quiero obtener todos los usuarios que son miembros de algún "espacio".
Ejemplo de regla simplificada de Firestore:
match /users/{userId} { allow read: if exists(/databases/$(database)/documents/spaces/SPACEID/members/$(userId)); }Código JS en el sitio web:
firebaseApp .firestore() .collection("users") .where( ??? ) .onSnapshot((querySnapshot) => { ... });Pude encontrar solo 2 opciones de trabajo:
spacesArray en la colección /users y use usersRef.where("spacesArray", "array-contains", "SPACEID") . Pero en este caso, cualquiera puede averiguar en qué grupos se encuentra el usuario leyendo spacesArray . Además, el problema es que estas matrices pueden ser bastante grandes, mientras que estos datos no son necesarios en el lado del cliente, lo que provoca un tráfico excesivo./databases/$(database)/documents/spaces/SPACEID/members/ y obtenga a cada usuario uno por uno. El problema con esta opción es que puede haber muchos usuarios, cada vez que se actualiza la página, se solicitarán cientos o miles de usuarios a través .get() o .onSnapshot() , que es redundante. La opción ideal sería usar un análogo del método exist exists(...) de las reglas en el campo where , o de alguna manera filtrar spacesArray del documento del usuario por motivos de confidencialidad.
Las consultas de Firestore solo pueden ordenar/filtrar datos que forman parte de los documentos que devuelve la consulta. No hay forma de ordenar/filtrar información en otro documento/colección.
Por lo tanto, su verificación de exists en las reglas de seguridad suele ser excelente para obtener documentos individuales (conocido como get en la sintaxis de reglas de seguridad más granular ), pero no para manejar lecturas masivas (conocidas como list en reglas de seguridad granular).
Si considera que la lista de espacios para la información privada de un usuario, considere almacenarla en una colección UserSpaces , que (como dice en el n. ° 2) conduce a más lecturas, o considere almacenar solo un hash unidireccional del espacio en el público formación.