Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Condiciones de uso en las reglas de seguridad de Firebase Cloud Storage

Esta guía se basa en el aprender la sintaxis básica del lenguaje de reglas de seguridad Firebase guía para mostrar cómo añadir condiciones a sus Reglas Firebase de seguridad para almacenamiento en la nube.

El bloque de construcción fundamental de almacenamiento en la nube en Reglas de seguridad es la condición. Una condición es una expresión booleana que determina si se debe permitir o denegar una operación en particular. Para las reglas básicas, el uso de true y false literales como las condiciones prefectamenta funciona bien. Pero las reglas de seguridad de Firebase para el lenguaje de almacenamiento en la nube le brindan formas de escribir condiciones más complejas que pueden:

  • Verificar la autenticación del usuario
  • Validar datos entrantes

Autenticación

Las reglas de seguridad de Firebase para Cloud Storage se integran con Firebase Authentication para proporcionar una poderosa autenticación basada en el usuario para Cloud Storage. Esto permite un control de acceso granular basado en reclamos de un token de autenticación de Firebase.

Cuando un autenticada realiza de usuario una solicitud contra Cloud Storage, la request.auth variable se rellena con del usuario uid ( request.auth.uid ), así como las reivindicaciones de la autenticación JWT Firebase ( request.auth.token ).

Además, al utilizar la autenticación personalizada, reclamaciones adicionales se salieron a la superficie en el request.auth.token campo.

Cuando un usuario no autenticado realiza una solicitud, el request.auth variable es null .

Con estos datos, existen varias formas comunes de utilizar la autenticación para proteger los archivos:

  • Público: ignorar request.auth
  • Autenticado privada: Asegúrate de que request.auth no es null
  • Usuario privado: Asegúrate de que request.auth.uid es igual a un camino uid
  • Grupo privado: compruebe las afirmaciones del token personalizado para que coincidan con una reclamación elegida, o lea los metadatos del archivo para ver si existe un campo de metadatos

Público

Cualquier regla que no tiene en cuenta la request.auth contexto se puede considerar un public general, ya que no tiene en cuenta el contexto de autenticación del usuario. Estas reglas pueden ser útiles para sacar a la luz datos públicos como activos de juegos, archivos de sonido u otro contenido estático.

// Anyone to read a public image if the file is less than 100kB
// Anyone can upload a public file ending in '.txt'
match /public/{imageId} {
  allow read: if resource.size < 100 * 1024;
  allow write: if imageId.matches(".*\\.txt");
}

Privado autenticado

En ciertos casos, es posible que desee que todos los usuarios autenticados de su aplicación puedan ver los datos, pero no los usuarios no autenticados. Desde el request.auth variable es null para todos los usuarios no autenticados, todo lo que tiene que hacer es comprobar el request.auth existe la variable con el fin de solicitar la autenticación:

// Require authentication on all internal image reads
match /internal/{imageId} {
  allow read: if request.auth != null;
}

Usuario privado

Con mucho, el caso de uso común para la mayoría request.auth será la de proporcionar a los usuarios individuales con permisos granulares en sus archivos: de perfil subir fotos a la lectura de los documentos privados.

Dado que los archivos de almacenamiento en la nube tienen un "camino" completa al archivo, todo lo que necesita para hacer un archivo controlado por un usuario es una pieza de información de identificación único usuario en el prefijo del nombre (por ejemplo, del usuario uid ) que se puede comprobar cuando se evalúa la regla:

// Only a user can upload their profile picture, but anyone can view it
match /users/{userId}/profilePicture.png {
  allow read;
  allow write: if request.auth.uid == userId;
}

Grupo privado

Otro caso de uso igualmente común será permitir permisos de grupo sobre un objeto, como permitir que varios miembros del equipo colaboren en un documento compartido. Hay varios enfoques para hacer esto:

  • Mint una autenticación Firebase encargo contador que contiene información adicional sobre un miembro del grupo (tal como un ID de grupo)
  • Incluir información del grupo (tal como un ID de grupo o lista de autorizados uid s) en el archivo de metadatos

Una vez que estos datos se almacenan en el token o en los metadatos del archivo, se puede hacer referencia a ellos desde dentro de una regla:

// Allow reads if the group ID in your token matches the file metadata's `owner` property
// Allow writes if the group ID is in the user's custom token
match /files/{groupId}/{fileName} {
  allow read: if resource.metadata.owner == request.auth.token.groupId;
  allow write: if request.auth.token.groupId == groupId;
}

Solicitar evaluación

Envíos, descargas, cambios en los metadatos y eliminaciones se evalúan mediante la request enviada al almacenamiento en la nube. Además de la identificación única del usuario y la carga útil de autenticación Firebase en el request.auth objeto como se describió anteriormente, la request variable contiene la ruta del archivo donde se realiza la solicitud, el tiempo de cuando se recibe la solicitud, y el nuevo resource valor si la solicitud es una escritura. También se incluyen los encabezados HTTP y el estado de autenticación.

La request objeto también contiene el ID único del usuario y la carga útil de autenticación Firebase en el request.auth objeto, que se explicará más adelante en el usuario Seguridad basada en sección de la documentación.

Una lista completa de propiedades en la request objeto está disponible a continuación:

