DEV Community: Pranav Karawale

How to keep your Firebase project safe and secure from everyone

Pranav Karawale — Fri, 18 Dec 2020 06:18:35 +0000

After doing a couple of open source Firebase projects (web apps, I mean), I feel like I'm experienced* enough to write this post. So if I say something wrong here, kindly let me know here.

Why is this necessary?

I have a secret here(not really, just some people don't know about it). Your Firebase config, which you might have been wondering where to hide, is publicly visible(if you use Firebase hosting). Don't believe me? Go to the index page any site which uses Firebase hosting, and just append "/__/firebase/init.js" (eg. someapp.web.app/__/firebase/init.js) ans visit it, and you'll remain surprised by the result. This is something which is not discovered by me, its actually written in the documentation.

Protecting your project

Firestore datastore and Firebase Storage

This is perhaps the most important part of your backend which possibly contains sensitive data, which must be protected and it might cause harm when in the hands of bad people. So how to protect these? Well, here are some steps:

"Start in production mode"

When setting up Firestore and storage, you might get asked whether to start the resource in production mode or test mode. So always choose "Production mode" / "Locked mode". The reason is that this mode introduces some security rules that will block access from every client. Don't fear though, we can still change them.

Configure security rules

Security rules are very great to have. Using these, you can decide who can have access to data and who cannot. These are written in .rules files and have a similar syntax to JavaScript which can be understood in the docs. Since we used production mode, you will see this particular rule in your security rules:

match /{document=**} {
    allow read, write: if false;
}
//Don't remove this rule, or else your project is gone
//and keep this rule at end (this comment is added by me)

Which literally means that no client can access your database and storage, which is sometimes not needed. So we can introduce changes in how we store data.
If you've used Firebase, you know that for every user that signs up for your app, they are assigned a unique ID (or UID). We can store resources based on their UID, for example, in a todo app, one can store user's data in their database at path /todos/users-uid which makes sense. So in this, we can add a new rule:

match /todos/{uid=**} {
    allow read, write: if request.auth != null and request.auth.uid == uid;
}

This means that if anyone accesses any path under todos collection, they should be authenticated to the app, and if they try to access a specific UID in the collection, the database will only allow access if they access data under their UID.
Do the same for Firebase storage as well.

Use seperate API keys if they are used only for one purpose

Suppose you are also developing a CLI for your app (which I am doing), you might need your API key for refreshig the user's JWT (which I am doing :) ). So just don't use the same Firebase config API key, create a new one which has only access to the things we need, in this case, we need access to the Token Service API. So you can move to the Google APIs dashboard, and then select your preferred project.

When you're in the dashboard, go to the 'Credentials' section.
Then in the top app bar, click the "Create Credentials" button. A drop down will appear. Select "API key"
Then it will show a dialog like this:
Then that key will appear in the "Keys" section. Then, in that list, find the API key we just created, and then click on the pencil icon.
Scroll down and you'll find a section "API restrictions". Select the option "Restrict key".
Then a dropdown will appear with text "Select APIs". Then select the services which you want the API key to be working with. I'll select the Token Service API here.
Just hit the "Save" button.

Then in the keys' section, you'll find that the API key has a green check on it. It means that it is now secure and you'll bear less damage if it got leaked.

If you need to have your API keys in your repo

If your code is public, and you need your API keys for testing or just to keep everything modular and smooth, encrypt it and then save it. I also use a similar approach in my CLI app, beacuse I need it for CI. You can use any encryption method which uses public-private key pair and then store the encrypted file in your repo and then decrypt it whenever needed.

Respect Firebase server credentials

Now this is important. We've been talking about the general Firebase config which we add in our web apps, but now, I'm talking about server credentials, which are used by the Admin SDKs. These are allowed access everywhere; no one can deny them. So treat them with respect and keep them as a secret only, don't show them off or else you're done.

Ending thoughts

Good job if you've made it this far. Now you can just chill back and write some code for your project. Always tell me if you got stuck in any of the steps. Have a nice day :)

Reactivity Anywhere - without virtual DOM

Pranav Karawale — Fri, 20 Nov 2020 06:37:05 +0000

How did this got into my mind??

Virtual DOM can be referenced as the thing which just "introduced" me to the title of this post. What if we keep aside all that diffing, state stuff and focus on one thing: reactivity between the JavaScript and the DOM. Well, most of us are using libraries just to achieve this reactivity in their apps. But most of them implement a virtual DOM which keeps track of all the tags, states, variables, objects and whatnot and then syncs them with the real DOM. As said, things might get a little crazy doing all this stuff. So I just decided, why not just implement a crude example of all this "virtual DOM" thing without virtual DOM. Is this even achievable?? The answer is (0.5 * yes)!! For the sake of this post, lets call it "Reactivity Anywhere"

Disclaimer

This post might have things that seem vague and senseless. Also don't take things too seriously here, take them as just a thought. Reader discretion is advised.

Let's Start!!

Prerequisites

A web browser
JavaScript

Defining the global variables(precisely, stores)

In order to keep track of what goes here and there, we need some global variables to preserve and mutate all the state.

const __refs__ = {};
const __reactives__ = [];
const __reactiveEl__ = document.querySelectorAll("[reactive]");
const reactive = (obj) => {
  /*Add logic*/
};
const __updateDOM__ = (ref) => {
  /*Add logic*/
};

This is just everything we need for the logic. The variables whose names start and end with double underscores are __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED.
We will only store two things: references to the elements, and, of course, the reactive variables.

But this seems like virtual DOM!!!

But I'm sorry, this is not the virtual DOM you think:

We will not be diffing the whole element tree for every single change; only and only the affected element will be mutated (less carbon dioxide)

Determining `reactive` elements

In order to keep specificity and refrain from scanning the whole DOM, we will just handpick special elements that work with our module. So, any element that has the reactive attribute (<element reactive></element>) , will only be able to use the special reactive powers.

In order to access the reactive elements from the store, we will use the ES6 string interpolation syntax. So, to access the count, we will write

<h1 reactive>The time is ${count}</h1>

The `refs`

Here, we will store the values of the object passed in the reactive function.

The `reactives`

This is just an array containing live references of the DOM Elements.

The `reactive()`

This function is basically a store where you'd be storing all the reactive stuff.
The definition of the function is surprisingly simple:

const reactive = (obj) => {
  //Loop through the string
  Object.keys(obj).forEach((key) => {
    // defineProperty, anyone??
    // We want to maintain reactivity, so we are using custom
    // getters and setters
    Object.defineProperty(__refs__, key, {
      get() {
        return obj[key];
      },
      // This shows an interesting aspect of the logic.
      // This will update the target element everytime
      // something changes.
      set(val) {
        obj[key] = val;
        __updateDOM__(key);
      },
    });
    // Think of this as an initial render
    __updateDOM__(key);
  });
  // This is an important step otherwise
  // everything is useless
  return __refs__;
};

The `updateDOM()`

This is the Rosetta for the reactive DOM Elements and the __refs__. This function is also relative simple in its definition:

// Ref can be any key from the __refs__ store
const __updateDOM__ = (ref) => {
  // This is to check whether we want to update a specific ref value
  if (ref) {
    __reactives__
      // filter out the elements we need
      .filter((reactive) => reactive.dataset.ref === ref)
      .forEach((reactive) => {
        let ref = reactive.dataset.ref;
        // Interacting with the DOM
        // Nullish coalescing, anybody?
        reactive.textContent = __refs__[ref] ?? "";
      });
  }
  // UPDATE ALL!!
  else
    __reactives__.forEach((reactive) => {
      let ref = reactive.dataset.ref;
      // Interacting with the DOM
      // Nullish coalescing, anybody?
      reactive.textContent = __refs__[ref] ?? "";
    });
};

Finding all the reactive variables and bootstrapping them

This can basically be wrapped as an IIFE (Immediately Invoked Function Expression) but I don't consider doing it for the sake of simplicity. So, here we go!!

// Get live elements
const __reactiveEl__ = document.querySelectorAll("[reactive]");
__reactiveEl__.forEach((el) => {
  // Match the `count` between <h1 reactive>${count}</h1>
  const refs = el.innerHTML.match(/\${([^}]+)}/g);
  // If the refs exist
  if (refs) {
    refs.forEach((ref) => {
      // extract it
      const dataRef = ref.split("{")[1].split("}")[0].trim();
      // insert a special span element with the element
      // and store the key name in the `data-ref` attribute
      el.innerHTML = el.innerHTML.replace(
        ref,
        `<span class="reactivity-anywhere" data-ref="${dataRef}"></span>`
      );
    });
    // Push the span element in __reactives__
    __reactives__.push(...el.querySelectorAll("span.reactivity-anywhere"));
  }
});
// Initialize all the magic!!
__updateDOM__();

