DEV Community: Paul Rondeau

Server Side Authentication with Firebase and Next.js

Paul Rondeau — Mon, 27 Apr 2020 14:27:05 +0000

In this tutorial I will go over how to set up server-side authentication for an application using Firebase Auth and Next.js. The motivation behind server-side authentication was to permit server-side rendering (SSR), which is one of the huge benefits of using a framework like Next.js, for an application that requires rendering some user data.

tl;dr Store the Firebase user idToken as a cookie. Send that cookie in getInitialProps to an API function to validate it with the Firebase Admin SDK. If valid, query your database for the data you require on page load and pass that data to the app as a prop.

This does not work out of the box when using Firebase Auth because all of their login logic happens on the client-side when using their Javascript SDK. The typical flow of an application that uses Firebase Auth is as follows:

User logs in first time, Firebase SDK writes a cookie that only the Firebase SDK can access.
When the user returns to the site, the Firebase SDK automatically verifies a valid token or refreshes an expired one, thereby logging the user in automatically.
Depending on the app, the UI may flash once the user has been logged in and taken into the application.

Where this breaks down

If we are using a framework such as Next.js, you most likely want to utilize the benefits of SSR (no screen flash or client-side JS execution). For performance reasons, Next.js will try to render as much of a page as it can on the server-side, and send the resulting HTML to the browser. However, if your application has a blocking requirement for user data, than you cannot pre-render any of the application until the Firebase SDK logs the user in.

Introducing Server Side Authentication

If, during the initial page load, we can log a user in on the server and query the DB for that user info, we should be able to pre-render the site for the user (no screen flash or client-side JS execution). How can we verify if a page request is coming from a logged in user? Cookies!

If we write our own cookie with some Firebase-verifiable user token, we should be able to verify a user is who they say they are on the server. Let's dive into the details.

User Login/Logout Flow

Once the user logs in using the Firebase SDK, we will write a cookie that can be access by the server. Using a simple library called js-cookie, we can read/write cookies to the browser for a user. Now the actual cookie we write needs to be something that firebase can verify is a valid user credential. For this, we will use the idToken retrieved from a Firebase user object. This is a short-lived user token that can be passed to a server and validated by the Firebase Admin SDK. You can read more about the specifics here.

import cookie from 'js-cookie';
import 'firebase' from 'firebase/app';
import 'firebase/auth';

const tokenName = 'tokenName';

firebase.auth().onAuthStateChanged(async (user: firebase.User) => {
  if (user) {
    const token = await user.getIdToken();
    cookie.set(tokenName, token, { expires: 1 });
    this.setState({ user });
  } else {
    cookie.remove(tokenName);
    this.setState({ user: null, userData: null });
  }
});

User Returns to Site

Here is where the magic happens. We need two things. First, update the _app.tsx to attempt to retrieve the cookie we set during login. Second, validate that cookie using the Firebase Admin SDK. We will be using a Next framework called next-cookies to automatically retrieve a cookie for us from local storage. The great thing about next-cookies is the ability to run on the client or server-side. In the App's getInitialProps method we will make an API request to validate the specified token and if valid, will populate the props for the app. Here's the code in app.tsx to get said cookie and make a request to the api function /api/validate.

import fetch from 'isomorphic-unfetch';

class MyApp extends App {

  constructor(props) {
    super(props);
    this.state = {
      user: this.props.user,
      userData: this.props.userData,
    }
  }

  render() {
    const { Component, pageProps } = this.props;
    const { user, userData } this.state;
    return <Component {...pageProps} user={user} userData={thisuserData} />;
  }

  static async getInitialProps(appContext: AppContext) {
    const { ctx } = appContext;
    // calls page's `getInitialProps` and fills `appProps.pageProps`
    const appProps = await App.getInitialProps(appContext);

    // only run on server-side, user should be auth'd if on client-side
    if (typeof window === 'undefined') {
      const { tokenName } = nextCookie(ctx);

      // if a token was found, try to do SSA
      if (tokenName) {
        try {
          const headers: HeadersInit = {
            'Content-Type': 'application/json',
             Authorization = JSON.stringify({ token: tokenName });
          };
          const result = await fetch('/api/validate', { headers });
          return { ...result, ...appProps };
        } catch (e) {
          // let exceptions fail silently
          // could be invalid token, just let client-side deal with that
        }
      }
    }
    return { ...appProps };
  }
}

