La respuesta simple es medir el tamaño del archivo que el usuario desea cargar y luego realizar un seguimiento del tamaño total del archivo usando una variable en la base de datos de Firebase.
/ usuarios / [usuario 1] / uso actual: 500
Debería hacer un observador una vez en este valor para recuperarlo, luego agregar el tamaño del nuevo archivo a ese valor y luego establecer el valor nuevamente.
- ¿Por qué es esencial una auditoría de seguridad para una aplicación móvil financiera?
- ¿Qué plataforma de desarrollo de aplicaciones móviles proporciona un desarrollo paralelo de aplicaciones móviles para dos plataformas?
- ¿Quiénes son los mejores desarrolladores de aplicaciones?
- Cómo contratar desarrolladores de aplicaciones móviles dedicados en India
- ¿Cuáles son los idiomas utilizados para desarrollar aplicaciones móviles? ¿Puedo usar HTML5, CSS, PHP y JavaScript para crear aplicaciones móviles o necesito saber Java y C ++? ¿Qué es la programación de Android? ¿Como es diferente?
El problema aquí es que no es muy seguro. El cliente podría escribir una función JavaScript simple para establecer este valor en lo que quiera.
Hay dos formas de solucionar este problema.
Forma relativamente segura
Cada vez que se inicia la aplicación, puede recuperar el valor de current-usage de Firebase y almacenarlo en el llavero. Por supuesto, haría una comprobación para asegurarse de que el valor que provenía de Firebase era >= al valor que había guardado.
Luego, cuando quisiera establecer el valor de current-usage , usaría el valor local más el tamaño del nuevo archivo. Dado que el llavero no se borra cuando se elimina la aplicación y es un área de almacenamiento de datos muy segura, sería muy difícil para el usuario hacer trampa.
Imagine que falsificaron el valor de Firebase. La próxima vez que intenten cargar un archivo, la aplicación solo usará el valor local más el nuevo tamaño del archivo. Entonces Firebase aún sería correcto.
La forma completamente segura
La forma completamente segura sería utilizar un servicio alternativo para el almacenamiento de archivos. Algo como AWS. Su aplicación llamaría a una API en su servidor que cargaría el archivo y luego escribiría el valor en Firebase. Esto también puede ser más barato que usar el almacenamiento de Firebase.
Conclusión
De las dos opciones, elegiría la primera. Creo que es muy poco probable que alguien intente aplicar ingeniería inversa a su aplicación para obtener más almacenamiento. Si su aplicación realmente despega y esto se convierte en un problema, podría invertir un poco más de esfuerzo para implementar una solución más sólida.
