Authentication-based rules in Firebase - Step-by-Step Execution

Process Flow - Authentication-based rules

User tries to access data

↓

Check if user is signed in

↓

Allow access

↓

Perform requested operation

This flow shows how Firebase checks if a user is signed in before allowing access to data.

Execution Sample

Firebase

service cloud.firestore {
  match /databases/{database}/documents {
    match /messages/{messageId} {
      allow read, write: if request.auth != null;
    }
  }
}

This rule allows read and write access to messages only if the user is authenticated.

Process Table

Step	User Signed In?	Condition (request.auth != null)	Access Granted?	Action
1	Yes	True	Yes	Allow read or write
2	No	False	No	Deny read or write

💡 Access is granted only if the user is signed in (request.auth is not null). Otherwise, access is denied.

Status Tracker

Variable	Start	After Step 1	After Step 2
request.auth	null	User object (authenticated)	null
Access Granted	No	Yes	No

Key Moments - 2 Insights

Why does access get denied when request.auth is null?

Because the rule explicitly checks if request.auth is not null to allow access. When it is null, the condition fails and access is denied, as shown in execution_table row 2.

What does request.auth represent in these rules?

request.auth represents the user's authentication state. If the user is signed in, it contains user info; if not, it is null. This is why the condition checks for request.auth != null.

Visual Quiz - 3 Questions

Look at the execution table, what is the value of 'Access Granted?' when the user is not signed in?

A No

B Yes

C Maybe

D Depends on data

💡 Hint

Check execution_table row 2 under 'Access Granted?' column.

At which step does the condition 'request.auth != null' evaluate to true?

A Both steps

B Step 2

C Step 1

D Neither step

💡 Hint

Look at execution_table rows and see when the user is signed in.

If we remove the condition 'request.auth != null', what would happen to access control?

A Access would always be denied

B Access would always be granted

C Access would depend on user role

D Access would depend on data content

💡 Hint

Think about the condition controlling access in the execution_table and variable_tracker.

Concept Snapshot

Firebase Authentication Rules:
- Use 'request.auth != null' to check if user is signed in.
- Allow access only if user is authenticated.
- Deny access if user is not signed in.
- Applies to read and write operations.
- Simple and secure way to protect data.

Full Transcript

This visual execution shows how Firebase Authentication-based rules work. When a user tries to access data, Firebase checks if the user is signed in by verifying if 'request.auth' is not null. If the user is signed in, access is granted for read or write operations. If not, access is denied. The execution table traces these steps clearly. Variables like 'request.auth' and 'Access Granted' change accordingly. Key moments clarify why access is denied when not signed in and what 'request.auth' means. The quiz tests understanding of these steps. This helps beginners see how authentication controls data access simply and securely.

Practice

1. What does the Firebase rule condition request.auth != null check for?

easy

A. If the request is from a mobile device

B. If the user has admin privileges

C. If the user is signed in

D. If the database is empty

Solution

1. Step 1: Understand the meaning of request.auth

   request.auth holds authentication info if a user is signed in; otherwise, it is null.

2. Step 2: Interpret the condition request.auth != null

   This condition is true only when a user is signed in, meaning authentication info exists.

3. Final Answer:

   If the user is signed in -> Option C

4. Quick Check:

   Authentication check = user signed in [OK]

Hint: Check if request.auth is not null to confirm user login [OK]

Common Mistakes:

• Thinking it checks for admin rights
• Assuming it checks device type
• Confusing with database content check

2. Which of the following is the correct Firebase rule syntax to allow read access only to authenticated users?

easy

A. allow read: if request.auth == true;

B. allow read: if request.auth == null;

C. allow read: if request.auth.id == null;

D. allow read: if request.auth != null;

Solution

1. Step 1: Identify the correct condition for authenticated users

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

2. Step 2: Match the syntax with the correct condition

   allow read: if request.auth != null; uses allow read: if request.auth != null; which correctly allows reads only for signed-in users.

3. Final Answer:

   allow read: if request.auth != null; -> Option D

4. Quick Check:

   Correct syntax for auth check = allow read: if request.auth != null; [OK]

Hint: Use != null to allow only signed-in users [OK]

Common Mistakes:

• Using == null which allows unauthenticated users
• Checking request.auth.id instead of request.auth
• Using boolean true instead of null check

3. Given this Firebase rule snippet:

allow read: if request.auth != null && request.auth.uid == resource.data.ownerId;

What happens if a signed-in user tries to read data where ownerId is different from their uid?

medium

A. Read access is denied

B. Read access is granted only if user is admin

C. Read access is granted

D. Read access causes a syntax error

Solution

1. Step 1: Analyze the rule condition

   The rule requires the user to be signed in and their user ID (uid) to match the data's ownerId.

2. Step 2: Evaluate the scenario where uid differs from ownerId

   Since the IDs do not match, the condition fails, so access is denied.

3. Final Answer:

   Read access is denied -> Option A

4. Quick Check:

   User ID match required = access denied if no match [OK]

Hint: User ID must match ownerId for access [OK]

Common Mistakes:

• Assuming any signed-in user can read
• Thinking admin rights are checked here
• Confusing syntax error with logic denial

4. Identify the error in this Firebase rule:

allow write: if request.auth.uid = resource.data.ownerId;

medium

A. Missing check for request.auth != null

B. Using single equals (=) instead of double equals (==)

C. Incorrect field name 'ownerId'

D. No error, rule is correct

Solution

1. Step 1: Check the comparison operator

   The rule uses a single equals = which is an assignment, not a comparison.

2. Step 2: Correct operator usage in Firebase rules

   Firebase rules require double equals == for equality checks.

3. Final Answer:

   Using single equals (=) instead of double equals (==) -> Option B

4. Quick Check:

   Use == for comparisons, not = [OK]

Hint: Use == for equality, not = [OK]

Common Mistakes:

• Confusing assignment (=) with comparison (==)
• Ignoring null check for request.auth
• Assuming field names cause error

5. You want to write a Firebase rule that allows users to update their own profile only if they are signed in and the profile's userId matches their uid. Which rule correctly implements this?

hard

A. allow update: if request.auth != null && request.auth.uid == resource.data.userId;

B. allow update: if request.auth != null && request.auth.uid == request.resource.data.userId;

C. allow update: if request.auth == null || request.auth.uid != resource.data.userId;

D. allow update: if request.auth != null && request.auth.uid == resource.data.ownerId;

Solution

1. Step 1: Understand the difference between resource.data and request.resource.data

   resource.data is the existing data; request.resource.data is the new data being written.

2. Step 2: Match user ID with existing data's userId during update

   To allow update only if the profile's existing userId matches the user's uid, compare request.auth.uid with resource.data.userId.

3. Step 3: Verify the condition

   allow update: if request.auth != null && request.auth.uid == resource.data.userId; correctly checks the user is signed in and owns the existing profile.

4. Final Answer:

   allow update: if request.auth != null && request.auth.uid == resource.data.userId; -> Option A

5. Quick Check:

   Check existing data userId matches auth.uid for update [OK]

Hint: Use resource.data for existing ownership checks [OK]

Common Mistakes:

• Using request.resource.data (new data) instead of resource.data (existing data)
• Allowing updates without authentication
• Using wrong field names for user ID