Condiciones de uso en reglas de seguridad de bases de datos en tiempo real

Esta guía se basa en la guía de lenguaje de aprendizaje de las reglas de seguridad principales de Firebase para mostrar cómo agregar condiciones a sus reglas de seguridad de bases de datos en tiempo real de Firebase.

El componente principal de las reglas de seguridad de bases de datos en tiempo real es la condición . Una condición es una expresión booleana que determina si se debe permitir o denegar una operación particular. Para reglas básicas, usar literales true y false como condiciones funciona perfectamente bien. Pero el lenguaje de reglas de seguridad de bases de datos en tiempo real le ofrece formas de escribir condiciones más complejas que pueden:

• Verificar autenticación de usuario
• Evaluar los datos existentes comparándolos con los datos enviados recientemente
• Acceda y compare diferentes partes de su base de datos
• Validar datos entrantes
• Utilice la estructura de consultas entrantes para la lógica de seguridad.

Uso de variables $ para capturar segmentos de ruta

Puede capturar partes de la ruta para lectura o escritura declarando variables de captura con el prefijo $ . Esto sirve como comodín y almacena el valor de esa clave para usarla dentro de las condiciones de las reglas:

{
  "rules": {
    "rooms": {
      // this rule applies to any child of /rooms/, the key for each room id
      // is stored inside $room_id variable for reference
      "$room_id": {
        "topic": {
          // the room's topic can be changed if the room id has "public" in it
          ".write": "$room_id.contains('public')"
        }
      }
    }
  }
}

Las variables dinámicas $ también se pueden utilizar en paralelo con nombres de rutas constantes. En este ejemplo, usamos la variable $other para declarar una regla .validate que garantiza que widget no tenga hijos distintos del title y color . Cualquier escritura que diera lugar a la creación de hijos adicionales fallaría.

{
  "rules": {
    "widget": {
      // a widget can have a title or color attribute
      "title": { ".validate": true },
      "color": { ".validate": true },

      // but no other child paths are allowed
      // in this case, $other means any key excluding "title" and "color"
      "$other": { ".validate": false }
    }
  }
}

Nota: Las claves de ruta son siempre cadenas. Por esta razón, es importante tener en cuenta que cuando intentamos comparar una variable $ con un número, esto siempre fallará. Esto se puede corregir convirtiendo el número en una cadena (por ejemplo $key === newData.val()+'' ).

Autenticación

Uno de los patrones de reglas de seguridad más comunes es controlar el acceso según el estado de autenticación del usuario. Por ejemplo, es posible que su aplicación desee permitir que solo los usuarios que hayan iniciado sesión escriban datos.

Si su aplicación usa Firebase Authentication, la variable request.auth contiene la información de autenticación para el cliente que solicita datos. Para obtener más información sobre request.auth , consulte la documentación de referencia .

Firebase Authentication se integra con Firebase Realtime Database para permitirle controlar el acceso a los datos por usuario mediante condiciones. Una vez que un usuario se autentica, la variable auth en sus reglas de reglas de seguridad de bases de datos en tiempo real se completará con la información del usuario. Esta información incluye su identificador único ( uid ), así como datos de la cuenta vinculada, como una identificación de Facebook o una dirección de correo electrónico, y otra información. Si implementa un proveedor de autenticación personalizado, puede agregar sus propios campos a la carga útil de autenticación de su usuario.

Esta sección explica cómo combinar el lenguaje de las reglas de seguridad de la base de datos en tiempo real de Firebase con información de autenticación sobre sus usuarios. Al combinar estos dos conceptos, puede controlar el acceso a los datos en función de la identidad del usuario.

La variable auth

La variable auth predefinida en las reglas es nula antes de que se realice la autenticación.

Una vez que un usuario se autentica con Firebase Authentication , contendrá los siguientes atributos:

