Estructuración de las reglas de seguridad de Cloud Firestore

Las reglas de seguridad de Cloud Firestore le permiten controlar el acceso a documentos y colecciones en su base de datos. La sintaxis de reglas flexibles le permite crear reglas que coincidan con cualquier cosa, desde todas las escrituras en toda la base de datos hasta operaciones en un documento específico.

Esta guía describe la sintaxis básica y la estructura de las reglas de seguridad. Combine esta sintaxis con las condiciones de las reglas de seguridad para crear conjuntos de reglas completos.

Declaración de servicios y bases de datos

Las reglas de seguridad de Cloud Firestore siempre comienzan con la siguiente declaración:

service cloud.firestore {
  match /databases/{database}/documents {
    // ...
  }
}

La declaración del service cloud.firestore las reglas a Cloud Firestore, lo que evita conflictos entre las reglas de seguridad de Cloud Firestore y las reglas de otros productos, como Cloud Storage.

La declaración match /databases/{database}/documents especifica que las reglas deben coincidir con cualquier base de datos de Cloud Firestore en el proyecto. Actualmente, cada proyecto tiene solo una única base de datos denominada (default) .

Reglas básicas de lectura/escritura

Las reglas básicas consisten en una declaración de match que especifica una ruta de documento y una expresión de allow detalla cuándo se permite la lectura de los datos especificados:

service cloud.firestore {
  match /databases/{database}/documents {

    // Match any document in the 'cities' collection
    match /cities/{city} {
      allow read: if <condition>;
      allow write: if <condition>;
    }
  }
}

Todas las declaraciones de coincidencia deben apuntar a documentos, no a colecciones. Una declaración de coincidencia puede apuntar a un documento específico, como en match /cities/SF o usar comodines para apuntar a cualquier documento en la ruta especificada, como en match /cities/{city} .

En el ejemplo anterior, la declaración de coincidencia utiliza la sintaxis de comodín {city} . Esto significa que la regla se aplica a cualquier documento de la colección de cities , como /cities/SF o /cities/NYC . Cuando se evalúan las expresiones de allow en la declaración de coincidencia, la variable de la city se resolverá en el nombre del documento de la ciudad, como SF o NYC .

Operaciones granulares

En algunas situaciones, es útil dividir la read y write en operaciones más granulares. Por ejemplo, es posible que su aplicación quiera aplicar condiciones diferentes en la creación de documentos que en la eliminación de documentos. O es posible que desee permitir lecturas de un solo documento pero denegar consultas grandes.

Una regla de read se puede dividir en get y list , mientras que una regla de write se puede dividir en create , update y delete :

service cloud.firestore {
  match /databases/{database}/documents {
    // A read rule can be divided into get and list rules
    match /cities/{city} {
      // Applies to single document read requests
      allow get: if <condition>;

      // Applies to queries and collection read requests
      allow list: if <condition>;
    }

    // A write rule can be divided into create, update, and delete rules
    match /cities/{city} {
      // Applies to writes to nonexistent documents
      allow create: if <condition>;

      // Applies to writes to existing documents
      allow update: if <condition>;

      // Applies to delete operations
      allow delete: if <condition>;
    }
  }
}

datos jerárquicos

Los datos en Cloud Firestore están organizados en colecciones de documentos, y cada documento puede extender la jerarquía a través de subcolecciones. Es importante comprender cómo interactúan las reglas de seguridad con los datos jerárquicos.

Considere la situación en la que cada documento de la colección de cities contiene una subcolección de landmarks de referencia. Las reglas de seguridad se aplican solo en la ruta coincidente, por lo que los controles de acceso definidos en la colección de cities no se aplican a la subcolección de landmarks de referencia. En su lugar, escribe reglas explícitas para controlar el acceso a las subcolecciones:

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      allow read, write: if <condition>;

        // Explicitly define rules for the 'landmarks' subcollection
        match /landmarks/{landmark} {
          allow read, write: if <condition>;
        }
    }
  }
}

Al anidar sentencias de match , la ruta de la sentencia de match interna siempre es relativa a la ruta de la sentencia de match externa. Por lo tanto, los siguientes conjuntos de reglas son equivalentes:

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      match /landmarks/{landmark} {
        allow read, write: if <condition>;
      }
    }
  }
}

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city}/landmarks/{landmark} {
      allow read, write: if <condition>;
    }
  }
}

Comodines recursivos

Si desea que las reglas se apliquen a una jerarquía arbitrariamente profunda, use la sintaxis de comodín recursiva, {name=**} . Por ejemplo:

service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the cities collection as well as any document
    // in a subcollection.
    match /cities/{document=**} {
      allow read, write: if <condition>;
    }
  }
}

Cuando se usa la sintaxis de comodín recursivo, la variable comodín contendrá el segmento de ruta coincidente completo, incluso si el documento se encuentra en una subcolección profundamente anidada. Por ejemplo, las reglas enumeradas anteriormente coincidirían con un documento ubicado en /cities/SF/landmarks/coit_tower y el valor de la variable del document sería SF/landmarks/coit_tower .

Tenga en cuenta, sin embargo, que el comportamiento de los comodines recursivos depende de la versión de las reglas.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the cities collection as well as any document
    // in a subcollection.
    match /cities/{city}/{document=**} {
      allow read, write: if <condition>;
    }
  }
}

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the songs collection group
    match /{path=**}/songs/{song} {
      allow read, write: if <condition>;
    }
  }
}

Si utiliza consultas de grupos de recopilación , debe utilizar la versión 2; consulte protección de consultas de grupos de recopilación .

Declaraciones de coincidencia superpuestas

Es posible que un documento coincida con más de una declaración de match . En el caso de que varias expresiones de allow coincidan con una solicitud, se permite el acceso si se true alguna de las condiciones:

service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the 'cities' collection.
    match /cities/{city} {
      allow read, write: if false;
    }

    // Matches any document in the 'cities' collection or subcollections.
    match /cities/{document=**} {
      allow read, write: if true;
    }
  }
}

En el ejemplo anterior, se permitirán todas las lecturas y escrituras en la colección de cities porque la segunda regla siempre es true , aunque la primera regla siempre es false .

Límites de las reglas de seguridad

Cuando trabaje con reglas de seguridad, tenga en cuenta los siguientes límites:

Próximos pasos

• Escribir condiciones de reglas de seguridad personalizadas .
• Lea la referencia de las reglas de seguridad .