Making `<input>` and `<textarea>` work with reactives

Of course, we need this if user input is needed for our code to run.

The supercharged textareas and input elements will bear the ref attribute

A lot of things, harsh things are going to be done in this section, so brace yourself and hold on tight.

const parseDefaultRefValue = (el) => {
  let parsed = null;
  try {
    // If the passed key is a function, run it
    // and store the value
    // I'm sorry, but we need to use eval here
    parsed = eval(`(${el.getAttribute("ref-default")})()`);
  } catch (e) {
    parsed = el.getAttribute("ref-default");
  }
  return parsed;
};
const assignDefaultRefsToInputs = (el, ref) => {
  __refs__[ref] = parseDefaultRefValue(el);
};
// Select input and textarea elements containing the
// 'ref' attribute, where the attr. value refers to any
// key in the __refs__ store.
// The `ref-default` contains the default value for the `ref`
// eg.
// <textarea ref="name"></textarea>
document.querySelectorAll("input[ref], textarea[ref]").forEach((el) => {
  // Keep a ref to the ref!! Because we don't want to
  // lose it in event listeners
  const ref = el.getAttribute("ref");
  if (ref) {
    // lazily update default values
    window.addEventListener("load", () => assignDefaultRefsToInputs(el, ref));
    el.addEventListener("input", () => {
      // again, a dumb reference to the ref
      const elRef = ref;
      // preserve default value
      const defaultVal = parseDefaultRefValue(el);
      // Set whatever value is typed as the ref value
      // else, the default value
      __refs__[elRef] = el.value !== "" ? el.value : defaultVal;
      if (__refs__[elRef] !== defaultVal) {
        // Keep rest of the input/textarea elements in sync
        Array.from(document.querySelectorAll("input[ref], textarea[ref]"))
          // Find input/textareas with same refs
          .filter((el) => el.getAttribute("ref") === elRef)
          // Keep their value in sync
          .forEach((el) => (el.value = __refs__[elRef]));
      }
    });
  }
});

We're almost done!

Now the only thing that remains is to write some HTML to check whether everything works!
So, here we go!!
Some more things to note here:

You can use multiple stores!! However, if you redeclare a key in the latter store, it will take precedence, not the first one

Why something like this would be great to use (according to me)

It will allow HTML to do its work and JS to do its own. Its not like "All HTML!" or "All JS!" but a harmony between the two (not to mention CSS here) that will appreciate the job these languages have to do.
Minimal overhead. As I said earlier, no virtual DOM, only real DOM (credits to Svelte) with some objects in memory

Limitations

You're going to think over this :), because this is just a crude implementation of an idea. So, feel free to critically think over it.

Ending notes

If you seem to be intrested in creating some sort of framwework with this, you're ready to go (some frameworks, using this idea, might even exist)! I'd also be happy to help you! Thank you for bearing with me in such a long post!

My experience of writing a CLI in Go

Pranav Karawale — Thu, 15 Oct 2020 17:16:46 +0000

How I ended up here?

So here I am, tinkering with React and Vite and Material UI, making a simple, productive app called Lookahead for the lay man and the hoodie(?) dev. Now, it turns out that, Google Keep doesn't have a CLI!! And here's what I think would be a great experience(and hopefully someone notices my work) to make a CLI interface for Lookahead. And so this is the high level overview of how I ended up here.

Why Go??

