Tutorial: Security Rules

Webcom provides a rules language based on JavaScript-like boolean expression. You can easily define how your data should be structured and when your data can be read from and written to. Combined with our "serverless authentication" service which allows for easy authentication, you can define who has access to what data and keep all of your user's personal information secure. The security rules live on the Webcom servers and are automatically enforced at all times.

Understand the default security rules

Security rules are used to determine who has read and write access to your Webcom data as well to ensure the structure of that data. They are found in the "security" tab of your Webcom developer console. They come in three flavors: .write, .read, and .validate. Here is a quick summary of their purpose:

Security rules are written in JavaScript which makes them easy to work with. The maximum length of a rule is 2048 characters. By default, your application has rules which grants every request either full read and write permissions (“discovery mode”) or authenticated read and write permissions (“restricted mode”) to your Webcom app:

{
	"rules": {
		".read": true,
		".write": true
	}
}

Evaluation rules

• Rules are evaluated at first level first and then deeper and deeper if needed (if false for .read and .write, if true for .validate).

• For .read and .write rules, the first (shallower) rule that is evaluated to true stops the evaluation and the operation is allowed (without any evalation of deeper rules). Default value for .read and .write rules is false.

• For .validate rules, all rules must allow the write operation. The first validate rule that is evaluated to false stops the evaluation and the opeation is rejected (without any evalation of deeper rules). Default value for .validate rule is true.

• For set (write/put) and get (read) operations, the .read or .write rule evaluation stops at operation path depth, it does not go deeper inside value (existing or to be written) subpaths.

• For update (merge) operations, the .write rule evaluation goes one step deeper. (because an update is equivalent to N set on N first level key of the value.

• When writing new data all validate rules at subpaths inside value are executed. Exception: .validate rules are skipped when deleting data (more precisely when newData is null at evaluation path).

Security rules live on the Webcom servers and are enforced at all times. Every read and write request will only be completed if your rules allow it. With the default rules above, all requests will be permitted. Security Behind the Scenes

Limitations

To avoid performances issue, some elements are forbidden in security rules:

• regular expressions
• loops
• function calls
• function definitions