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 esnull
- Usuario privado: Asegúrate de que
request.auth.uid
es igual a un caminouid
- 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 resultar útiles para hacer emerger 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 | Escribe | 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 | sendero | 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 | Escribe | 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 alresource
variable y de la nube Firestore única, una función de funciones tales comoget()
yexists()
. - 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 ellet
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:
- Escribir reglas que abordan escenarios comunes .
- Construir sobre sus conocimientos mediante la revisión de las situaciones donde hay que detectar y evitar las Reglas inseguros .
- Reglas de prueba utilizando el emulador de almacenamiento en la nube y dedicado biblioteca de prueba Reglas de Seguridad .
- Revisar los métodos disponibles para la implementación de reglas .