Resource and request objects in Firebase - Commands & Configuration

Introduction

When building apps with Firebase, you often need to handle data and actions securely. Resource and request objects help you define what data is available and what actions users can perform. They make sure your app works correctly and safely.

When you want to control who can read or write data in your Firebase database.

When you need to check what data a user is sending before saving it.

When you want to respond differently based on the user's request details.

When you want to protect your app from unwanted or harmful data changes.

When you want to log or audit user actions on your Firebase resources.

Config File - firestore.rules

firestore.rules

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
    match /posts/{postId} {
      allow read: if true;
      allow write: if request.auth != null && request.resource.data.keys().hasAll(['title', 'content']) && request.resource.data.title is string && request.resource.data.content is string;
    }
  }
}

This file defines rules for Firestore database access.

rules_version: sets the version of rules syntax.

service cloud.firestore: targets Firestore database.

match /databases/{database}/documents: applies rules to all documents.

match /users/{userId}: allows only authenticated users to read/write their own user data.

match /posts/{postId}: allows anyone to read posts but only authenticated users can write posts with required fields 'title' and 'content' as strings.

request.auth: the user making the request.

request.resource.data: the data being written.

Commands

This command uploads and activates the Firestore security rules defined in the 'firestore.rules' file to your Firebase project.

Terminal

firebase deploy --only firestore:rules

Expected Output

=== Deploying to 'your-project-id'...



i  deploying firestore.rules

✔  firestore.rules: Rules deployed successfully



✔  Deploy complete!

→

--only firestore:rules - Deploys only Firestore security rules without affecting other Firebase services.

Starts the local Firestore emulator so you can test your rules and database behavior safely on your computer without affecting live data.

Terminal

firebase emulators:start --only firestore

Expected Output

i  emulators: Starting emulators: firestore

✔  firestore emulator running at http://localhost:8080



All emulators started, it is now safe to connect your app.

→

--only firestore - Starts only the Firestore emulator.

Fetches the document 'post1' from the 'posts' collection in the local Firestore emulator to verify read access.

Terminal

curl -X GET 'http://localhost:8080/v1/projects/your-project-id/databases/(default)/documents/posts/post1'

Expected Output

{

  "name": "projects/your-project-id/databases/(default)/documents/posts/post1",

  "fields": {

    "title": {"stringValue": "Hello World"},

    "content": {"stringValue": "This is a test post."}

  },

  "createTime": "2024-06-01T12:00:00.000Z",

  "updateTime": "2024-06-01T12:00:00.000Z"

}

Attempts to write a new document 'post2' to the 'posts' collection in the local Firestore emulator, testing write rules with required fields.

Terminal

curl -X PATCH 'http://localhost:8080/v1/projects/your-project-id/databases/(default)/documents/posts/post2' -H 'Content-Type: application/json' -d '{"fields": {"title": {"stringValue": "New Post"}, "content": {"stringValue": "Content here."}}}'

Expected Output

{

  "name": "projects/your-project-id/databases/(default)/documents/posts/post2",

  "fields": {

    "title": {"stringValue": "New Post"},

    "content": {"stringValue": "Content here."}

  },

  "createTime": "2024-06-01T12:05:00.000Z",

  "updateTime": "2024-06-01T12:05:00.000Z"

}

Key Concept

If you remember nothing else from this pattern, remember: resource and request objects let you control who can do what with your Firebase data and what data is allowed.

Common Mistakes

Trying to write data without required fields in request.resource.data.

The security rules reject writes missing required fields, causing the write to fail.

Always include all required fields with correct data types when writing data.

Allowing read or write access without checking request.auth.

This can expose or allow changes to data by anyone, risking security.

Always verify request.auth to restrict access to authenticated users as needed.

Deploying rules without testing them locally first.

Mistakes in rules can block legitimate access or allow unwanted access in production.

Use the Firebase emulator to test rules before deploying.

Summary

Write Firestore security rules using resource and request objects to control data access and validation.

