Evi1 Gdsof Mags

Gestión del Proceso de Desarrollo de Software
EVIDENCIA 1
Nombre: Marcelo Andrés Gascón Santos

Matricula: 10933
Fecha: 21/Octubre/2022
INSTRUCCIONES:
1. Definirás un proyecto de desarrollo móvil y realizará lo siguiente:
a. Sección de reglas de seguridad de cloud firestore.
b. Reglas por defecto al crear la base de datos.
c. Regla para aceptar todas las consultas.
d. Zona de pruebas de reglas.
e. Reglas para rechazar todas las consultas.
f. Regla para aceptar consultas de users autenticados.
g. Reglas de users autenticados con email y password de facebook.
h. Publicación de nuevas reglas de seguridad.
2. Realizarás un reporte y explicarás los tres tipos de prueba (unitaria, widgets
y de integración) aplicados estos a tu proyecto.
Sección de reglas de seguridad sencillas, pero ¿dónde se escriben estás normas?

Para ello nos vamos a nuestra consola de Firebase.
Y una vez hemos entrado en nuestra base de datos, vamos a la sección de reglas.
Aquí vemos las reglas por defecto.
Reglas de seguridad versión 2
La primera línea que vemos, al añadir rules_version especificamos qué versión de
las reglas de seguridad queremos, en nuestro caso vamos a dejarlo como está y
nos quedaremos con la versión 2.
Escribimos las reglas
Antes de leer, escribir o eliminar en nuestra base de datos Cloud Firestore se
comprueban las reglas de seguridad. Si se cumplen, tenemos acceso a nuestra
base de datos, y si estas no se cumplen no podemos acceder y por lo tanto
tendríamos un error.
Si quisiéramos aceptar todas las peticiones a nuestra base de datos, podríamos
hacer lo siguiente:
 rules_version, especifica la versión de las reglas de seguridad
 service, especifica el servicio que vamos a utilizar, en nuestro caso es la
base de datos Cloud Firestore (solo se aplicarán estas reglas de seguridad
aquí)
 match /databases/{database}/documents y match /{document=**}, aquí lo
que hacemos es indicar que se apliquen las reglas en toda la jerarquía de
nuestra base de datos. En cualquier documento de nuestra colección.
 allow, aquí indicamos que para lectura y escritura queremos retornar
siempre true, indicando que cualquier user puede leer, escribir y eliminar en
nuestra base de datos.
El problema de hacer esto es que le das permiso a cualquier user a alterar el
contenido de tu base de datos, incluso de borrarla por completo.
Cómo probar las reglas de seguridad de nuestra base de datos Cloud
Firestore
Si te fijas, en la misma vista en la que estamos trabajando, tenemos una Zona de
prueba de reglas en esta sección podemos probar la regla que acabamos de
añadir.
Para probar nuestra nueva regla de seguridad lo que vamos hacer es poner la
colección links y a continuación pondremos un document ID que exista en nuestra
base de datos. Y pulsamos en el Button Ejecutar. Si todo va bien debería
aparecer lo mismo que vemos en la siguiente imagen:
Esto lo hemos hecho como prueba, pero no nos interesa que todos los users
tengan estos privilegios. Si queremos el caso opuesto, haríamos lo siguiente:
Aquí estamos bloqueando todas las solicitudes de nuestros users, y por lo tanto no
permitimos realizar ninguna operación en nuestra base de datos.
Ahora vamos a añadir la única regla que queríamos en nuestra base de datos
Cloud Firestore, y es la de solo permitir hacer consultas de lectura y escritura a
users que préviamente se hayan logueado.
Ahora vamos a probar esta opción en el simulador, aquí tenemos una opción que
si la habilitamos podemos especificar el proveedor, en nuestro caso vamos a
escoger password. No haría falta poner el correo electrónico.
Mejoramos nuestras reglas de seguridad
Ahora vamos hacer un pequeño cambio, y vamos a añadir que solo los users que
se han autenticado con Email y Password o Facebook puedan realizar
operaciones de lectura, escritura y eliminación de nuestra base de datos.
Para ello vamos a espeficicar en nuestra condición de la la regla de seguridad que
el provider sea con password y facebook.com.
Publicar reglas de seguridad nuevas

Una vez hemos modificado als reglas de seguridad que queremos, debemos
publicarlas para que empiecen a funcionar. Para hacerlo le damos al Button
de Publicar.
Pruebas funcionales
 Se asegura de que el sitio web / aplicación está libre de defectos.
 Garantiza el comportamiento esperado de todas las funcionalidades.
 Garantiza que la arquitectura sea correcta con la seguridad necesaria.
 Mejora la calidad y las funcionalidades generales.
 Minimiza los riesgos empresariales asociados con el sitio web/aplicación.
Pruebas de integración
 Se asegura de que todos los módulos de aplicación estén bien integrados y
funcionen juntos según lo esperado.
 Detecta problemas y conflictos interconectados para resolverlos antes de crear un
gran problema.
 Valida la funcionalidad, fiabilidad y estabilidad entre diferentes módulos.
 Detecta excepciones ignoradas para mejorar la calidad del código.
 Admite la canalización de CI/CD.
Pruebas unitarias
 Detección temprana de errores en las nuevas funcionalidades o características
desarrolladas.
 Minimiza los costos de las pruebas a medida que se detectan problemas desde el
principio.
 Mejora la calidad del código con una mejor refactorización del código.
 Apoya el proceso de desarrollo ágil.
 Simplifica la integración y permite una buena documentación.

Evi1 Gdsof Mags

Cargado por

Copyright:

Formatos disponibles

Evi1 Gdsof Mags

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Evi1 Gdsof Mags

Cargado por

Copyright:

Formatos disponibles

Gestión del Proceso de Desarrollo de Software

Nombre: Marcelo Andrés Gascón Santos

Sección de reglas de seguridad sencillas, pero ¿dónde se escriben estás normas?

Publicar reglas de seguridad nuevas

También podría gustarte