With Webcom, application developers must specify Security Rules, which accurately control access rights to the data.
Security rules are defined using Javascript-like boolean expressions. They describe the conditions under which your data can be read or written and how your data should be structured. Combined with the serverless authentication service which offers easy authentication of users, you can define who can access which data and so, keep secure all of your users' personal information. The security rules are hosted on Webcom servers and are automatically enforced all the time.
Understand the default security rules
Security rules both determine who has "read" and "write" access to your Webcom application data, and ensure the
structure of that data.
They are defined in the "security" tab of the Webcom developer console.
They come in three flavors: .write
, .read
, and .validate
:
Rule Type | Purpose |
---|---|
.read |
Describes whether some data is allowed to be read. |
.write |
Describes whether some data is allowed to be written. |
.validate |
Constraints the format of the written data (e.g. its data type, the list of allowed child attributes...) |
Security rules are written in JavaScript, which makes them easy to work with. By default, your application has rules which enforce no constraint on the data structure and grant every request either:
- full "read" and "write" permissions to the data (“discovery mode”):
{
"rules": {
".read": true,
".write": true
}
}
- or authenticated "read" and "write" permissions to data (“restricted mode”), which require that a user must be authenticated to perform any read or write operation:
{
"rules": {
".read": "auth!==null",
".write": "auth!==null"
}
}
Evaluation of rules
-
Rules are first evaluated at first level, and then deeper and deeper while needed, that is,
- while evaluated to
false
for.read
and.write
rules, - while evaluated to
true
for.validate
rules.
- while evaluated to
-
For
.read
and.write
rules, the first (shallower) rule that is evaluated totrue
stops the overall evaluation and the operation is allowed (without any evaluation of deeper rules).
At a given level, if not defined, default value for.read
and.write
rules isfalse
. -
For
.validate
rules, all rules must allow the write operation. The first validation rule that is evaluated tofalse
stops the overall evaluation and the operation is rejected (without any evaluation of deeper rules).
At a given level, if not defined, default value for.validate
rule istrue
. -
When reading, for
get
andsubscribe
operations, the evaluation of.read
rules stops at the level corresponding to the operation path depth. It does not consider any deeper (possibly existing) sub-paths. -
When writing:
- for
set
operations, the evaluation of.read
or.write
rules stops at the level corresponding to the operation path depth. It does not consider any deeper (existing or to be written) sub-paths. - for
merge
andpush
operations, the.write
rule evaluation goes one step deeper than the operation path depth (because amerge
is equivalent to nset
on the first-level keys
of the merged data node, andpush
is equivalent toset
on a first-level key of the written data node). It does not consider any deeper (existing or to be written) sub-paths.
- for
-
When writing data, all
.validate
rules at the levels corresponding to all sub-paths inside the written value are executed.
Exception:.validate
rules are skipped when deleting data (more precisely whennewData
isnull
at the evaluation path).
Security rules are hosted on Webcom servers and are enforced all the time: every read and write request will succeed only if the rules registered at the time of the request allow it. With the default rules in “discovery mode”, all requests will be permitted.
Limitations
The maximum length of the JavaScript expression defining a security rule is 2048 characters.
In addition, to avoid performance issue:
- Some JavaScript expressions or statements are forbidden in security rules (regular expressions, loops, function calls, function definitions).
- The amount of data to read in order to evaluate a rule (
.read
,.write
or.validate
) is limited. If this amount exceeds this limit, then the evaluated rule fails and the corresponding permission is refused.