Using the Firebase Admin SDK we can validate that token securely. After we validate the token, we can query some backend data store to retrieve the initial props we want to populate our app with, in this case it is user data retrieved from Firestore. We will need an API function called /pages/api/validate.tsx.

import * as admin from 'firebase-admin';

interface UserData {
  // arbitrary user data you are storing in your DB
}

interface ValidateResponse {
  user: {
    uid: string;
    email: string;
  };
  userData: UserData
}

const admin = admin.initializeApp({
  // your admin app creds
});

const validate = (token: string) => 
  const decodedToken = await admin.auth().verifyIdToken(token, true);
  console.log('Valid token.');

  // get user data from your DB store
  const data = (
    await admin
      .firestore()
      .doc(`/users/${decodedToken.uid}`)
      .get()
  ).data() as UserData;

  const user = await admin.auth().getUser(decodedToken.uid);
  const result = {
    user: {
      uid: user.uid,
      email: user.email,
    },
    userData: data,
  };
  return result;
};

export default async (req: NextApiRequest, res: NextApiResponse) => {
  console.log('Validating token...');
  try {
    const { token } = JSON.parse(req.headers.authorization || '{}');
    if (!token) {
      return res.status(403).send({
        errorCode: 403,
        message: 'Auth token missing.'
      });
    }
    const result = await validate(token);
    return res.status(200).send(result);
  } catch (err) {
    return res.status(err.code).send({
      errorCode: err.code,
      message: err.message,
    });
  }
}

Now that Next has the initial props we want to render, it can go ahead SSR the entire app for this specific user with all of their data populated in it. Success!

There's quite a lot to unpack in those snippets, but there's a few key parts. In the getInitialProps method, if there is no token found, the validate API call is skipped entirely. If there is a token, we make an HTTP request to /api/validate with a header that includes the token. If that API request returns data, then the token was validated and the props can be populated with the result of the validate call. If the API call returns a rejected promise, we render the page without any user data. Since this is a short lived token, the token may have once been valid, but is no longer valid. In this case, the API function returns a rejected promise and we cannot SSR the page for the user. Luckily, on the client-side, the Firebase SDK will refresh the user's credentials, at which point a new cookie will be saved for future requests.

You may have noticed I used state instead of props to pass data into the components. This is to handle changing data. If for instance your user logs out, you probably want to update your local state and stop rendering user data in the child components for that user.

Hope you enjoyed this tutorial and helped elevate your Next.js and Firebase project!

If you have any questions, hit me up on Twitter.

This article was originally published on parondeau.com on 2020-04-09.

GCP Credentials & Next.js

Paul Rondeau — Tue, 14 Apr 2020 18:58:47 +0000

Let's begin with the problem. You're running a Next.js app on ZEIT Now, you've created some API functions and now you want to make an authenticated call to some GCP service using their client libraries (Firebase, GCS, Big Query, etc). For apps not running on GCP, you must provide your own set of credentials to make authenticated requests to your GCP services, however, we don't want to just go and store those credentials in our repo as plaintext (🚨 danger️️ous 🚨)! We should use some secure data-store for this. Luckily, if you're deploying on Now, it has support for secrets, but they only allow the secret value to be a string.

$ now secrets add <secret-name> <secret-value>

Wouldn't it be nice if we could store our service account JSON in that secret? Turns out we can with the power of base64 encoding. With a few commands we can turn our JSON key into a secret that can be consumed in our API functions.

Here are the steps we'll need to do

Create a GCP service account with the appropriate permissions.
Download a JSON credential for that service account.
Convert that service account into a base64 encoded string and save it as a Now Secret.
Configure the build processes (remote and local) of Now to access this secret and store it as an environment variable.
Configure Next.js to expose this environment variable to the application.
Read the environment variable in our API function, base64 decode it and create a Google Credential from that key.
Make authenticated requests to your GCP services like Firebase, GCS, BigQuery, etc.

Creating and managing the Service account

First you'll need to create a service account in GCP with the appropriate permissions granted to it, Google has a simple guide explaining how to do this. Next, download a JSON key of this account. Once you have your JSON key, you can rename it if you'd like to match the following shell command. Now that we have our JSON key, we can create a Now secret using the data in it.

$ now secret add <secret-name> $(cat service-account.json | base64)

ZEIT Now configuration

Now that your service account is encoded via base64 and stored in Now. We need to set up a few more things in the build process for that secret to be accessible by your API function. We have two cases we need to cover, one, your local development build will need to read that secret and two, the remote deployment of Next.js on Now. Using Now build configuration we will tell the Now deployment to mount that secret into our Next app configuration so we can access the secret as an environment variable.

