<h1>How to use Meteor's Settings.json</h1>

Security for your keys

With the rise of big-wig social media apps being hacked in past few years, security is vital for frameworks like Meteor.
So, Meteor provided Settings.json, a file to store API keys and other config info that can choose to hide from the client.

What are API Keys?

• When your program uses another application, it communicates with that application's API.
• It communicates using an API key, a password that identifies the calling program, its developer, or its user to the Web site.
• used to track and control how the API is being used
  • eg to prevent malicious use or abuse of the API

Reference: Wikipedia Defines API Key

Does BigBlueButton use API keys?

BigBlueButton’s HTML5 client doesn’t actually use any API keys. We’ve configured the API our app uses, Redis, to listen on the localhost of our main server so we don't have to use a key for authentication.

BBB is also a single server solution, meaning that all dependencies and components are on the server too. So it never has to send out any requests over the network to communicate with them. They’re all right there in the same home.

How do I use Settings.json?

It’s use is really simple: it’s just a JSON file, ie. a file with key-value pairs.
Here’s an example:

magicPizzaService is going to only be available on the server and can be accessed in your javascript with:

By default, anything we put inside of our object is accessible only on the server.
If we do want a key or configuration value to be available on the client, we can simply wrap it in an object named public:

But don’t worry, your unwrapped key is still private! You don’t even have to wrap it with private, but you can if you want!

The keys wrapped in public and private can be accessed in your javascript like so:
Notice in the 3rd example that you don't need to do settings.private.keyName, because it is the default.

How to load the settings

In BigBlueButton, since we startup Meteor via command line, we use this command to make our settings available and run the app at the same time:

>>meteor --settings settings.json

Splitting settings.json

Another security concern is the values you need in development vs. production. When testing and developing, you should use API keys linked to dummy accounts(especially when users or our product has to pay money for the services.

For example, in BBB, we want to have an HTTPS connection only in production. (and use HTTP in development). We can store a different value for each mode, prod and dev.

Just remember:

*NEVER COMMIT settings-production.json*

Never ever. You don’t want your keys to be stolen from your published source code. Even if your repo is private, Github, Bitbucket, and other source code storage tools are still vulnerable to hacking themselves!

Josh Owens’ blog post on the subject really hits the point home with this Github search for S3 keys.

The easiest way to deal with this is to put settings-production.json in .gitignore file (the file GIT uses to know which files to hide from commits).

Follow these steps separate dev from production:

1. separate settings.json file into two files: settings-development.json and settings-production.json


2. Put values for testing in settings-development.json , and values for real end-users in settings-production.json . Notice the two files are identical except for the values!

Load one of the two files when starting up Meteor:

1. >>meteor --settings settings-development.json
OR

2. >>meteor --settings settings-production.json

How are we using this in BBB?

This solution above didn’t fit all of our needs, we wanted to:

1. Have a shorter way to launch into dev (since we are in dev most of the time)


2. Have separate files for our public and private values, not just wrapped separate objects in the same file


3. Have common values for dev and prod without having to duplicate our code across the two files

We found that this package does all of that! 4commerce:env-settings

And its installation was straightforward as well.

This suited our needs exactly! And given the configuration info that we want to store in our files, this is part of the directory structure we chose for BigBlueButton:

This way, our Javascript code stays free of config values and we can simply use them wherever needed.
Although we're not storing any sensative data, it localizes, organizes and reduces our overall code!

Credit for images and Meteor content Meteor Documentation - Making Use of Settings.json

Please feel free to leave comments or questions below :)