I was thinking of making the CLI in Node.js(feels like home for a webdev, right?). So, pkged or nexeed the file, I get the binary in build/. Hooray!! Just look to the right of the screen... file size : 130,769 KB. Yes, these numbers are as real as global warming is, I am not joking. How am I gonna distribute these?? Even .gz won't help(file size ~30MB). And those binaries are way too slow. I feel my heart pain while running the binary. And yeah, I also wanted to learn a new language after Web stuff and Python, and magically, the Gopher jumped out in the field!! And honestly, after 2 weeks, I am up and writing the CLI(though with not that much sense of convention and semanticity and stuff; will be dealt later). So I would like to give a little overview of what I have done, and will be doing.

Things I wish would have been done by somebody

And now I have a real, hard time with Firebase. No, not the API key stuff, but there is NO CLIENT LIBRARY!! Surely, there are official SDKs, but those are for server side(meh! my CLI ain't a server) so there is only one option, use the REST APIs!! And yeah, to be honest, now I feel pretty much comfortable with those APIs and stuff(REST APIs and not the fancy gRPC thingy)

Things that I have done

I just implemented some authentication logic which is displayed below:

From the user's side

User types look login -> User enters the email -> A sign-in link is sent to their mail -> They open it -> A message will come on their browser like "Yeah, open the CLI to continue" -> They open the CLI -> Signed in successfully!!!

From the CLI and server side

Request email link to be sent -> Wait for link to be opened -> After link is opened, get that oobCode parameter and temporarily store it -> Convert the oobCode into a Firebase ID token -> CLI gets the ID token, along with a refresh token, to renew the ID token -> BAM!! All well

Things yet to implement

Of course, the main purpose of the CLI, notes and to-dos... But I'll do it later next week, I have exams coming this week. This will need using the Firestore REST API (gRPC looks like overkill to me for this; I am not at all familiar with gRPC)
Refreshing the UX in the CLI

Ending here...

I will make some code posts, so be in the event loop to catch those. I hope you are having a nice day, reader!! Goodbye for now.

Watch and build code with esbuild

Pranav Karawale — Wed, 29 Jul 2020 10:01:00 +0000

How I found esbuild to be great

I think you must be aware of esbuild(if not, check it out), the next-gen, ultra-fast bundler for JavaScript and TypeScript written in Go. When I first landed on the GitHub page, I thinked of trying it out. So I quickly opened VSCode which had my current project using Rollup. So I quickly swapped Rollup with esbuild and voila, built in <500 ms!! A significant increase from the built in >25s that Rollup shows up. I decided to just start using it right away. But, esbuild has not its own watch mode, for now. I mean, its a MVP (edit: resolved) for now, but no worries, I got you covered.

Some News

esbuild has its own official Watch API! Go there if you're in a hurry.

Let's code!!

For this, I will be using

TypeScript (if you dont know, just ignore the ':' and '<>' things and everything will be okay),
ts-node, for running scripts,
esbuild (of course!)
chokidar, for watching files

The very first thing,

$ npm i typescript ts-node esbuild chokidar -D

Then, create a file under scripts/watch-code.ts(of course you need not go by that), and first import all the things we need:

Then, the utility functions:

You might wonder, why do we need that noop() at the first glance. But look deeper, and you understand it. In the second function, updateLine(), we are taking in the second parameter isBuiltInput to prevent gibberish. For example:

You saved the code:

built in 452ms

Then comes an error after sometime:

ERROR: jfkjdfgkfd
sdsdsdfsadfds(just an example)

You resolve it and save it...

ERROR: jfkjdfgkfd
sdsdsdfsadfds(just an example)Built in 125ms.
//                            ^ Oops?!

In order to prevent this, we set the cursor position exactly one line below the "Watching your files..." line, and clear the garbage after the cursor, and print the good old Built in x ms message.

After this, enter the build() function:

To get that options list, look at the full list of build options for more info.

And then, we just write something that runs all that stuff we discussed above:

Now that you have everything, why not run it out! To do that, go to package.json, and do this:

"scripts": {
  "watch": "ts-node-script scripts/watch-code.ts"
}

Now you are the most powerful programmer. Go ahead, type some code, do mistakes, resolve them, and that bundles right after you hit Ctrl+S/⌘+S.

In case you are in a hurry..

Copy the code and paste it!