Up and running with Meteor settings, settings.json

We’ve all done it. Exposing an API key in plaintext in your git repo is a bad idea. We all know this, and yet we still do it. This doesn’t usually cause problems, but there are hackers out there running scripts to find your keys, so the potential for damage does exist.

Josh Owens wrote a great article on the perils of exposing your password and gives a few suggestions on how to counter some of the potential security risks while using Meteor.

It’s probably in your best interest to start getting used to using Meteor settings. Here’s how you do it. It should only take about 5 minutes to implement once you understand how it works and you’ll probably want to use it in all your future projects.

Step 1

Create a settings.json file in your root directory. The boilerplate code should look like this:

{
   "public": {
    
  }
}

Any variable that you set under public will be exposed to the client. This is where you put things like your Stripe publishable key, which you need to expose to the client for Stripe to work. Anything outside of public will only run on the server.

Step 2

I’m making the assumption that this is a public git repo, which is why you want to protect your keys in the first place. If that is the case, you will want git to ignore your settings.json file so it doesn’t make its way to the public domain.

You can do this fairly easily by creating a file called .gitignore in your root directory. After you create the file, add the following content:

settings.json

Git will now ignore the settings.json file and will not push it to your public repo. The file will only exist on your local machine. Keep in mind that if you delete your local copy of your code, it will delete the keys.

Step 3

Fill out your settings.json file with your keys. Here’s an example from a project I’m currently working on:

{
  "public": {
    "stripe": {
      "p_key": "pk_test_22r23a...fa3n"
   }
  },
  "stripe": {
    "s_key": "sk_test_32uin...2nio"
  }
}

As you can see, the publishable key is exposed to the client under public, while the secret key is only exposed to the server, which is secure.

Step 4

Now that you have your settings.json file the way you want it, you will want to start meteor with the following command:

$ meteor --settings settings.json

It’s annoyingly redundant code that you will have to type over and over again (unless you create an alias!), but it will protect your keys. After everything starts up, you will have access to these variables in their respective locations.

Step 5

Now, you need a way to access them. You can do this fairly easily with Meteor.settings. Using the Stripe example above, you can access your secret key on the server using the following code:

let secretKey = Meteor.settings.stripe.s_key

And you can access your publishable key using the following code:

let pubKey = Meteor.settings.stripe.p_key

You’ll notice that if you try to access the secret key on the client, it will throw an error that reads something like: TypeError: Cannot read property ‘s_key’ of undefined. This is a good thing! It means you are not exposing your secret key to the client.

Optional

I highly recommend setting up an alias for meteor settings. It’s a real pain to type it out every time you want to run your server. You can do this by opening/creating the file .bash_profile in your home directory (unrelated to your project), then inserting the following code:

alias ms=”meteor — settings settings.json”

This will allow you to use the command ms to launch meteor with settings set to settings.json. It will save you a lot of time.