proveedor	El método de autenticación utilizado ("contraseña", "anónimo", "facebook", "github", "google" o "twitter").
fluido	Una identificación de usuario única, garantizada para ser única en todos los proveedores.
simbólico	El contenido del token de ID de autenticación de Firebase. Consulte la documentación de referencia de auth.token para obtener más detalles.

A continuación se muestra una regla de ejemplo que utiliza la variable auth para garantizar que cada usuario solo pueda escribir en una ruta específica del usuario:

{
  "rules": {
    "users": {
      "$user_id": {
        // grants write access to the owner of this user account
        // whose uid must exactly match the key ($user_id)
        ".write": "$user_id === auth.uid"
      }
    }
  }
}

Estructurar su base de datos para soportar las condiciones de autenticación

Generalmente es útil estructurar su base de datos de una manera que facilite la escritura de reglas. Un patrón común para almacenar datos de usuario en Realtime Database es almacenar a todos sus usuarios en un único nodo users cuyos hijos son los valores uid de cada usuario. Si quisiera restringir el acceso a estos datos de modo que solo el usuario que inició sesión pueda ver sus propios datos, sus reglas se verían así.

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth !== null && auth.uid === $uid"
      }
    }
  }
}

Trabajar con reclamaciones personalizadas de autenticación

Para aplicaciones que requieren control de acceso personalizado para diferentes usuarios, Firebase Authentication permite a los desarrolladores establecer reclamos sobre un usuario de Firebase . Se puede acceder a estas reclamaciones en la variable auth.token de sus reglas. A continuación se muestra un ejemplo de reglas que utilizan el reclamo personalizado hasEmergencyTowel :

{
  "rules": {
    "frood": {
      // A towel is about the most massively useful thing an interstellar
      // hitchhiker can have
      ".read": "auth.token.hasEmergencyTowel === true"
    }
  }
}

Los desarrolladores que crean sus propios tokens de autenticación personalizados pueden, opcionalmente, agregar reclamos a estos tokens. Estos reclamos están disponibles en la variable auth.token en sus reglas.

Datos existentes frente a datos nuevos

La variable data predefinida se utiliza para hacer referencia a los datos antes de que se realice una operación de escritura. Por el contrario, la variable newData contiene los nuevos datos que existirán si la operación de escritura se realiza correctamente. newData representa el resultado combinado de los nuevos datos que se escriben y los datos existentes.

Para ilustrar, esta regla nos permitiría crear nuevos registros o eliminar los existentes, pero no realizar cambios en los datos existentes que no sean nulos:

// we can write as long as old data or new data does not exist
// in other words, if this is a delete or a create, but not an update
".write": "!data.exists() || !newData.exists()"

Asegúrese de verificar si hay datos nulos o no válidos. Los errores en las reglas provocan operaciones rechazadas.

Hacer referencia a datos en otras rutas

Cualquier dato puede utilizarse como criterio para las reglas. Usando las variables predefinidas root , data y newData , podemos acceder a cualquier ruta tal como existiría antes o después de un evento de escritura.

Considere este ejemplo, que permite operaciones de escritura siempre que el valor del nodo /allow_writes/ sea true , el nodo principal no tenga un indicador readOnly establecido y haya un hijo llamado foo en los datos recién escritos:

".write": "root.child('allow_writes').val() === true &&
          !data.parent().child('readOnly').exists() &&
          newData.child('foo').exists()"

Validación de datos

La aplicación de estructuras de datos y la validación del formato y contenido de los datos se deben realizar mediante reglas .validate , que se ejecutan solo después de que una regla .write logra otorgar acceso. A continuación se muestra un ejemplo de definición de regla .validate que solo permite fechas en el formato AAAA-MM-DD entre los años 1900-2099, que se verifica mediante una expresión regular.

".validate": "newData.isString() &&
              newData.val().matches(/^(19|20)[0-9][0-9][-\\/. ](0[1-9]|1[012])[-\\/. ](0[1-9]|[12][0-9]|3[01])$/)"