For the local case, we will create a new file called .env.build at your project root. You will need to copy the base64 encoded secret into this file. Be sure to add this file to your .gitignore or else your secret may become public!

$ echo GOOGLE_APPLICATION_CREDENTIALS=$(cat service-account.json | base64) >> .env.build
$ echo .env.build >> .gitignore

Now instead of starting up your service with npm run dev or yarn dev you will need to start using now dev check this blog post for more info.

For the remote case, you will need to create a file in the root called now.json and populate it as follows.

{
  "build": {
    "env": {
      "GOOGLE_APPLICATION_CREDENTIALS": "@secret-name"
    }
  }
}

Be sure to note the "@" symbol, this tells Now to use a secret of this name instead of the raw string.

Next.js Configuration

Next up we want to configure Next to expose this environment variable to the application. To do so, modify your next.config.js. If you don't already have one, create an empty file at the root again and name it next.config.js. Add the following to that file. Check out the Next docs for more info on using a custom next.config.js.

module.exports = {
  env: {
    GOOGLE_APPLICATION_CREDENTIALS: process.env.GOOGLE_APPLICATION_CREDENTIALS,
  },
};

Accessing the Service Account in the API Function

We have one final step before we can make authenticated calls to GCP. That is reading the environment variable where our secret is stored, and turning it back (base64 decode) into a credential that can be consumed by the various GCP SDKs. Once we do this, we can make all the authenticated requests we like!

const credential = JSON.parse(
    Buffer.from(process.env.GOOGLE_APPLICATION_CREDENTIALS, 'base64').toString()
);

// Authenticate with the GCS SDK
import { Storage } from '@google-cloud/storage';

const storage = new Storage({
    projectId: '<gcp-project-id>',
    credentials: credential,
});

// Authenticate with the Firebase Admin SDK
import * as admin from 'firebase-admin';

admin.initializeApp({
    ...appOptions,
    credential: admin.credential.cert(credential),
});

That just about sums it up. Hope this helps you on your Next project!

If you have any questions, hit me up on Twitter.

This article was originally published on parondeau.com on 2020-04-03.

Self-Hosting Ghost on GCP

Paul Rondeau — Thu, 09 Apr 2020 18:04:55 +0000

As most software engineers will attest, I think there's some law that every programmer must completely redo their blog/website every 2 years. So this is me, paying my dues.

tldr; Run a Ghost docker image on Cloud Run, configure a custom domain and connect it to Cloud SQL MySQL for ~$5/month.

In this post I will try and explain how this site was configured and served. I had a few goals when redesigning my website.

I wanted the cleanest writing experience possible
I wanted to run this as cheaply as possible
I wanted minimal maintenance once configured
I wanted the ability to tweak the UI to my heart's content

With these restrictions, I started searching for a blogging platform. Previously I had a static-site generated blog set up using Markdown, but I found, as with many DIY blog platforms, the editing experience to be poor and deployment to be cumbersome.

Prerequisites

There are a few things this tutorial assumes you have already completed.

docker installed
gcloud configured
Google Container Registry, Cloud Run and Cloud SQL APIs initialized
GCP Billing configured

Helpful links [1], [2].

Enter Ghost Stage Right

As described by themselves Ghost is "...a powerful platform for creating an online blog or publication". After playing around with the product I found that Ghost certainly passes goals (1) and (3) with flying colours, and does a decent job at (4), depending on how you configure it. But when we look at (2), using Ghost Pro doesn't do so well. Coming in at $29/month, this was quite a bit more expensive than I was willing to pay for a personal blog that I make $0/month on. After diving through their developer documentation I found a few options available to self-host Ghost. This could significantly lower the costs.

There exists a sanctioned, but community run unofficial Docker image containing Ghost and the necessary dependencies to run the service. After playing around with this locally I decided it was time to try putting this on the line. Coming from a ton of experience in GCP, the easiest way for me to get the docker image out there was to use Cloud Run. Simply pass in a docker image and Cloud Run manages it for you. It will scale it up and down and manage access via GCP IAMs. You can even connect it to a private domain you own.

Configuring Cloud Run

You can only deploy images on Cloud Run that you have created and stored in Google Container Registry (GCR). So let's grab that Ghost docker image and upload it to our own GCP.

docker pull ghost:3.12.0
docker tag ghost:3.12.0 gcr.io/<GCP_PROJECT_NAME>/ghost:3.12.0
docker push gcr.io/<GCP_PROJECT_NAME>/ghost:3.12.0

