npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

firestore-rule-compiler

v1.1.1

Published

Firestore rules can be complicated to work with and quickly get repetitive and verbose. However, to properly secure and structure a Firestore database they are essential. That's where the Rule Compiler comes in. You write a model in JSON that matches the

Downloads

16

Readme

Firestore Rule Compiler

Firestore rules can be complicated to work with and quickly get repetitive and verbose. However, to properly secure and structure a Firestore database they are essential. That's where the Rule Compiler comes in. You write a model in JSON that matches the schema, pass it through the compiler and use the resulting rules file.

Features

  • Powerful JSON schema
  • Helpers for common security rules
  • Scale your rules easily
  • Enforce data types and structure
  • Input raw strings for extra flexibility
  • Granular operation control

CLI Usage

Usage: Firestore Rule Compiler [options] <inputFile

Arguments:
  inputFile            json model file to load

Options:
  -d, --debug          output extra debugging
  -V, --version        output the version number
  -o, --output <path where to save the generated rules
  -h, --help           display help for command

Editor autocomplete

To get autocomplete for ".rules.json" files in VSCode add the following to your settings.json

"json.schemas": [
    {
      "fileMatch": [
        "*.rules.json"
      ],
      "url": "https://raw.githubusercontent.com/tajetaje/firestore-rule-compiler/main/src/lib/model.schema.json"
    }
  ]

Example rules

Input model (this is not all possible options):

{
  "topLevelMatchPath": "/databases/{database}/documents",
  "matches": [
    {
      "collectionPath": "users",
      "documentName": "uid",
      "isWildCardRecursive": true,
      "isWildCard": true,
      "allowRules": [
        {
          "methods": [
            "get"
          ],
          "requireAuth": true
        },
        {
          "methods": [
            "list",
            "update"
          ],
          "requireAuth": true,
          "conditions": [
            {
              "fieldA": {
                "fieldA": "request.auth.uid",
                "comparator": "==",
                "fieldB": "uid"
              },
              "comparator": "||",
              "fieldB": {
                "fieldA": "request.auth.token.permissions",
                "comparator": "==",
                "fieldB": "'admin'"
              }
            }
          ]
        }
      ],
      "children": [
        {
          "collectionPath": "internal",
          "documentName": "info",
          "allowRules": [
            {
              "methods": [
                "read",
                "write"
              ],
              "requireAuth": true,
              "requiredClaims": [
                {
                  "name": "permissions",
                  "value": "'admin'"
                }
              ]
            }
          ]
        }
      ]
    }
  ]
}

Output rules

rules_version = '2';

/*
 * Generated on: 7/20/2022, 10:31:58 PM
 */
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{uid=**} {
      allow get: if request.auth != null;
      allow list: if (request.auth.uid == uid || request.auth.token.permissions == 'admin') && request.auth != null;
      allow update: if (request.auth.uid == uid || request.auth.token.permissions == 'admin') && request.auth != null;
    
      match /internal/info {
        allow read: if request.auth != null && request.auth.token.permissions == 'admin';
        allow write: if request.auth != null && request.auth.token.permissions == 'admin';
      
      }    
    }
  }

  function getOr(request, field, alt) {
    return request.resource.data.get(field, alt);
  }
}

In-depth explanation

The compiler refers to the input JSON file as the model for your rules. The structure of the top level model is simple, with only three properties. The first is topLevelMatchPath, which is usually just going to be "/databases/{database}/documents". The second is matches, an array of Match objects, this is where the heavy lifting is done. The last top-level property is customFunctions, an array of strings that will be formatted and added to the end of the rules file. This is where you can add your own functions that you want to have access to in your rules.

Match:

| Property | Type | Description | | --- | --- | --- | | collectionPath (req) | string | The slash separated path to the field, e.g. "collection/document/sub-collection", no leading or trailing slashes | | documentName (req) | string | The name of the document, e.g. "uid" | | isWildCardRecursive | boolean | Whether or not the match is recursive, e.g. "collection/document/sub-collection/sub-sub-collection/sub-sub-document" | | isWildCard | boolean | Whether or not the match is a wildcard, e.g. "collection/document/sub-collection/*" | | allowRules | AllowRule[] | The logical rules to apply to the field | | structureRules | StructureRule[] | The type-based rules to apply to the field | | children | Match[] | The children of the match, if any |

AllowRule:

| Property | Type | Description | | --- | --- | --- | | methods (req) | string[] | An array of strings, each of which is a method name, e.g. "get", "list", "update" | | requireAuth | boolean | Whether or not the rule requires authentication | | conditions | Condition[] | An array of conditions, each of which has the following properties: | | requiredClaims | { name: string; value?: string | number | boolean }[] | Adds a rule for each claim, if value is set for the claim, adds "request.auth.token.${name} == ${value}" to the condition, otherwise adds "request.auth.token.${name} != null" |

StructureRule:

| Property | Type | Description | | --- | --- | --- | | field (req) | string | The name of the field to check | | type | string[] | The allowed types for the field. If type is not specified, just make sure the field exists and ignore type (results in no effect to update) | | required | boolean | Whether or not the field is required |

Condition:

| Property | Type | Description | | --- | --- | --- | | fieldA (req) | string | Field | The lefthand field to compare, can be a field object, or a string that is taken literally | | comparator (req) | string | The comparator to put between the two fields, e.g. "==", "!=", ">", "<", ">=", "<=" | | fieldB (req) | string | Field | The righthand field to compare, can be a field object, or a string that is taken literally | | isInverted | boolean | Should the expression be preceded by "!" |

Field:

| Property | Type | Description | | --- | --- | --- | | fieldA (req) | string | Field | The lefthand field to compare, can be a field object, or a string that is taken literally | | comparator (req) | string | The comparator to put between the two fields, e.g. "==", "!=", ">", "<", ">=", "<=", "+", "/" | | fieldB (req) | string | Field | The righthand field to compare, can be a field object, or a string that is taken literally |

Future project goals

  • Generate client-side code
  • Add more helpers to reduce boilerplate
  • Add emulator testing to the project