Pruébelo en JSFiddle : haga clic aquí para verlo en acción . Intente escribir valores diferentes en el campo de entrada.

Las reglas .validate son el único tipo de regla de seguridad que no se aplica en cascada. Si alguna regla de validación falla en algún registro secundario, se rechazará toda la operación de escritura. Además, las definiciones de validación se ignoran cuando se eliminan datos (es decir, cuando el nuevo valor que se escribe es null ).

Nota: Las reglas .validate solo se evalúan para valores no nulos y no se conectan en cascada.

Estos pueden parecer puntos triviales, pero en realidad son características importantes para escribir poderosas reglas de seguridad de bases de datos en tiempo real de Firebase. Considere las siguientes reglas:

{
  "rules": {
    // write is allowed for all paths
    ".write": true,
    "widget": {
      // a valid widget must have attributes "color" and "size"
      // allows deleting widgets (since .validate is not applied to delete rules)
      ".validate": "newData.hasChildren(['color', 'size'])",
      "size": {
        // the value of "size" must be a number between 0 and 99
        ".validate": "newData.isNumber() &&
                      newData.val() >= 0 &&
                      newData.val() <= 99"
      },
      "color": {
        // the value of "color" must exist as a key in our mythical
        // /valid_colors/ index
        ".validate": "root.child('valid_colors/' + newData.val()).exists()"
      }
    }
  }
}

Con esta variante en mente, observe los resultados de las siguientes operaciones de escritura:

javascript

var ref = db.ref("/widget");

// PERMISSION_DENIED: does not have children color and size
ref.set('foo');

// PERMISSION DENIED: does not have child color
ref.set({size: 22});

// PERMISSION_DENIED: size is not a number
ref.set({ size: 'foo', color: 'red' });

// SUCCESS (assuming 'blue' appears in our colors list)
ref.set({ size: 21, color: 'blue'});

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
ref.child('size').set(99);

C objetivo

Nota: Este producto de Firebase no está disponible en el destino del clip de aplicación.

FIRDatabaseReference *ref = [[[FIRDatabase database] reference] child: @"widget"];

// PERMISSION_DENIED: does not have children color and size
[ref setValue: @"foo"];

// PERMISSION DENIED: does not have child color
[ref setValue: @{ @"size": @"foo" }];

// PERMISSION_DENIED: size is not a number
[ref setValue: @{ @"size": @"foo", @"color": @"red" }];

// SUCCESS (assuming 'blue' appears in our colors list)
[ref setValue: @{ @"size": @21, @"color": @"blue" }];

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
[[ref child:@"size"] setValue: @99];

Rápido

Nota: Este producto de Firebase no está disponible en el destino del clip de aplicación.

var ref = FIRDatabase.database().reference().child("widget")

// PERMISSION_DENIED: does not have children color and size
ref.setValue("foo")

// PERMISSION DENIED: does not have child color
ref.setValue(["size": "foo"])

// PERMISSION_DENIED: size is not a number
ref.setValue(["size": "foo", "color": "red"])

// SUCCESS (assuming 'blue' appears in our colors list)
ref.setValue(["size": 21, "color": "blue"])

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
ref.child("size").setValue(99);

Java

FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("widget");

// PERMISSION_DENIED: does not have children color and size
ref.setValue("foo");

// PERMISSION DENIED: does not have child color
ref.child("size").setValue(22);

// PERMISSION_DENIED: size is not a number
Map<String,Object> map = new HashMap<String, Object>();
map.put("size","foo");
map.put("color","red");
ref.setValue(map);

// SUCCESS (assuming 'blue' appears in our colors list)
map = new HashMap<String, Object>();
map.put("size", 21);
map.put("color","blue");
ref.setValue(map);

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
ref.child("size").setValue(99);

DESCANSAR

