ENV variabels or settings


#1

Where do I declare my ENV variables for things like mailgun, stripe payments, paypal, aws bucket etc. I am thinking that these need to be inside Meteor.startup or Meteor.settings? But does that keep them safe and out of the hands of anyone who would otherwise try to get those secret keys?

Is there any documentation or file inside the meteor app that has a list of ENV variables or settings that can be changed?


Where to store my credentials for 3rd party REST API?
#2

Hi @bbush91

You are able to divide your Meteor.settings in elements which are public (available on server AND client) or just stay on server.

We have made a nice package to save larger settings of config params in private YAML or JSON files. See: https://atmospherejs.com/4commerce/env-settings for an idea.

Important config params like password may be given by ENV VAR on start of meteor. So you do not store these somewhere. Just call:

METEOR_SETTINGS={“secrets”: {“mailgun”: “ABC”, “mailchimp”: “DEF”}} meteor

If you use the above package and provide additional conf files, all is mixed on startup.

Just print out on server console.log(Meteor.settings) and on client console.log(Meteor.settings.public) to see what values you have stored.

Good luck


#3

Thanks for the reply! I will have to look into that package.

Is it safe/secure to use Meteor.startup() and declare my ENV variables with process.env.VARIABLE = “”; until I get a chance to dive more into METEOR_SETTINGS?


#4

I do not understand what you mean with

I guess you will not set an ENV var but get the value FROM an ENV var, isn’t it?


#5

For example, on the server the below code would be used to set my env variable for setting up a mail smtp. I was just wondering if this was secure enough to use for now.

Meteor.startup( function() {
 process.env.MAIL_URL = "<Our URL here>";
});

#6

“Normally” accessing ENV_VAR content is to understand as a READ functionality.

So you set your ENVIRONMENT values before starting the node process and get the values from system / server through process.env.varname.

It is also possible to set values by assigning them to process.env.newvar = value but this is only temporarily accessible in the nodejs context or if you run some child processes from your node process.

In case of the email package it is the only option to set the settings by MAIL_URL. So if you define it in your app, then you would probably need to save secrets in your app. That is why ENV_VAR on starting the process is the more advised way.


E.g. read also this comment about process.env from David Walsh https://davidwalsh.name/node-environment-variables


#7

So for stripe secret key I could do

**inside of the server dir. in a file that is excluded from git commits and uploaded on deploy

Meteor.startup(function() {
  process.env.stripeSecretKey = "SECRET_KEY";
  
  stripeSK = process.env.stripeSecretKey;
});

then call stripeSK where ever I need to insert the secret key

or

inside settings.json file that is excluded from git commit and uploaded on deploy

METEOR_SETTINGS = {
  "stripeSecretKey": "SECRET_KEY"
}

stripeSK = Meteor.settings.stripeSecretKey;

Calling stripeSK where ever needed.

Would both of these achieve the same thing? and both being equally secure from hackers or anyone attempting to get my stripe secret key?


#8

If you exclude the file, both parts are doing the same in case of function and security.

However, I would advise you to create yourself a starter.sh like

METEOR_SETTINGS='{"stripeSecretKey": "SECRET_KEY"}' meteor

or on the production system

METEOR_SETTINGS='{"stripeSecretKey": "SECRET_KEY"}' node main.js

The starter should not be stored in git as well

You also may enter once on console while testing:

alias meteor=METEOR_SETTINGS='{"stripeSecretKey": "SECRET_KEY"}' meteor

Then always just need to start meteor during development


#9

Im assuming that starter.sh is a script file that I run?

so inside the file I declare my METEOR_SETTINGS variable and meteor at the end of the file starts up the local server?

likewise for production the node fires the server. what is the main.js? But once deployed to my host, how would I run the starter.sh cause the website/app would already be running once deployed?

using a starter.sh file seems similar to creating a settings.json file and using the command

meteor --settings settings.json

or for production

meteor deploy 'website-here' --settings settings.json

#10

Yes, using starter or settings.json is based on your deployment.

I am not sure if you have ever build an app locally, then you get a README.md in your bundles path that informs how to run the production environment.

This is the content: