users seguridad firestore descripcion auth security authentication authorization firebase firepad

security - seguridad - Reglas de autorización adecuadas para contenido protegido en firebase



firebase users rules (1)

¿Existe un enfoque de mejores prácticas para las reglas de autorización adecuadas para el contenido protegido en una aplicación de Firebase

  • usando firepad específicamente
  • Por contenido protegido me refiero a donde un usuario crea un documento y solo lo comparte con ciertos otros usuarios).
  • También necesito poder consultar Firebase para todos los documentos a los que tengo acceso (documentos que creé y documentos que otros usuarios compartieron conmigo)

Algunas de mis investigaciones hasta el momento:

Método 1: URL secreta

  • Necesito saber la URL para poder ver / editar el documento

  • No es una autorización real, ya que cualquier usuario conectado que tenga acceso a esa URL podría editarla / modificarla.

  • No puedo indexar todos los documentos a los que tengo acceso

Método 2: Usar las reglas de autorización de firebase para agregar usuarios a un documento y verificar si el usuario es document.users antes de leer / escribir.

Tomado de: contenido protegido en Firebase posible?

{ "documents": { "$documents_id": { // any friend can read my post ".read": "auth.id === data.child(''owner'').val() || root.child(''users/''+data.child.owner.val()+''/users/''+auth.id).exists()", // any friend can edit my post ".write": "auth.id === data.child(''owner'').val() || root.child(''users/''+data.child.owner.val()+''/users/''+auth.id).exists()" }, users:{ // List of user.ids that have access to this document } } }

Pros:

  • Autorización / autenticación adecuada. Solo usuarios autenticados a los que se les ha otorgado acceso pueden ver / editar.

Contras:

  • No puedo consultar todos los documentos que un usuario puede editar (los que tengo o que me han compartido) (¿Es correcta esta suposición?)

Método 3: reglas de autorización de Firebase (método 2), más un almacenamiento redundante de usuarios con una matriz de documentos_administrados por cada usuario. Esta tienda de usuario solo se usaría para consultar todos los documentos a los que tiene acceso un usuario. es decir:

{ "documents": { "$documents_id": { // any friend can read my post ".read": "auth.id === data.child(''owner'').val() || root.child(''users/''+data.child.owner.val()+''/users/''+auth.id).exists()", // any friend can edit my post ".write": "auth.id === data.child(''owner'').val() || root.child(''users/''+data.child.owner.val()+''/users/''+auth.id).exists()" } }, "users":{ "$user":{ ".read": "auth.id=$user.id", ".write": "auth.id=$user.id" "$documents":{ // All the documents i have access to. This list gets ammended whenever I am granted/stripped access to a document. } } } }

Pros:

  • Autenticación / autorización adecuada

Contras:

  • Duplicar datos, tiene que lidiar con problemas de sincronización entre dos almacenes de datos. Esto simplemente no parece una buena idea.

Método 4: Grupos

Usar grupos por Otorgar acceso a ubicaciones de Firebase a un grupo de usuarios

  • Tenemos un grupo para cada documento en la tienda de datos

  • No se puede consultar fácilmente Firebase para todos los documentos a los que un usuario puede acceder

¿Hay una mejor manera de hacer esto?


Has hecho un buen trabajo al enumerar las opciones, y definitivamente estás en el camino correcto. Como ha descubierto, no hay forma de consultar basándose en las reglas de seguridad. Esto se hizo intencionalmente, ya que (dependiendo de sus reglas de seguridad) esto podría ser bastante caro (Firebase evita las consultas complejas en general por este motivo).

Entonces su método 3 es la forma correcta de hacer esto. La duplicación de datos para este tipo de situaciones es en realidad una práctica muy común. Consulte Desnormalizar sus datos es normal para una publicación de blog que entra en más detalles al respecto.

También podría hacer el método 1 con la lista de documentos duplicados. Esto es especialmente útil si desea poder "invitar" a alguien a un documento solo con una URL (que contiene la ID secreta). O puede hacer una combinación de ambos (algunos documentos deben ser "públicos pero no listados" y otros ser "privados para amigos invitados" o lo que sea).