# PERMISSION_DENIED: does not have children color and size
curl -X PUT -d 'foo' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# PERMISSION DENIED: does not have child color
curl -X PUT -d '{"size": 22}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# PERMISSION_DENIED: size is not a number
curl -X PUT -d '{"size": "foo", "color": "red"}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# SUCCESS (assuming 'blue' appears in our colors list)
curl -X PUT -d '{"size": 21, "color": "blue"}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# If the record already exists and has a color, this will
# succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
# will fail to validate
curl -X PUT -d '99' \
https://docs-examples.firebaseio.com/rest/securing-data/example/size.json

Ahora veamos la misma estructura, pero usando reglas .write en lugar de .validate :

{
  "rules": {
    // this variant will NOT allow deleting records (since .write would be disallowed)
    "widget": {
      // a widget must have 'color' and 'size' in order to be written to this path
      ".write": "newData.hasChildren(['color', 'size'])",
      "size": {
        // the value of "size" must be a number between 0 and 99, ONLY IF WE WRITE DIRECTLY TO SIZE
        ".write": "newData.isNumber() && newData.val() >= 0 && newData.val() <= 99"
      },
      "color": {
        // the value of "color" must exist as a key in our mythical valid_colors/ index
        // BUT ONLY IF WE WRITE DIRECTLY TO COLOR
        ".write": "root.child('valid_colors/'+newData.val()).exists()"
      }
    }
  }
}

En esta variante, cualquiera de las siguientes operaciones tendría éxito:

javascript

var ref = new Firebase(URL + "/widget");

// ALLOWED? Even though size is invalid, widget has children color and size,
// so write is allowed and the .write rule under color is ignored
ref.set({size: 99999, color: 'red'});

// ALLOWED? Works even if widget does not exist, allowing us to create a widget
// which is invalid and does not have a valid color.
// (allowed by the write rule under "color")
ref.child('size').set(99);

C objetivo

Nota: Este producto de Firebase no está disponible en el destino del clip de aplicación.

Firebase *ref = [[Firebase alloc] initWithUrl:URL];

// ALLOWED? Even though size is invalid, widget has children color and size,
// so write is allowed and the .write rule under color is ignored
[ref setValue: @{ @"size": @9999, @"color": @"red" }];

// ALLOWED? Works even if widget does not exist, allowing us to create a widget
// which is invalid and does not have a valid color.
// (allowed by the write rule under "color")
[[ref childByAppendingPath:@"size"] setValue: @99];

Rápido

Nota: Este producto de Firebase no está disponible en el destino del clip de aplicación.

var ref = Firebase(url:URL)

// ALLOWED? Even though size is invalid, widget has children color and size,
// so write is allowed and the .write rule under color is ignored
ref.setValue(["size": 9999, "color": "red"])

// ALLOWED? Works even if widget does not exist, allowing us to create a widget
// which is invalid and does not have a valid color.
// (allowed by the write rule under "color")
ref.childByAppendingPath("size").setValue(99)

Java

Firebase ref = new Firebase(URL + "/widget");

// ALLOWED? Even though size is invalid, widget has children color and size,
// so write is allowed and the .write rule under color is ignored
Map<String,Object> map = new HashMap<String, Object>();
map.put("size", 99999);
map.put("color", "red");
ref.setValue(map);

// ALLOWED? Works even if widget does not exist, allowing us to create a widget
// which is invalid and does not have a valid color.
// (allowed by the write rule under "color")
ref.child("size").setValue(99);

DESCANSAR

# ALLOWED? Even though size is invalid, widget has children color and size,
# so write is allowed and the .write rule under color is ignored
curl -X PUT -d '{size: 99999, color: "red"}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# ALLOWED? Works even if widget does not exist, allowing us to create a widget
# which is invalid and does not have a valid color.
# (allowed by the write rule under "color")
curl -X PUT -d '99' \
https://docs-examples.firebaseio.com/rest/securing-data/example/size.json

