36 Common Rule Patterns and Examples

This chapter presents a collection of practical, reusable rule patterns and service-specific examples that developers can apply across Oracle Backend for Firebase services. These patterns are based on real-world use cases and demonstrate how to enforce access control using CEL expressions with request and resource context.

• Common Rule Patterns
  
• Service-Specific Rule Applications
  

36.1 Common Rule Patterns

These patterns can be adapted and combined to suit a wide range of application needs.

Owner-Only Access

Restrict access to a document so that only the user who created it (the owner) can read, update, or delete it.

Example 36-1 Allow Update Only by Owner

The following rule ensures that only the user whose UID matches the uuid field in the document can perform the update.

match /users/{userid}/recipes/{resid} {
  allow update: if request.auth != null && request.auth.uid == resource.data.uuid;
}

Public Read Access

Allow anyone to read a document if it is marked as public.

Example 36-2 Public Read with Fallback to Owner

The following rule allows public access to posts marked isPublic == true, and private access to the owner.

match /posts/{postId} {
  allow get: if resource.data.isPublic == true || (request.auth != null && request.auth.uid == resource.data.ownerId);
}

Conditional Creation

Allow document creation only if certain fields in the request meet specific criteria.

Example 36-3 Require isPublic to be True

The following rule ensures that only authenticated users can create documents, and only if they explicitly set isPublic to true.

match /users/{userid}/recipes/{resid} {
  allow create: if request.auth != null && request.resource.data.isPublic == true;
}

Time-Based Access

Restrict access based on the current server time.

Example 36-4 Allow Read Only in November

This rule allows access to reports only during the month of November.

match /reports/{reportId} {
  allow get: if request.time.month() == 11;
}

Field-Based Filtering

Use document fields to control access dynamically.

Example 36-5 Allow read if status is "active"

match /projects/{projectId} {
  allow get: if resource.data.status == "active";
}

Cross-Document Validation

Use macros to validate access based on related documents.

Example 36-6 Allow Creation only if Referenced User Exists

match /projects/{projectId} {
  allow create: if request.auth != null && exists(/users/$(request.resource.data.ownerId));
}

Wildcard-Based Access

Apply rules to multiple documents using path wildcards.

Example 36-7 Allow Read on All Subcollections for Authenticated Users

match /users/{userid}/{path=**} {
  allow read: if request.auth != null;
}

Restrict by Token Claims

Use fields from the authentication token to enforce access.

Example 36-8 Allow Access only to Users with Verified Email

match /users/{userid} {
  allow get: if request.auth.email_verified == "true";
}

36.2 Service-Specific Rule Applications

This section demonstrates how security rules are applied within individual Oracle Backend for Firebase services—Database, Object Storage, and Authentication. While the rule syntax remains consistent across services, each service has unique contexts, data models, and access patterns that influence how rules are written and enforced.

• Database Rules
  
• Object Storage Rules
  
• Authentication Rules
  

36.2.1 Database Rules

Database rules govern access to documents, collections, subcollections, joins, and duality views. These rules are enforced at the document level and support both relational and collection-based models.

Document-Level Access

This rule allows a user to update a recipe only if they are the owner.

match /users/{userid}/recipes/{recipeid} {
  allow update: if request.auth.uid == resource.data.uuid;
}

Collection Group Rules

This enables querying across all recipes subcollections, regardless of their parent document.

match /.*/recipes {
  allow read: if request.auth != null && resource.data.difficulty == "Easy";
}

Join Collection Rules

This rule applies to a join view created from multiple relational tables and restricts access to engineering department data.

match /engineering_view/_docId {
  allow read: if request.auth != null && resource.data.dept == "Engineering";
}

36.2.2 Object Storage Rules

Object Storage rules control access to file uploads, downloads, deletions, and metadata operations. These rules are enforced per file path and can be used to generate public URLs or restrict access based on user identity.

Public File Access

The following rule allows downloading a file if it is marked as public.

match /files/{fileId} {
  allow get: if resource.data.isPublic == true;
}

Owner-Only File Management

The following rule allows only the file owner to delete the file.

match /files/{fileId} {
  allow delete: if request.auth.uid == resource.data.ownerId;
}

Upload Restriction

The following rule allows file upload only for authenticated users and if the file size is less than 10MB.

match /uploads/{fileId} {
  allow create: if request.auth != null && request.resource.data.size < 10485760;
}

36.2.3 Authentication Rules

Authentication rules are not enforced directly by the Auth service but are used in conjunction with token claims and identity provider metadata to control access in other services.

Email Verification Check

The following rule allows access only if the user’s email is verified.

match /users/{userid} {
  allow get: if request.auth.email_verified == "true";
}

Identity Provider Restriction

The following rule restricts updates to users authenticated through Oracle IDCS.

match /users/{userid} {
  allow update: if request.auth.idp_type == "IDCS";
}