Webcom documentation

Use Predefined Variables

When writing a security rule, you can use a number of helpful, predefined JavaScript variables:

Variable	Description
`now`	The current time in milliseconds since Unix Epoch. This works particularly well for validating timestamps created with server timestamps.
`root`	A RuleDataSnapshot representing the root path of the Webcom application database, as it exists before the attempted operation.
`newData`	A RuleDataSnapshot representing the data as it would exist after the attempted write operation at the specified path. It merges both the new data being written and the already existing data.
`data`	A RuleDataSnapshot representing the data as it existed before the attempted (write or read) operation at the specified path.
`$``level`	A wildcard path level used to represent dynamic child keys (see below).
`auth`	The authentication payload of the currently authenticated user or `null` if no user is authenticated (see the “Using rules to control authentication”).

These variables can be used anywhere in your security rules. For example, the following security rules ensure that data written to the /foo/ node must be a string less than 100 characters:

{
  "rules": {
    "foo": {
      // /foo is readable by anyone
      ".read": true,
      // /foo is writable by anyone
      ".write": true,
      // data written to /foo must be a string less than 100 characters
      ".validate": "newData.isString() && newData.val().length < 100"
    }
  }
}

Make Your Rules Dynamic

The security rules must be defined in a hierarchy of levels that follows the structure of the data nodes stored in the Webcom database. For example, say you are keeping track of a list of messages. Your data could look like:

{
  "messages": {
    "m-001": {
      "content": "Hello",
      "timestamp": 1405704370369
    },
    "m-002": {
      "content": "Goodbye",
      "timestamp": 1405704395231
    },
    ...
  }
}

Your rules should be structured in a similar manner. You can use $ prefixed levels to refer to some levels that you can't know the exact name in advance (like for example the message identifiers). You are then provided with a JavaScript variable with the same ($-prefixed) name to get this name within the security rule.

To illustrate, take a look at the following validation rule (pay attention to the $id level and its corresponding JavaScript variable):

{
  "rules": {
    "messages": {
      "$id": {
        // only messages from the last ten minutes can be read by anyone
        ".read": "data.child('timestamp').val() > (now - 600000)",
        // new messages must have their path starting with "m", 2 children and their content attribute of type string
        ".validate": "$id[0]==='m' && newData.hasChildren(['content','timestamp']) && newData.child('content').isString()"
      }
    }
  }
}

Tutorial: Writing rules

Serverless Database Security Rules Writing rules

Use Predefined Variables

Make Your Rules Dynamic