Esto ilustra las diferencias entre las reglas .write y .validate . Como se demostró, todas estas reglas deben escribirse usando .validate , con la posible excepción de la regla newData.hasChildren() , que dependerá de si se deben permitir las eliminaciones.

Nota: Las reglas de validación no pretenden reemplazar completamente el código de validación de datos en su aplicación. Le recomendamos que también realice la validación de entradas en el lado del cliente para obtener el mejor rendimiento y la mejor experiencia de usuario cuando su aplicación esté fuera de línea.

Reglas basadas en consultas

Aunque no puede utilizar reglas como filtros , puede limitar el acceso a subconjuntos de datos utilizando parámetros de consulta en sus reglas. Utilice query. expresiones en sus reglas para otorgar acceso de lectura o escritura según los parámetros de consulta.

Por ejemplo, la siguiente regla basada en consultas utiliza reglas de seguridad basadas en usuarios y reglas basadas en consultas para restringir el acceso a los datos en la colección de baskets solo a las cestas de compras que posee el usuario activo:

"baskets": {
  ".read": "auth.uid !== null &&
            query.orderByChild === 'owner' &&
            query.equalTo === auth.uid" // restrict basket access to owner of basket
}

La siguiente consulta, que incluye los parámetros de consulta de la regla, tendría éxito:

db.ref("baskets").orderByChild("owner")
                 .equalTo(auth.currentUser.uid)
                 .on("value", cb)                 // Would succeed

Sin embargo, las consultas que no incluyen los parámetros de la regla generarían un error PermissionDenied :

db.ref("baskets").on("value", cb)                 // Would fail with PermissionDenied

También puede utilizar reglas basadas en consultas para limitar la cantidad de datos que descarga un cliente mediante operaciones de lectura.

Por ejemplo, la siguiente regla limita el acceso de lectura solo a los primeros 1000 resultados de una consulta, ordenados por prioridad:

messages: {
  ".read": "query.orderByKey &&
            query.limitToFirst <= 1000"
}

// Example queries:

db.ref("messages").on("value", cb)                // Would fail with PermissionDenied

db.ref("messages").limitToFirst(1000)
                  .on("value", cb)                // Would succeed (default order by key)

La siguiente query. Las expresiones están disponibles en Reglas de seguridad de bases de datos en tiempo real.

Expresiones de reglas basadas en consultas
Expresión	Tipo	Descripción
consulta.orderByKey consulta.orderByPriority consulta.orderByValue	booleano	Verdadero para consultas ordenadas por clave, prioridad o valor. Falso en caso contrario.
consulta.orderByChild	cadena nulo	Utilice una cadena para representar la ruta relativa a un nodo secundario. Por ejemplo, query.orderByChild === "address/zip" . Si la consulta no está ordenada por un nodo secundario, este valor es nulo.
consulta.startAt consulta.endAt consulta.equalTo	cadena número booleano nulo	Recupera los límites de la consulta en ejecución o devuelve nulo si no hay ningún límite establecido.
consulta.limitToFirst consulta.limitToLast	número nulo	Recupera el límite de la consulta en ejecución o devuelve nulo si no hay ningún límite establecido.

Próximos pasos

Después de esta discusión sobre las condiciones, tendrá una comprensión más sofisticada de las reglas y estará listo para:

Aprenda a manejar casos de uso principales y conozca el flujo de trabajo para desarrollar, probar e implementar reglas:

• Obtenga información sobre el conjunto completo de variables de reglas predefinidas que puede utilizar para crear condiciones .
• Escriba reglas que aborden escenarios comunes .
• Amplíe sus conocimientos revisando situaciones en las que debe detectar y evitar reglas inseguras .
• Obtenga más información sobre Firebase Local Emulator Suite y cómo puede usarlo para probar reglas .
• Revise los métodos disponibles para implementar reglas .

Funciones de reglas de aprendizaje específicas de Realtime Database:

• Aprenda a indexar su base de datos en tiempo real .
• Revise la API REST para implementar reglas .