Firestore Security With Firebase Authentication

Cloud Firestore Security Rules are used to determine who has read and write access to collections and documents stored in Cloud Firestore, as well as how documents are structured and what fields and values they contain.

In this tutorial, We will learn how to secure your data using Firebase Authentication and Cloud Firestore Security Rules to handle serverless authentication, authorization, and data validation.

To set up and deploy your first set of rules, open the Rules tab in the Cloud Firestore section of the Firebase console.

Cloud Firestore populates a default rule, denying read and write access to everyone on all data:

Working with Security Rule


Cloud Firestore stores its data in a hierarchy of collections, documents, and subcollections, and you’ll often be working to secure data that is several layers deep in the hierarchy. Therefore it’s important to understand how to best work with this hierarchical data.

All documents in Cloud Firestore are stored in a path that begins with /databases/database name/documents — this path is generally not visible to clients working with Cloud Firestore. A client might be writing data to the employees/stanley document, but from the perspective of the Cloud Firestore Security Rules, this write is occurring at databases/database name/documents/employees/stanley.

Match Path


Rules match paths representing a document or collection in Cloud Firestore. Rules may match one or more paths and more than one rule can match the document name in a given request.

The basic type of rule is the allow rule, which allows read and write operations if an optionally specified condition is met.

In most cases, you’ll want to write rules that apply to any document within a collection, not just a specific one. In these situations, you can use wildcards to specify any element within a path. A wildcard is created by adding curly brackets around a string.

Apply rules to multiple documents or collections with wildcards. Wildcards represent the document or collection ID in the match path as a string between curly brackets. Add =** to the end of your wildcard string to apply the wildcard to all documents and subcollections in the path.

The request variable


The request variable is a map that contains information about the request that’s coming in from the client. You can view the reference documentation for a full list of fields, but two fields you’ll frequently be working with are the auth field, which contains information from Firebase Authentication about the currently signed-in user, and the resource field, which contains information about the document being submitted.

Common use cases for the request object include:

  • Confirming that request.auth is not null to ensure that a user is signed in
  • Using the value of request.auth.uid to get the user’s ID, as verified by Firebase Authentication
  • Using request.resource.data. to ensure the value being submitted for a document write meets a particular format. This is most common way to perform data validation within your database.

For example

Resource  vs Request.resource variable


The resource variable is similar to the request.resource variable, but it refers to the document that already exists in the database. In the case of a read operation, this is the document that is about to be read, while in a write operation, this is the old document that is about to be updated or altered.

Both the resource and request.resource objects are maps. Each contains a __name__ property indicating the document name, and a data property where all user-defined properties are declared. By accessing keys within the data property of these maps, you can get the values of the various fields belonging to the document being referenced. For example, resource.data.kesselRun is mapped to the value of the kesselRun field within the document represented by the resource variable.

Examples using the resource object.

Get Document From Database


Using the resource variable will let you evaluate the current document that is about to be accessed, but sometimes you will want to evaluate other documents in other parts of the database.
You can do so by calling the get() function with the document path in the database. This will retrieve the current document, which will allow you to access custom fields through the data property, just like the resource object.
One very common use of this function is to evaluate an access control list and determine if the userID of the current user is part of that list.
The exists() function can also be used to determine if a document already exists.

When entering a path into the exists or get function, you do not include quotes. If you want to include a variable in the path name, you should enclose the variable in parenthesis and preface it with a dollar sign.

For example:

Add Firestore Security Rules with Android Example


In previous tutorial we build a ‘MyThought’ application using Firestore which use for saving thought in Firestore database.In this tutorial we use same project to add firebase security rule.

Add Firebase Authentication


In the Authentication tab of the Firebase console go to the Sign-in Method page and enable ‘Google’
Firebase Enable Login With Google

Add Dependency


Add following dependency in your app.gradle file.

Add FirebaseUI


FirebaseUI has separate modules for using Firebase Realtime Database, Cloud Firestore, Firebase Auth, and Cloud Storage. To get started, see the individual instructions for each module.

Security Rules


Add the following security rules to your project in the: rules tab:

  • Rule 1: Only authorized users can create, read them.
  • Rule 2: Only the user who Creates the Thought can delete it. Thought can never be updated.

 

Download this project from GitHub

 

Related Post

Firestore Document Database Data Model.
Firebase Firestore Database for Android Application.

 

Leave a Reply

Your email address will not be published. Required fields are marked *