Este dilema se puede solucionar de variadas maneras, pero nosotros te enseñamos la que para nosotros es la resolución más completa.
Solución:
Las reglas de seguridad que se muestran aquí son una desviación de las reglas predeterminadas anteriores que eran mucho más permisivas. La idea con esta regla:
match /document=**
allow read, write: if request.time < timestamp.date(2019, 12, 14);
Es que obtienes acceso sin restricciones a tu base de datos de Firestore hasta la fecha indicada, para poder experimentar libremente con ella durante un mes. Sin embargo, permitir el acceso sin restricciones es obviamente un gran agujero de seguridad a largo plazo.
El curso de acción recomendado es primero elimine esta regla por completo, ya que permite que cualquier persona lea y escriba cualquier cosa en su base de datos. Luego, diseñe algunas reglas adecuadas que permitan solo el acceso a las colecciones y documentos a los que sus eventuales usuarios deberían poder acceder. Una discusión completa de eso está fuera de tema para Stack Overflow (ya que no conocemos los requisitos de su aplicación), pero aquí hay algunos buenos lugares para comenzar a aprender sobre las reglas de seguridad:
- La documentación
- esta serie de videos
Lo que debería estar haciendo es llamar las restricciones de acceso para cada colección y subcolección en su base de datos. Idealmente, debe bloquear el acceso de escritura no autenticado a todas las colecciones, excepto cuando sea absolutamente necesario. En el mejor de los casos, está utilizando Firebase Authentication para ayudar a controlar el acceso a los documentos solo según lo requieran los usuarios autenticados.
Alternativamente, si ha terminado de trabajar con la base de datos (por el momento), puede bloquear completamente el acceso a la base de datos desde la web y el cliente móvil usando la siguiente regla exclusivamente:
rules_version = '2';
service cloud.firestore
match /databases/database/documents
allow read, write: if false;
Con esta regla, aún se permitirá el acceso desde el código de backend mediante el SDK de administración de Firebase u otros SDK de Cloud.
O si eres como yo, ¿quién sigue en modo de prueba? solo actualiza la fecha
match /document=**
// from previous date 2019, 12, 14 to new date 2020, 01, 4
allow read, write: if request.time < timestamp.date(2020, 01, 4);
Cada vez que inicia un nuevo proyecto en firebase (o) configura una base de datos de firestore, firebase agrega de forma predeterminada un conjunto de reglas para su base de datos, que se parece a esto.
rules_version = '2';
service cloud.firestore
match /databases/database/documents
// This rule allows anyone on the internet to view, edit, and delete
// all data in your Firestore database. It is useful for getting
// started, but it is configured to expire after 30 days because it
// leaves your app open to attackers. At that time, all client
// requests to your Firestore database will be denied.
//
// Make sure to write security rules for your app before that time, or else
// your app will lose access to your Firestore database
match /document=**
allow read, write: if request.time < timestamp.date(XXXX, XX, XX);
El "timestamp.date" data de 1 mes desde que inicia el proyecto. Más o menos como una prueba gratuita de 30 días. Al omitir esta fecha, la base de datos niega todas las solicitudes de los clientes. Entonces, el correo electrónico es básicamente un recordatorio para que cambies las reglas de seguridad. Una forma simple es permitir solicitudes de lectura/escritura solo a usuarios autenticados.
// Allow read/write access on all documents to any user signed in to the application
service cloud.firestore
match /databases/database/documents
match /document=**
allow read, write: if request.auth != null;
Tenga en cuenta que esta es una de las formas de definir las reglas y no necesita exactamente como se muestra, puede realizar modificaciones adicionales según sus requisitos. Para más información, puedes echar un vistazo a esta documentación