Fantastic, we now have our own docker image stored on GCR. Let's set up Cloud Run to deploy this image. You can follow along this Google tutorial and these screenshots, but it is fairly straightforward.

Follow the prompts and be sure to select:

Cloud Run (fully managed)
A region that suits your needs
Allow unauthenticated invocations

Once you make it to the second screen select the newly created docker image in your GCR and be sure to select the container port to be 2368, this is the default port Ghost will be listening on. I kept most of the defaults, make sure the memory allocated is at least 256 MiB or else you run the risk of Ghost running out of memory and crashing.

Click create and you're well on your way to running your own blog. If you'd like to connect your own domain you can follow this Google tutorial. It is fairly trivial and just involves updating a few DNS records.

Now navigate to the newly created URL (or the custom url if you configured that) to see your brand spankin' new Ghost blog self-hosted for a fraction of the cost of Ghost Pro. To access the admin panel navigate to <blog-url>.com/ghost. Here you will configure the first admin user, be sure to pick a strong password! You can now write posts and have them appear on <blog-url>.com.

Narrator: Little did they know...

Enter the First Problem Stage Left

I noticed this one the hard way, after re-deploying my Ghost image a few times to update some config I found that I was forced to create new admin user every time and no post that I had written would persist. After some digging, I found the problem. By default, the Ghost docker image uses a local installation of SQLite to store all of the data. When you deploy the image on Cloud Run, it instantiates the SQLite DB, however whenever we turn the container off or start a new one the database is effectively re-created from scratch, thereby deleting all of your data.

This is not good.

What if we had some external database that our Ghost image could connect to on startup. This would certainly deal with our data persistence problem.

Enter Cloud SQL from Above

Since we're already so deep in Google land, why don't we delve a bit deeper. Google offers a Cloud SQL service which effectively runs a relational database (PostgreSQL, MySQL, or SQL Server) on the internet for you with a ton of security, backup and integrations to make your life easy.

Now after poking around the Ghost documentation I found that they support a variety of DB connections. If we can configure a Cloud SQL instance to run MySQL and connect our Cloud Run instance to that instance we should have all the pieces we need for a self-hosted Ghost blog that actually persists your data.

Cloud SQL is easy to configure, follow the prompts like so and be sure to generate a strong password for your instance.

Note: When selecting a machine type, I choose the db-f1-micro to save costs. Be sure to select a DB type that will support your needs.

Click create and there you have it. Your a new Cloud SQL instance for all your SQL needs. Now comes the tricky part: connecting Cloud Run to Cloud SQL.

Connecting the Dots

Lucky for us, Cloud Run has first-party support for connecting to a Cloud SQL instance so we do not even need to really think about Cloud SQL Proxy. Again, props to Google because they have a tutorial for just about all of these steps, to connect your Cloud Run instance to Cloud SQL follow this one.

Once you add the Cloud SQL connection you will need to do one final step. Unlucky for me (but lucky for you) I had to figure out how to tell Ghost to connect to a remote SQL instance. We can do this by passing the database connection info into the docker image via Environment Variables. For security purposes Cloud SQL can only be accessed over a Unix Socket. However, in probably the biggest gap in Ghost's documentation, they do not explain how to connect to a DB via Unix Socket whatsoever. Luckily after poking around the DB connection code in Ghost (+1 for open source), I found the magic solution. They blindly pass in any configuration defined in the database config block to knex, and lucky for us again, knex supports Unix Sockets! So all we need to do is setup the database configuration to use the Unix Socket that Cloud SQL is running on. Add the following Environment Variables to your Cloud Run instance. Make sure you replace <DB_PASSWORD>, <CLOUD_SQL_INSTANCE> and <BLOG_URL> with the appropriate values that you've previously defined.

Once that is setup you can deploy a revision to your Cloud Sql instance and voilà!

Navigate to the Cloud Run URL and you should see your new blog running, backed by a Cloud SQL database. You can verify this by logging in creating an admin account, adding a test post then creating a new revision (with the same configuration) of your Cloud Run instance. You should be able to log back in with the same admin credentials and see the old posts you've written.

–– End Scene ––

Now that your instances are configured and running, you can start to configure your Ghost installation as you'd please. You can find some themes and templates that you like.

Well that wraps up this tutorial. I hope you were able to follow along and didn't come across too many hurdles. Happy blogging!

If you have any questions, hit me up on Twitter.

This article was originally published on parondeau.com on 2020-04-05.