DEV Community: Oddbit

How to Keep Your Custom Claims in Sync with Roles Stored in Firestore

Dennis Alund — Thu, 25 Apr 2024 06:50:36 +0000

A common question I often encounter, is how to maintain consistency between custom claims in Firebase Auth and role assignments stored in Firestore.

It is common in applications to have role-based authentication, where the access to resources is determined by a given role and where there are admin users have the authority to assign or revoke roles.

While Firestore provides an excellent backend to manage such information, it's crucial that this role data also be useful in authorization logic. In Firebase this is by best practice implemented in Firestore rules and Storage rules to declare resource access for database and files.

One of the ways to implement this is to only keep the data in Firestore, and another way to do it is to maintain the information in auth custom claims.

Both solutions has a few considerations to keep in mind.

Considering Your Options

As an illustration of the considerations, consider these security rules that are implementing each solution for two separate areas of the database and storage.

`firestore.rules`

service cloud.firestore {
  match /databases/{database}/documents {

    // Alt A: Using roles stored in Firestore user documents to determine access
    match /collection-a/{document} {
      allow read: if 'admin' in getUserRoles();
    }

    // Alt B: Using auth claims (role as an array) to determine access
    match /collection-b/{document} {
      allow read: if request.auth != null && 'admin' in request.auth.token.roles;
    }    

    // Function to get user roles from Firestore document
    function getUserRoles() {
      return get(/databases/$(database)/documents/users/$(request.auth.uid)).data.roles;
    }
  }
}

`storage.rules`

service firebase.storage {
  match /b/{bucket}/o {

    // Alt A: Using roles in user documents to determine access
    match /folder-a/{allPaths=**} {
      allow read: if 'admin' in getUserRoles();
    }

    // Alt B: Using auth claims to determine access
    match /folder-b/{allPaths=**} {
      allow read: if request.auth != null && 'admin' in request.auth.token.roles;
    }

    // Function to get user role from Firestore document
    function getRoleFromFirestore() {
      return get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role;
    }
  }
}

Option A: Firestore Document Lookups

If you choose to use Firestore document lookups for role-based access control, you're leveraging a straightforward method that works well with Firestore and Cloud Storage.

The primary drawback of this approach is its applicability is limited to just Firestore and Cloud Storage; it doesn't extend to Firebase's Realtime Database or other services that might benefit from integrated role-based access control.

It is also important to note that using Firestore documents to check authorization rules in both Firestore and Cloud Storage incurs additional document read costs each time an access check is performed.

Option B: Using Firebase Auth Custom Claims

The alternative involves replicating role information in Firebase Auth custom claims. This method offers broader integration across various services, including the Realtime Database and external API integrations where authentication data might be accessed via OAuth.

To implement this, a dedicated cloud function is essential for synchronizing role updates from Firestore documents to Firebase Auth custom claims. This function ensures that any changes in user roles within Firestore are promptly reflected in Firebase Auth.

Implementing the Cloud Function

The cloud function required for this task should:

Trigger on updates to the user document specifically related to role changes.
Update Firebase Auth custom claims to reflect these changes.
Maintain any other existing custom claims in the user's auth object.

Here’s a simple example of such a cloud function:

export const updateUserRoles = functions.firestore
  .document('/users/{userId}')
  .onUpdate(async (change, context) => {
    const beforeData = change.before.data();
    const afterData = change.after.data();

    // Check if roles have changed
    if (JSON.stringify(beforeData.roles) === JSON.stringify(afterData.roles)) {
      functions.logger.info('Roles are unchanged. Do nothing.');
      return null;
    }

    const uid = context.params.userId;
    const newRoles = afterData.roles;

    // Get the current auth user and merge the new roles into the claims
    const user = await admin.auth().getUser(uid);
    const newClaims = { ...user.customClaims, roles: newRoles };
    return admin.auth().setCustomUserClaims(uid, newClaims);
});

Conclusion

Both approaches offer distinct advantages depending on your application's specific needs. Whether you prioritize broader service integration or a more focused, cost-effective solution within Firestore and Cloud Storage, understanding these options will empower you to make informed decisions about implementing role-based access control in your Firebase environment.

Backing up Firebase project with Github Actions

Dennis Alund — Wed, 29 Apr 2020 15:38:05 +0000

Backups are really useless most of the time... until something goes wrong and you really need one.

This article will help provide some easy to apply recipes to back up your Firebase project, in a single Github Action workflow.

To implement this workflow you will be needing

Firebase token for CI/CD deployment.
Service account that can access your Firebase project and storage buckets.

We will be making a snapshot backup that is being replaced for each run and another accumulative one that is adding every new
backup into an historical archive.

Make sure that your GCP project has a "backups bucket". It should be listed in your Google Cloud Platform Console, but not in the Firebase console. Replace example in the URL below to check and confirm.

https://console.cloud.google.com/storage/browser?project=example

If your project ID is example, then you should have a bucket called example-backups.

The bucket is automatically created if you have already configured Firebase Database automated backups before. You can configure to switch them on right away to get two-for-one: both having the bucket generated and benefits of automated backups.

We will be using this bucket to store our own backups too.

/.github/workflows/backup-snapshot.yml

The schedule for your snapshot backups is up to you on how frequent you find it necessary. In this example we're making a nightly snapshot of the project.

/.github/workflows/backup-archive.yml

The schedule for your archive backups is also up to your own needs, depending on how frequent you find it necessary. In this example we're making a monthly backup archive of the project.

Finally

Sleep well knowing that your project is backed up on a regular basis.

Publishing Dart Packages with Github Actions

Dennis Alund — Sat, 09 Nov 2019 13:24:21 +0000

A tutorial that will get you started with automated publishing of Dart packages to the pub.dev package repository, in less than 3 minutes.

In a couple of minutes from now, you will have a Github Action workflow that does all the heavy lifting of publishing your dart package or
Flutter plugin to pub.dev for you.

Let’s get started.

Get your credentials

First you need to get and setup your credentials for publishing the package. Make sure that you publish your first version manually from the command line so that your package gets listed and you become the owner of that listing.

After that, find your credentials.json file either in ~/.pub-cache or ~/<your flutter root>/.pub-cache/

$ cat ~/.pub-cache/credentials.json 
{
 “accessToken”:”<access-token>”,
 ”refreshToken”:”<refresh-token>”,
 ”tokenEndpoint”:”https://accounts.google.com/o/oauth2/token",
 "scopes":["openid","https://www.googleapis.com/auth/userinfo.email"],
 "expiration":1570721159347
}

Copy your access and refresh tokens and create secret variables in your Github project and name them
OAUTH_ACCESS_TOKEN and OAUTH_REFRESH_TOKEN respectively. They will match the names in the script below later.

Set up your Github Actions workflow

You can either choose to setup your actions direcly from the Github website or just add
this YAML configuration file
into your project and push the change to the Github repository.

/.github/workflows/dart.yml

Publishing new versions

This script will now publish a new version of your package to pub.dev every time you merge to the master branch.
It’s important to rember that each new version that you are publishing must have a new semantic version number in your pubspec.yaml and you should also declare a corresponding explanation of what you have updated in the CHANGELOG.md. The deployment will complain if you don’t.