Rule syntax and structure in Firebase - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to allow read access to all users.

Firebase

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read: if [1];
    }
  }
}

Drag options to blanks, or click blank then click option'

Arequest.auth != null

Bfalse

Ctrue

Drequest.time < timestamp.date(2020, 1, 1)

Attempts:

3 left

💡 Hint

Common Mistakes

Using false blocks all access.

Using request.auth != null restricts to signed-in users only.

Setting allow read: if true; means anyone can read the data.

2fill in blank

medium

Complete the code to allow write access only if the user is authenticated.

Firebase

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow write: if [1];
    }
  }
}

Drag options to blanks, or click blank then click option'

Atrue

Brequest.time > timestamp.date(2023, 1, 1)

Cfalse

Drequest.auth != null

Attempts:

3 left

💡 Hint

Common Mistakes

Using true allows anyone to write.

Using false blocks all writes.

The condition request.auth != null checks if the user is signed in.

3fill in blank

hard

Fix the error in the rule condition to allow read only if the user is authenticated.

Firebase

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read: if [1];
    }
  }
}

Drag options to blanks, or click blank then click option'

Arequest.auth = null

Brequest.auth != null

Crequest.auth == null

Drequest.auth = true

Attempts:

3 left

💡 Hint

Common Mistakes

Using assignment = instead of comparison == or !=.

Checking for null with wrong operator.

The correct syntax to check authentication is request.auth != null.

4fill in blank

hard

Fill both blanks to allow write access only if the user is authenticated and the document ID matches the user ID.

Firebase

service cloud.firestore {
  match /databases/{database}/documents {
    match /users/[1] {
      allow write: if request.auth != null && request.auth.uid == [2];
    }
  }
}

Drag options to blanks, or click blank then click option'

A{userId}

Brequest.auth.uid

CuserId

Ddocument.id

Attempts:

3 left

💡 Hint

Common Mistakes

Using userId without braces in the path.

Using request.auth.uid instead of userId.

The path variable {userId} captures the document ID, and request.auth.uid is the signed-in user's ID.

5fill in blank

hard

Fill all three blanks to allow read access only to authenticated users and only for documents in the 'posts' collection where the post is published.

Firebase

service cloud.firestore {
  match /databases/{database}/documents {
    match /posts/[1] {
      allow read: if request.auth != null && resource.data.[2] == [3];
    }
  }
}

Drag options to blanks, or click blank then click option'

A{postId}

Bpublished

Ctrue

Dfalse

Attempts:

3 left

💡 Hint

Common Mistakes

Using false instead of true for published check.

Not capturing the document ID in the path.

The path variable {postId} captures the document ID. The rule checks if the published field is true and the user is authenticated.

Practice

1. What is the main purpose of a match block in Firebase security rules?

easy

A. To create new collections automatically

B. To define user roles and permissions

C. To write data to the database

D. To specify which data paths the rules apply to

Solution

1. Step 1: Understand the role of match blocks

   The match block is used to specify the path in the database where the rules apply.

2. Step 2: Differentiate from other rule parts

   Other parts like allow control access, but match targets the data location.

3. Final Answer:

   To specify which data paths the rules apply to -> Option D

4. Quick Check:

   match = data path selector [OK]

Hint: Remember: match points to data location [OK]

Common Mistakes:

• Confusing match with allow
• Thinking match defines user roles
• Assuming match writes data

2. Which of the following is the correct syntax to allow read access to all users in a Firebase rule?

easy

A. allow read { true }

B. allow read: if true;

C. allow read = true;

D. allow read if (true)

Solution

1. Step 1: Recall correct allow syntax

   The correct syntax uses a colon and condition: allow read: if true;

2. Step 2: Check other options for syntax errors

   Options A, B, and D use incorrect symbols or missing keywords.

3. Final Answer:

   allow read: if true; -> Option B

4. Quick Check:

   Correct allow syntax uses colon and if [OK]

Hint: Use colon and 'if' for conditions in allow [OK]

Common Mistakes:

• Using '=' instead of ':'
• Omitting 'if' keyword
• Using braces instead of semicolon

3. Given the rule snippet:

match /posts/{postId} {
  allow read: if request.auth != null;
  allow write: if request.auth.uid == resource.data.authorId;
}

What happens if a logged-in user tries to write to a post they did NOT create?

medium

A. Write is denied because user is not the author

B. Write is allowed because user is logged in

C. Write is allowed only if postId matches user ID

D. Write is denied because read access is restricted

Solution

1. Step 1: Analyze write condition

   Write is allowed only if request.auth.uid == resource.data.authorId, meaning user must be the author.

2. Step 2: Apply condition to user not author

   If user is logged in but not the author, condition fails, so write is denied.

3. Final Answer:

   Write is denied because user is not the author -> Option A

4. Quick Check:

   Write allowed only for author = A [OK]

Hint: Check if user ID matches author ID for write [OK]

Common Mistakes:

• Assuming any logged-in user can write
• Confusing read and write conditions
• Ignoring resource data in condition

4. Identify the error in this Firebase rule snippet:

match /users/{userId} {
  allow read if request.auth.uid == userId;
  allow write: if request.auth.uid == userId;
}

medium

A. Missing colon after 'allow read'

B. Incorrect variable name 'userId'

C. Missing semicolon after 'allow write' condition

D. Using '==' instead of '=' in conditions

Solution

1. Step 1: Check syntax for 'allow' statements

   Each allow must have a colon before the condition, e.g., allow read: if ...;

2. Step 2: Identify missing colon

   The first line misses colon after allow read, causing syntax error.

3. Final Answer:

   Missing colon after 'allow read' -> Option A

4. Quick Check:

   Colon required after allow keyword [OK]

Hint: Always put colon after allow before condition [OK]

Common Mistakes:

• Omitting colon after allow
• Confusing '=' and '=='
• Forgetting semicolon at line end

5. You want to write a rule that allows users to read their own profile data but only write if their profile contains a non-empty 'name' field. Which rule snippet correctly enforces this?

hard

A. match /profiles/{userId} {
allow read: if request.auth.uid == userId;
allow write: if request.resource.data.name != "";
}

B. match /profiles/{userId} {
allow read: if request.auth.uid == userId;
allow write: if request.auth.uid == userId || request.resource.data.name != "";
}

C. match /profiles/{userId} {
allow read: if request.auth.uid == userId;
allow write: if request.auth.uid == userId && request.resource.data.name != "";
}

D. match /profiles/{userId} {
allow read: if true;
allow write: if request.auth.uid == userId && request.resource.data.name == "";
}

Solution

1. Step 1: Understand read condition

   Users can read only their own profile: request.auth.uid == userId.

2. Step 2: Understand write condition

   Write allowed only if user owns profile AND 'name' field is not empty: request.auth.uid == userId && request.resource.data.name != "".

3. Step 3: Check options for correct logic

   match /profiles/{userId} { allow read: if request.auth.uid == userId; allow write: if request.auth.uid == userId && request.resource.data.name != ""; } matches both conditions correctly; others use wrong logic or allow too much.

4. Final Answer:

   match /profiles/{userId} { allow read: if request.auth.uid == userId; allow write: if request.auth.uid == userId && request.resource.data.name != ""; } -> Option C

5. Quick Check:

   Use AND for ownership and non-empty name [OK]

Hint: Use AND (&&) to combine ownership and data checks [OK]

Common Mistakes:

• Using OR (||) instead of AND (&&)
• Allowing write without ownership check
• Checking for empty string incorrectly