Deploy rules with 'firebase deploy --only firestore:rules' to apply them to your project.

Test rules locally using the Firestore emulator and curl commands to simulate reads and writes.

Practice

1. What does a request object in Firebase functions mainly contain?

easy

A. Logs of previous function executions

B. Details about the data or file that triggered the function

C. Settings for Firebase project configuration

D. Information about what the user sent and how

Solution

1. Step 1: Understand the role of request objects

   The request object holds details about the user's input and request method.

2. Step 2: Differentiate from resource objects

   Resource objects describe the trigger data or file, not user input.

3. Final Answer:

   Information about what the user sent and how -> Option D

4. Quick Check:

   Request object = user input info [OK]

Hint: Request = user input details, Resource = trigger data [OK]

Common Mistakes:

• Confusing resource object with request object
• Thinking request holds trigger file info
• Assuming request contains project settings

2. Which of the following is the correct way to access the data sent by a user in a Firebase HTTPS function's request object?

easy

A. request.data.body

B. request.body.data

C. request.payload

D. request.trigger.data

Solution

1. Step 1: Recall request object structure

   In Firebase HTTPS functions, user data is inside request.body.

2. Step 2: Identify correct property for user data

   The user data is accessed as request.body.data if data is nested inside body.

3. Final Answer:

   request.body.data -> Option B

4. Quick Check:

   Access user data via request.body.data [OK]

Hint: User data is inside request.body in HTTPS functions [OK]

Common Mistakes:

• Using request.data.body which is invalid
• Trying to access request.payload which doesn't exist
• Confusing trigger data with request data

3. Given this Firebase function snippet:

exports.myFunction = functions.storage.object().onFinalize((object, context) => {
  console.log(object.name);
  console.log(context.eventId);
});

What does the object parameter represent?

medium

A. The Firebase project configuration

B. The user's HTTP request data

C. The file that triggered the function

D. The function's execution logs

Solution

1. Step 1: Identify the trigger type

   The function triggers on a storage object finalization, meaning a file event.

2. Step 2: Understand the object parameter

   The object parameter holds info about the file that triggered the function.

3. Final Answer:

   The file that triggered the function -> Option C

4. Quick Check:

   Storage trigger object = file info [OK]

Hint: Storage triggers pass file info as object parameter [OK]

Common Mistakes:

• Thinking object is user request data
• Confusing context with resource object
• Assuming object holds config or logs

4. Identify the error in this Firebase HTTPS function code:

exports.func = functions.https.onRequest((resource, request) => {
  console.log(request.body);
});

medium

A. Parameters are reversed; should be (request, response)

B. Missing return statement

C. Incorrect function name

D. No error; code is correct

Solution

1. Step 1: Check HTTPS function parameters

   HTTPS functions receive (request, response) parameters in that order.

2. Step 2: Identify parameter misuse

   The code uses (resource, request) which reverses and misnames parameters.

3. Final Answer:

   Parameters are reversed; should be (request, response) -> Option A

4. Quick Check:

   HTTPS function params = (request, response) [OK]

Hint: HTTPS functions always use (request, response) parameters [OK]

Common Mistakes:

• Swapping request and response parameters
• Using resource parameter in HTTPS function
• Ignoring parameter order importance

5. You want to write a Firebase function triggered by Firestore document changes. Which object should you use to access the changed document's data inside the function?

hard

A. resource.after.data()

B. request.body

C. context.params

D. resource.data()

Solution

1. Step 1: Understand Firestore trigger parameters

   Firestore triggers receive a change object with before and after snapshots.

2. Step 2: Access the new document data

   The updated document data is accessed via change.after.data(), which is the resource object.

3. Final Answer:

   resource.after.data() -> Option A

4. Quick Check:

   Firestore change after data = resource.after.data() [OK]

Hint: Use resource.after.data() for updated Firestore document data [OK]

Common Mistakes:

• Using request.body which is for HTTP functions
• Using context.params which holds path variables
• Using resource.data() which is old snapshot, not updated