37 Console and SDK Integration

This chapter explains how developers can define, test, and manage security rules using the Oracle Backend for Firebase Console and SDKs. It covers the end-to-end workflow for rule creation, validation, and deployment, ensuring that developers can confidently enforce access control policies across their applications.

• Defining Security Rules Using Console
  
• Security Rule Example
  

37.1 Defining Security Rules Using Console

The Oracle Backend for Firebase Console provides a visual interface for managing security rules at the project level. Developers can define rules for:

• Database collections and documents

• Object Storage paths

• Join views and collection groups

Console Steps to Define a Rule

1. Navigate to the Security Rules section of your project in the Console.

2. Select the target path (e.g.,

   /users/{userid}/recipes/{recipeid}

   ).

3. Choose the operation(s): get, list, create, update, delete.

4. Write the CEL expression in the rule editor.

5. Validate the rule using the built-in syntax checker.

6. Publish the rule to apply it to your backend.

The Console also provides inline documentation, autocomplete for variables, and error highlighting to assist with rule authoring.

Rule Simulation and Testing

Before deploying a rule, developers can:

• Use the Console’s test mode to simulate requests

• Provide mock request and resource data

• View the evaluation result (true or false)

• Debug failed conditions using detailed logs

37.2 Security Rule Example

The following example covers basic rules, nested match statements, and sub-collection level rules.

Data Model

  users/{userId}

  organizations/{orgId}
    +-- members/{memberId}

  projects/{projectId}
    +-- tasks/{taskId}
          +-- comments/{commentId}

  notifications/{notificationId}

Summary

The security rules enforce that every user can only access data they own or are explicitly included in, without relying on any external lookups.

For the users collection, each user is completely isolated — they can only read or modify their own profile document. No other user can access it.

In the organizations collection, access is controlled using two lists stored inside each organization document: members and admins. Any user listed as a member can read the organization data, but only users listed as admins are allowed to make changes.

For projects, access is again driven by a members list stored within each project. Only those members can view the project. When creating a project, the user must declare themselves as the owner and also include themselves in the members list, preventing fake ownership. Once created, only the owner of the project is allowed to update or delete it.

Within projects, tasks inherit access through their own members field. Any user listed there can read or modify the task. This ensures that access control remains local to the document without needing to check the parent project.

For comments under tasks, the same pattern continues. Only users listed in the comment's members field can read or create comments. Additionally, each comment has an authorId, and only the original author is allowed to delete their comment, enforcing ownership at a granular level.

Finally, in the notifications collection, each document is tied to a specific user via userId. A user can only read or delete their own notifications and can only create notifications addressed to themselves.

Example 37-1 Security Rule

// USERS
match /users/{userId} {
  allow read, write: if request.auth != null
    && request.auth.uid == userId;
}

// ORGANIZATIONS
match /organizations/{orgId} {

  // Read if user is in members array
  allow read: if request.auth != null &&
    request.auth.uid in resource.data.members;

  // Write only if admin
  allow write: if request.auth != null &&
    request.auth.uid in resource.data.admins;

  // MEMBERS SUBCOLLECTION (optional)
  match /members/{memberId} {
    allow read: if request.auth != null &&
      request.auth.uid == memberId;

    allow write: if false; // managed via org doc only
  }
}

// PROJECTS
match /projects/{projectId} {

  // Read if member
  allow read: if request.auth != null &&
    request.auth.uid in resource.data.members;

  // Create if creator adds themselves as owner
  allow create: if request.auth != null &&
    request.auth.uid == request.resource.data.ownerId &&
    request.auth.uid in request.resource.data.members;

  // Update/Delete only by owner
  allow update, delete: if request.auth != null &&
    request.auth.uid == resource.data.ownerId;

  // TASKS
  match /tasks/{taskId} {

    allow read, write: if request.auth != null &&
      request.auth.uid in resource.data.members;

    // COMMENTS
    match /comments/{commentId} {

      // Read if member
      allow read: if request.auth != null &&
        request.auth.uid in resource.data.members;

      // Create if user is author
      allow create: if request.auth != null &&
        request.auth.uid == request.resource.data.authorId &&
        request.auth.uid in request.resource.data.members;

      // Delete only by author
      allow delete: if request.auth != null &&
        request.auth.uid == resource.data.authorId;
    }
  }
}

// NOTIFICATIONS
match /notifications/{notificationId} {

  allow read, delete: if request.auth != null &&
    request.auth.uid == resource.data.userId;

  allow create: if request.auth != null &&
    request.auth.uid == request.resource.data.userId;
}