Sync Rules and Permissions

Partition-Based Sync Rule Behavior

Sync rules apply to specific partitions and are coupled to your app's data model by the partition key. Consider the following behavior when designing your schemas to ensure that you have appropriate data access granularity and don't accidentally leak sensitive information.

• Sync rules apply dynamically based on the user. One user may have full read & write access to a partition while another user has only read permissions or is unable to access the partition entirely. You control these permissions by defining JSON expressions.
• Sync rules apply equally to all objects in a partition. If a user has read or write permission for a given partition then they can read or modify all synced fields of any object in the partition.
• Write permissions require read permissions, so a user with write access to a partition also has read access regardless of the defined read permission rules.

Partition-Based Sync Permissions

App Services enforces dynamic, user-specific read and write permissions to secure the data in each partition. You define permissions with JSON rule expressions that control whether or not a given user has read or write access to the data in a given partition. App Services evaluates a user's permissions every time they open a synced realm.

Key Concepts

Permission Strategies

You can structure your read and write permission expressions as a set of permission strategies that apply to your partition strategy. The following strategies outline common approaches that you might take to define sync read and write permissions for your app.

true

false

{ "%%true": true }

{ "%%partition": "PUBLIC" }

{
  "%%partition": {
    "$in": [
      "PUBLIC (NA)",
      "PUBLIC (EMEA)",
      "PUBLIC (APAC)"
    ]
  }
}

{ "%%user.id": "5f4863e4d49bd2191ff1e623" }

{
  "%%user.id": {
    "$in": [
      "5f4863e4d49bd2191ff1e623",
      "5f48640dd49bd2191ff1e624",
      "5f486417d49bd2191ff1e625"
    ]
  }
}

{ "%%user.custom_data.readPartitions" : "%%partition" }

{ "%%user.data.writePartitions" : "%%partition" }

{
  "%%true": {
    "%function": {
      "name": "canReadPartition",
      "arguments": ["%%partition"]
    }
  }
}

// canReadPartition
exports = async (partition) => {
  const cluster = context.services.get("mongodb-atlas");
  const permissions = cluster
    .db("myApp")
    .collection("permissions");
  const { canRead } = await permissions.findOne({ partition });
  return canRead.includes(context.user.id);
}

Available Expansions in Flexible Sync Rules Quick Reference

Default Roles

You can create one or more default session roles that apply across all collections. If a collection does not have any custom session roles defined, session role resolution reverts to default session roles.

Flexible Sync Rules

You define a read and write rule expression pair for every session role.

Rule expressions can refer to the queryable fields of your data model.

In response to a Flexible Sync subscription query, App Services evaluates the read and write rule expressions for each document that matches the query. The client only receives documents where the rule expression evaluates to "true".

Consider the following behavior when designing your schemas to ensure that you have appropriate data access granularity and don't accidentally leak sensitive information.

• Sync rules apply dynamically based on the value of the queryable field or user metadata. One user may have full read & write access to a document while another user has only read permissions or is unable to access the document. You control these permissions by defining JSON expressions.
• There are no field-level permissions. Sync rules apply to all documents in a query on a per-collection basis. If a user has read or write permission for a given collection, then they can read or modify all synced fields of any document that matches the sync query in the collection.
• Write permissions require read permissions, so a user with write access to a collection also has read access regardless of the defined (or undefined) read permission rule.