Asegura tu flujo de imágenes en Firebase con reglas claras y efectivas. Aquí verás cómo abrir lectura pública por ruta específica y restringir la escritura a usuarios autenticados, validando tamaño del archivo y tipo de contenido. El resultado: imágenes visibles para todos y subidas controladas solo por su dueño, con archivos válidos y ligeros.
¿Qué problema resuelven las reglas de Firebase Storage?
Las reglas por defecto de Firebase permiten escribir solo si estás autenticado, pero no contemplan rutas específicas ni validaciones finas. Para un blog con imágenes en storage, se ajustan estas reglas para que:
Cualquier usuario pueda leer imágenes públicas sin autenticarse.
Solo el propietario pueda subir archivos a su directorio.
Se valide el tamaño: menor a 5 MB.
Se verifique el tipo de archivo: solo imágenes.
¿Qué conceptos clave se aplican?
Autenticación, autorización y validación de datos: seguridad integral en storage.
Patrón de rutas con match: define reglas por directorios y subdirectorios.
Variables de ruta como {userID} y {IMG ID}: capturan valores dinámicos.
Identidad del usuario con request.auth.uid: asegura escritura solo en su carpeta.
Tipos MIME con content type y matches: restringen a image/.*.
¿Qué estructura de carpetas se usa?
Directorio raíz de imágenes: “IMGs post/”.
Subcarpeta por usuario: “IMGs post/{userID}/”.
Archivo dentro: “IMGs post/{userID}/{IMG ID}”.
¿Cómo configurar lectura pública y escritura segura?
Se parte del tab de reglas en la consola. Se ajusta el match global a rutas concretas y se añaden condiciones para validar archivo, usuario y tipo de contenido.
¿Cómo abrir lectura pública por ruta específica?
Aplicar un match a “IMGs post/**” para permitir read sin autenticación.
Mantener write con restricciones en una regla más específica.
rules_version ='2';service firebase.storage{ match /b/{bucket}/o {// Lectura pública de todas las imágenes bajo "IMGs post/" match /IMGs post/{allPaths=**}{ allow read:iftrue;}// Escritura segura por usuario y archivo específico match /IMGs post/{userID}/{imgID}{ allow read:iftrue; allow write:if request.auth!=null&& request.auth.uid== userID
&& request.resource.size<5*1024*1024&& resource.contentType.matches('image/.*');}}}
¿Cómo limitar el tamaño a 5 MB?
Usar una condición que compare el tamaño del archivo subido con 5 × 1024 × 1024.
Beneficio: evita archivos pesados que afecten rendimiento y costos.
Puntos clave:
Solo se aceptan archivos < 5 MB.
La validación ocurre en el servidor de Firebase.
¿Cómo validar tipo de archivo e identidad del usuario?
Tipo de contenido: usar resource.contentType.matches('image/.*').
Identidad: exigir request.auth != null y request.auth.uid == userID.
Esto garantiza que:
Solo imágenes válidas se suban.
Cada usuario escribe en “su” directorio y no en el de otros.
¿Qué errores comunes y reto final se proponen?
Al probar la subida, puede fallar si no hay sesión iniciada: “no puede leer la propiedad UID en el post controller”. La causa es clara: no hay autenticación, por lo que no existe UID en el cliente.
¿Cómo resolver el error de autenticación?
Iniciar sesión, por ejemplo con Google.
Opcional: validar antes de abrir la ventana de post para evitar intentos de subida sin sesión.
Efecto al autenticarse:
La subida cumple reglas: usuario autenticado, carpeta propia, imagen válida y menos de 5 MB.
El post se crea con imagen y link del video visibles.
¿Qué reto práctico queda pendiente?
Habilitar en el formulario de comentarios la subida de un archivo máximo de 1 MB.
Permitir la subida solo si el usuario está autenticado.
Sugerencias de implementación:
Reutilizar el patrón de match con carpeta específica para comentarios.
Replicar validación de tamaño y autenticación.
¿Tienes dudas o quieres compartir cómo estructuraste tus reglas? Deja tu comentario y cuéntanos qué validaciones añadiste. Próximamente: hosting de Firebase.
Reglas de Seguridad en Firebase Storage para Blogs
Reglas de Seguridad en Firebase Storage para Blogs
Recursos
Resumen
Asegura tu flujo de imágenes en Firebase con reglas claras y efectivas. Aquí verás cómo abrir lectura pública por ruta específica y restringir la escritura a usuarios autenticados, validando tamaño del archivo y tipo de contenido. El resultado: imágenes visibles para todos y subidas controladas solo por su dueño, con archivos válidos y ligeros.
¿Qué problema resuelven las reglas de Firebase Storage?
Las reglas por defecto de Firebase permiten escribir solo si estás autenticado, pero no contemplan rutas específicas ni validaciones finas. Para un blog con imágenes en storage, se ajustan estas reglas para que:
Cualquier usuario pueda leer imágenes públicas sin autenticarse.
Solo el propietario pueda subir archivos a su directorio.
Se valide el tamaño: menor a 5 MB.
Se verifique el tipo de archivo: solo imágenes.
¿Qué conceptos clave se aplican?
Autenticación, autorización y validación de datos: seguridad integral en storage.
Patrón de rutas con match: define reglas por directorios y subdirectorios.
Variables de ruta como {userID} y {IMG ID}: capturan valores dinámicos.
Identidad del usuario con request.auth.uid: asegura escritura solo en su carpeta.
Tipos MIME con content type y matches: restringen a image/.*.
¿Qué estructura de carpetas se usa?
Directorio raíz de imágenes: “IMGs post/”.
Subcarpeta por usuario: “IMGs post/{userID}/”.
Archivo dentro: “IMGs post/{userID}/{IMG ID}”.
¿Cómo configurar lectura pública y escritura segura?
Se parte del tab de reglas en la consola. Se ajusta el match global a rutas concretas y se añaden condiciones para validar archivo, usuario y tipo de contenido.
¿Cómo abrir lectura pública por ruta específica?
Aplicar un match a “IMGs post/**” para permitir read sin autenticación.
Mantener write con restricciones en una regla más específica.
rules_version = '2';
service firebase.storage {
match /b/{bucket}/o {
// Lectura pública de todas las imágenes bajo "IMGs post/"
match /IMGs post/{allPaths=**} {
allow read: if true;
}
// Escritura segura por usuario y archivo específico
match /IMGs post/{userID}/{imgID} {
allow read: if true;
allow write: if request.auth != null
&& request.auth.uid == userID
&& request.resource.size < 5 * 1024 * 1024
&& resource.contentType.matches('image/.*');
}
}
}
¿Cómo limitar el tamaño a 5 MB?
Usar una condición que compare el tamaño del archivo subido con 5 × 1024 × 1024.
Beneficio: evita archivos pesados que afecten rendimiento y costos.
Puntos clave:
Solo se aceptan archivos < 5 MB.
La validación ocurre en el servidor de Firebase.
¿Cómo validar tipo de archivo e identidad del usuario?
Tipo de contenido: usar resource.contentType.matches('image/.*').
Identidad: exigir request.auth != null y request.auth.uid == userID.
Esto garantiza que:
Solo imágenes válidas se suban.
Cada usuario escribe en “su” directorio y no en el de otros.
¿Qué errores comunes y reto final se proponen?
Al probar la subida, puede fallar si no hay sesión iniciada: “no puede leer la propiedad UID en el post controller”. La causa es clara: no hay autenticación, por lo que no existe UID en el cliente.
¿Cómo resolver el error de autenticación?
Iniciar sesión, por ejemplo con Google.
Opcional: validar antes de abrir la ventana de post para evitar intentos de subida sin sesión.
Efecto al autenticarse:
La subida cumple reglas: usuario autenticado, carpeta propia, imagen válida y menos de 5 MB.
El post se crea con imagen y link del video visibles.
¿Qué reto práctico queda pendiente?
Habilitar en el formulario de comentarios la subida de un archivo máximo de 1 MB.
Permitir la subida solo si el usuario está autenticado.
Sugerencias de implementación:
Reutilizar el patrón de match con carpeta específica para comentarios.
Replicar validación de tamaño y autenticación.
¿Tienes dudas o quieres compartir cómo estructuraste tus reglas? Deja tu comentario y cuéntanos qué validaciones añadiste. Próximamente: hosting de Firebase.
Sigo pensando que las reglas de seguridad de Google son lo mismo que escribir código backend jaja es como aprender un lenguaje de programación totalmente nuevo
Pero algo que no me gusta es que no puedes debuggear, por ejemplo, no me dejaba subir la imagen por falta de permisos, y quería ver cuál era la condición que estaba fallando, y no podía debuggear, al final la condición era el límite de peso ya que había escrito mal el .size
¿Porque en storage aunque las reglas estén definidas solo para usuarios autenticados, las imagenes de los post se siguen visualizando aunque este sin logearme?
En el video anterior no logre subir nada al storage de firebase, en este pude luego de agregar las reglas mencionadas en el video y hacer este cambio en el código en postController.js
$('#btnUploadFile').on('change', e => {
const user = firebase.auth().currentUser
if(user == null){
Materialize.toast(`Para crear el post debes estar autenticado`, 4000)
return
}else{
const file = e.target.files[0]
const post = new Post()
post.subirImagenPost(file,user.uid)
}
})
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
Esta debe ser las reglas para el storage, en lo que muestra el profesor esta con imgPosts, pero en el codigo que se realizo nosotros creamos como imgsPosts
rules_version = '2';
service firebase.storage {
match /b/{bucket}/o {
match /imgsPosts/{allPaths=**} {
allow read: if true;
}
match /imgsPosts/{userId}/{imgId}{
allow write:if request.resource.size < 5 * 1024 * 1024
&& request.resource.contentType.matches('image/.*')
&& request.auth.uid != null
&& request.auth.uid == userId
}
}
}
Sigo pensando que las reglas de seguridad de Google son lo mismo que escribir código backend jaja es como aprender un lenguaje de programación totalmente nuevo
Pero algo que no me gusta es que no puedes debuggear, por ejemplo, no me dejaba subir la imagen por falta de permisos, y quería ver cuál era la condición que estaba fallando, y no podía debuggear, al final la condición era el límite de peso ya que había escrito mal el .size
Buen dia companeros, segui el ejemplo de las reglas de firebase storage pero no me deja subir nada, aun estando auntenticado:
Estas son las reglas:
Hola, no veo las reglas
¿Porque en storage aunque las reglas estén definidas solo para usuarios autenticados, las imagenes de los post se siguen visualizando aunque este sin logearme?
Hola puedes comprtir las reglas que tienes definidas para ver si es un problema con la definición de alguna de ellas.
¡Hola! El compañero Eden publicó la imagen de las reglas de cómo deben estar escritas, ¿podrías comprar con sus reglas a ver si tienes algún typo a ver si son lo mismo o hay algún error?
Reto completado:
pd: no puedo creer que hayan pasado casi 5 años desde que se publico el curso y sea el primero en publicar la solucion del reto:
jajajajaa
request.auth.uid != null && request.auth.uid == userId
Esta ultima linea no es necesaria?
[usando version actual de firebase de junio 2023]
En el video anterior no logre subir nada al storage de firebase, en este pude luego de agregar las reglas mencionadas en el video y hacer este cambio en el código en postController.js
$('#btnUploadFile').on('change',e=>{const user = firebase.auth().currentUserif(user ==null){Materialize.toast(`Para crear el post debes estar autenticado`,4000)return}else{const file = e.target.files[0]const post =newPost() post.subirImagenPost(file,user.uid)}})
¿Para poder subir la imagen verdad?
rules_version ='2';service firebase.storage{ match /b/{bucket}/o { match /imgsPosts/{allPaths=**}{ allow read:iftrue;} match /imgsPosts/{userId}/{imgId}{ allow write:if request.resource.size<5*1024*1024&& request.resource.contentType.matches('image/.*')&& request.auth.uid!=null&& request.auth.uid== userId
}}}
¿Como puedo quitar el error de? :
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
Hola,
Eso es un error del CORS o Cross-origin resource sharing. Hay documentacion en el que puedes profundizar mas en el tema. Algunas soluciones:
En desarrollo puede utilizar una extension de Google Chrome llamado Moesif Orign & CORS Changer y asi pruebas que los datos se estan enviando y recibiendo.
Desde Node puedes descargar el paquete de NPM de cors y configurarlo segun la documentacion. Para otros lenguajes hay distintas rutas
En la documentación de firebase existe como configurar CORS. A mi me paso un error similar al intentar descargar por URL un archivo en Storage. Hay varias formas de solucionarlo, pero lo que yo hice es configurar mi proyecto en el Google Cloud SDK. Simplemente segui los pasos que indican desde el siguiente link:
Eso ya lo trae por defecto, trate de subir varias veces la misma imagen y no lo permite, pero si lo relaciona con los posts relacionados
Esta debe ser las reglas para el storage, en lo que muestra el profesor esta con imgPosts, pero en el codigo que se realizo nosotros creamos como imgsPosts
rules_version ='2';service firebase.storage{ match /b/{bucket}/o { match /imgsPosts/{allPaths=**}{ allow read:iftrue;} match /imgsPosts/{userId}/{imgId}{ allow write:if request.resource.size<5*1024*1024&& request.resource.contentType.matches('image/.*')&& request.auth.uid!=null&& request.auth.uid== userId
}}}
Alguien seria amable de explicarme como determino 5 * 1024 * 1024 :/?
1 kilobyte = 1024 bytes
1 megabyte = 1024 kilobytes
eso quiere de decir que un megabyte es igual a 1024 x 1024 bytes (seguramente firebase mide todo en bytes) entonces identifica la fotos no como 5 megas sino como 1048576 bytes
espero hacerme entender
acabo de mirar en el uso de storage en la consola y si, firebase cuenta es los bytes, por eso hay que multiplicar x 1024 2 veces para llegar a megas