Propiedad Tipo Descripción
auth mapa <cadena, cadena> Cuando un usuario se registra en, ofrece uid , ID de usuario único y token , un mapa de reclamaciones Firebase autenticación JWT. De lo contrario, será null .
params mapa <cadena, cadena> Mapa que contiene los parámetros de consulta de la solicitud.
path camino Un path que representa la ruta de la petición se realiza en.
resource mapa <cadena, cadena> El nuevo valor del recurso, presente sólo en write peticiones.
time marca de tiempo Una marca de tiempo que representa la hora del servidor en la que se evalúa la solicitud.

Evaluación de recursos

Al evaluar las reglas, es posible que también desee evaluar los metadatos del archivo que se carga, descarga, modifica o elimina. Esto le permite crear reglas complejas y poderosas que hacen cosas como permitir que solo se carguen archivos con ciertos tipos de contenido, o que solo se eliminen archivos que superen un cierto tamaño.

Firebase Reglas de seguridad para almacenamiento en la nube proporciona metadatos del archivo en el resource objeto, que contiene los pares clave / valor de los metadatos salieron a la superficie de un objeto de almacenamiento en la nube. Estas propiedades pueden ser inspeccionados en la read o write solicitudes para garantizar la integridad de los datos.

En write peticiones (tales como archivos, actualizaciones de metadatos y eliminaciones), además del resource objeto, que contiene metadatos del archivo para el archivo que actualmente existe en la ruta de solicitud, usted también tiene la capacidad de utilizar el request.resource objeto, que contiene un subconjunto de los metadatos del archivo que se escribirán si se permite la escritura. Puede utilizar estos dos valores para garantizar la integridad de los datos o hacer cumplir las restricciones de la aplicación, como el tipo o tamaño de archivo.

Una lista completa de propiedades en el resource objeto está disponible a continuación:

Propiedad Tipo Descripción
name cuerda El nombre completo del objeto
bucket cuerda El nombre del depósito en el que reside este objeto.
generation En t La generación de objetos de Google Cloud Storage de este objeto.
metageneration En t El objeto metageneration Google Cloud Storage de este objeto.
size En t El tamaño del objeto en bytes.
timeCreated marca de tiempo Una marca de tiempo que representa la hora en que se creó un objeto.
updated marca de tiempo Una marca de tiempo que representa la hora en que se actualizó por última vez un objeto.
md5Hash cuerda Un hash MD5 del objeto.
crc32c cuerda Un hash crc32c del objeto.
etag cuerda El etag asociado con este objeto.
contentDisposition cuerda La disposición de contenido asociada con este objeto.
contentEncoding cuerda La codificación de contenido asociada con este objeto.
contentLanguage cuerda El idioma del contenido asociado con este objeto.
contentType cuerda El tipo de contenido asociado con este objeto.
metadata mapa <cadena, cadena> Pares clave / valor de metadatos personalizados adicionales especificados por el desarrollador.

request.resource contiene todos estos productos con la excepción de generation , metageneration , etag , timeCreated y updated .

Validar datos

Firebase Reglas de seguridad para almacenamiento en la nube también se puede utilizar para la validación de datos, incluyendo la validación de nombre de archivo y la ruta, así como las propiedades de archivo de metadatos, como contentType y size .

service firebase.storage {
  match /b/{bucket}/o {
    match /images/{imageId} {
      // Only allow uploads of any image file that's less than 5MB
      allow write: if request.resource.size < 5 * 1024 * 1024
                   && request.resource.contentType.matches('image/.*');
    }
  }
}

Funciones personalizadas

A medida que las reglas de seguridad de Firebase se vuelven más complejas, es posible que desee incluir conjuntos de condiciones en funciones que pueda reutilizar en su conjunto de reglas. Las reglas de seguridad admiten funciones personalizadas. La sintaxis de las funciones personalizadas se parece un poco a JavaScript, pero las funciones de las reglas de seguridad de Firebase están escritas en un lenguaje específico del dominio que tiene algunas limitaciones importantes:

  • Las funciones pueden contener un único return comunicado. No pueden contener ninguna lógica adicional. Por ejemplo, no pueden ejecutar bucles ni llamar a servicios externos.
  • Las funciones pueden acceder automáticamente a funciones y variables desde el ámbito en el que están definidas. Por ejemplo, una función definida dentro del service firebase.storage alcance tiene acceso al resource variable y de la nube Firestore única, una función de funciones tales como get() y exists() .
  • Las funciones pueden llamar a otras funciones pero no pueden repetirse. La profundidad total de la pila de llamadas está limitada a 10.
  • En la versión rules2 , las funciones se pueden definir variables utilizando el let palabra clave. Las funciones pueden tener cualquier número de enlaces let, pero deben terminar con una declaración return.

Una función se define con la function de palabras clave y tiene cero o más argumentos. Por ejemplo, es posible que desee combinar los dos tipos de condiciones utilizadas en los ejemplos anteriores en una sola función:

service firebase.storage {
  match /b/{bucket}/o {
    // True if the user is signed in or the requested data is 'public'
    function signedInOrPublic() {
      return request.auth.uid != null || resource.data.visibility == 'public';
    }
    match /images/{imageId} {
      allow read, write: if signedInOrPublic();
    }
    match /mp3s/{mp3Ids} {
      allow read: if signedInOrPublic();
    }
  }
}

El uso de funciones en sus reglas de seguridad de Firebase las hace más fáciles de mantener a medida que aumenta la complejidad de sus reglas.

Próximos pasos

Después de esta discusión sobre las condiciones, tiene una comprensión más sofisticada de las Reglas y está listo para:

Aprenda a manejar casos de uso básicos y conozca el flujo de trabajo para desarrollar, probar e implementar reglas: