I have a project that I built with Angular. I want to host it but it makes calls to an API with an API KEY. From my understanding, there is no way to secure your keys from the client. I have been researching how to accomplish this, but I cannot find anything useful.
I want to deploy this small app to Heroku to learn how to do this. In my environment.ts file Should I replace the values with the variables in the .env file, build the application, then just add the key/value pairs to Heroku's Config Vars?
You can create two environment files. One for development and one for production:
environment.dev.ts:
export const environment = {
API_KEY: "XXX"
};
environment.prod.ts:
export const environment = {
API_KEY: process.env.API_KEY
};
Define these files in angular.cli.json:
"environments": {
"dev": "environment.dev.ts",
"prod": "environment.prod.ts"
}
Add --prod to postinstall script for Heroku deploys in package.json:
"postinstall": "ng build --aot --prod"
And finally, add Config Vars in Heroku dashboard or using heroku-cli:
heroku config:set API_KEY=PROD_XXX
Have you considered creating a backend for the API call? Your server could function as a middleman to authenticate your user and only make API calls your code intended to make. It is not clear what kind of API is used in your app but it can be dangerous to expose API keys not intended for public use (unlike Firebase API keys which are meant to be public).
Anyway, you should never store credentials hard-coded or commited to repository through configuration files. The basic steps are:
Create a .env file in your project root and add it to .gitignore. This is for local development.
Set production config vars in Heroku CLI or Dashboard.
Update environment.ts:
export const environment = {
...rest,
exampleApiKey: process.env.EXAMPLE_API_KEY,
};
Related
I want to deploy my app using Heroku but I have kept my API keys in .env file which will be ignored by .gitignore file while pushing to Heroku and after deploying my app on Heroku, it is no longer able to read my API keys and app crashes? What to do in this case? How to use it correctly?
If your not storing your .env file in your git repository (which is absolutely the correct thing to do) then you need to manually configure the .env file once you deploy it.
In the instance of Heroku you can set Config Vars:
Configuration and Config Vars
If you do it that way I believe you have to access the vars in a different manor to env values but it has a local mode so that shouldn't be a problem.
You have to specify all the API keys in your START script in "package.json". Like below
"start": "MONGO_USER=abcis app.js"
My NX application's npm run build:server calls ng build api-server that triggers the #nrwl/node:build builder.
It builds the NestJS application as main.js. Things work except I wanted process.env.NODE_ENV to be evaluated at runtime but I think it was resolved at build time (via Webpack).
Currently, the value is always set to 'development'.
I am new to Nrwl's NX. Any solution this?
In NestJs/Nodejs app in Nx.Dev workspace process.env.NODE_ENV is replaced during compilation from typescript to javascript very "smart way" to "development" string constant (everything like NODE_ENV is replaced). I don't know why. But only way how can I get real NODE_ENV in runtime is this code:
//process.env.NODE_ENV
process.env['NODE' + '_ENV']
The reason you're seeing development is because you're building the app in development mode - it's not best practice to evaluate at runtime because then the builder can't do fancy things to make the build production ready. If you want production, you need to build the app in production mode by adding the --prod flag (just like how you need to build Angular in production mode).
If you need to serve the app in production mode (instead of build) the default config doesn't provide you with a prod mode for serve. You'll need to add the configuration to your angular.json.
So this code:
"serve": {
"builder": "#nrwl/node:execute",
"options": {
"buildTarget": "api-server:build"
}
},
Would become
"serve": {
"builder": "#nrwl/node:execute",
"options": {
"buildTarget": "api-server:build"
},
"configurations": {
"production": {
"buildTarget": "api-server:build:production"
}
}
},
and then you can run
ng serve --project=api-server --prod
Indeed the nx builder will replace the expression process.env.NODE_ENV in our source code with the current value of the env var (or the nx-mode).
What happens is this:
the build command executes the nx builder which creates a configuration for web-pack
this configuration instructions for the webpack-define plugin to replace the text process.env.NODE_ENV during compilation with the actual value of the env-var (or the nx-mode):
see nx-code getClientEnvironment()
Since the webpack-define plugin will look for the text process.env.NODE_ENV, it's easy to use a workaround as explained in this answer:
process.env['NODE'+'_ENV']
Warning
When you need to apply this workaround to make your app work, then something is wrong. Since you have compiled your app in production mode, it does not make sense to pass another value for NODE_ENV when you start the (production) app.
The webpack Production page contains some helpful info.
We also had this case, and the issue was, that we relied on the NODE_ENV variable to load different database configs for dev, prod, test, etc.
The solution for our case was to simply use separate env-vars for the database config (e.g. DB_NAME, DB_PORT, ..), so that we can use different db-configs at runtime with any build-variants: dev, prod, test, etc.
I recently faced the same problem using Express instead of Nest.
What we did to overcome this was adding some file replacements when compiling for any of our environments (development, production, staging, staging-dev). This is done in the angular.json file the same way the environment files are replaced for the Angular app .
Another approach that worked for us, was loading the environment variables only once, and retrieve them from that origin. As our app relies on Express for it's backend the used the Express env variable as:
import express from 'express';
const _app = express();
const _env = _app.get('env');
console.log(_env); // shows the right environment value set on NODE_ENV
To come to this conclusion we checked Express code for the env variable and it does use process.env.NODE_ENV internally.
Hope it helps. Best regards.
We had the same issue, we eventually used the cross-env package in our package.json:
"prodBuild": "cross-env NODE_ENV=production nx run api-server:build:production",
"prodServe": "cross-env NODE_ENV=production nx run api-server:serve:production"
process.env is indeed only available at run-time. What is probably happening is that you are not setting this value when running your application. Can I ask how you are running it?
As a trivial example
# The following will read the environment variables that are defined in your shell (run `printenv` to see what those are)
> node main.js
# this will have your variable set
> NODE_ENV=production node main.js
Of course you want to have it actually set in your environment when deploying the app rather then passing it in this way, but if you're doing it locally you can do it like this.
According to the React docs you can have development, test and production envs.
The value of NODE_ENV is set automatically to development (when using npm start), test (when using npm test) or production (when using npm build). Thus, from the point of view of create-react-app, there are only three environments.
I need to change root rest api urls based on how I am deployed.
e.g.
development: baseURL = 'http://localhost:3004';
test: baseURL = 'http://localhost:8080';
uat: baseURL = 'http://uat.api.azure.com:8080';
production: baseURL = 'http://my.cool.api.com';
How do I configure a UAT environment for react if it only caters for dev, test and prod?
What would my javascript, package.json and build commands look like to switch these values automatically?
Like John Ruddell wrote in the comments, we should still use NODE_ENV=production in a staging environment to keep it as close as prod as possible. But that doesn't help with our problem here.
The reason why NODE_ENV can't be used reliably is that most Node modules use NODE_ENV to adjust and optimize with sane defaults, like Express, React, Next, etc. Next even completely changes its features depending on the commonly used values development, test and production.
So the solution is to create our own variable, and how to do that depends on the project we're working on.
Additional environments with Create React App (CRA)
The documentation says:
Note: You must create custom environment variables beginning with REACT_APP_. Any other variables except NODE_ENV will be ignored to avoid accidentally exposing a private key on the machine that could have the same name.
It was discussed in an issue where Ian Schmitz says:
Instead you can create your own variable like REACT_APP_SERVER_URL which can have default values in dev and prod through the .env file if you'd like, then simply set that environment variable when building your app for staging like REACT_APP_SERVER_URL=... npm run build.
A common package that I use is cross-env so that anyone can run our npm scripts on any platform.
"scripts": {
"build:uat": "cross-env REACT_APP_SERVER_URL='http://uat.api.azure.com:8080' npm run build"
Any other JS project
If we're not bound to CRA, or have ejected, we can easily configure any number of environment configurations we'd like in a similar fashion.
Personally, I like dotenv-extended which offers validation for required variables and default values.
Similarly, in the package.json file:
"scripts": {
"build:uat": "cross-env APP_ENV=UAT npm run build"
Then, in an entry point node script (one of the first script loaded, e.g. required in a babel config):
const dotEnv = require('dotenv-extended');
// Import environment values from a .env.* file
const envFile = dotEnv.load({
path: `.env.${process.env.APP_ENV || 'local'}`,
defaults: 'build/env/.env.defaults',
schema: 'build/env/.env.schema',
errorOnMissing: true,
silent: false,
});
Then, as an example, a babel configuration file could use these like this:
const env = require('./build/env');
module.exports = {
plugins: [
['transform-define', env],
],
};
Runtime configuration
John Ruddell also mentioned that one can detect at runtime the domain the app is running off of.
function getApiUrl() {
const { href } = window.location;
// UAT
if (href.indexOf('https://my-uat-env.example.com') !== -1) {
return 'http://uat.api.azure.com:8080';
}
// PROD
if (href.indexOf('https://example.com') !== -1) {
return 'http://my.cool.api.com';
}
// Defaults to local
return 'http://localhost:3004';
}
This is quick and simple, works without changing the build/CI/CD pipeline at all. Though it has some downsides:
All the configuration is "leaked" in the final build,
It won't benefit from dead-code removal at minification time when using something like babel-plugin-transform-define or Webpack's DefinePlugin resulting in a slightly bigger file size.
Won't be available at compile time.
Trickier if using Server-Side Rendering (though not impossible)
To have multiple environments in a React.js application you can use this plugin
env-cmd from NPM
And after that Create the three files as per your need.
For example if you want to setup dev, stag and prod environments you can write your commands like this.
"start:dev": "env-cmd -f dev.env npm start", // dev env
"build:beta": "env-cmd -f stag.env npm run build", // beta env
"build": "react-scripts build", // prod env using .env file
I have been trying to get a streamline way of having different environment variables for local and production web apps, but I haven't come across the "ideal" solution yet.
There's the option of having a config.js file like so:
//config.js
{
"secretKey": "SDFDASFFSFD",
"facebook": {
"clientID": "EFGFDGBGDGFS",
"clientSecret": "EGDFNHFG"
}
}
And accessing via ES6 imports
Or using .env files like so:
SOME_KEY=someValue
HELLO=world
FACEBOOK_SECRET=435SDFSF5DZVD7S
And accessing the variables via process.env in the code using dotenv.
Obviously no matter what route you go down, the file will need to be omitted from version control which is fine. Each of these ways are great, but they only seem to work well for local development.
So how do you then have a separate file for a production environment? The dotenv docs say they strongly recommend against a .local.env and .prod.env situation.
Also, how is best to push to a remote server? I have my own server with Gulp tasks which run on a Git post-receive hook. How is best to pass up the production environment variables to here?
Thanks
You could have own config file for each environment:
- environments
- index.js
- deveplopment.json
- staging.json
- production.json
To use appropriate config file, run the app with required NODE_ENV:
NODE_ENV=production node index
In environments/index.js determinate the current NODE_ENV and use config:
process.env.NODE_ENV = process.env.NODE_ENV || 'development';
module.exports = require('./' + process.env.NODE_ENV);
If config file doesn't include secret info (apiKeys, etc), it can be pushed to repo. Otherwise add it to .gitignore and use environment variables on the server.
Note:
For advanced configuration use such packages as nconf.
It allows to create hierarchical node.js configuration with files, environment variables, command-line arguments, and atomic object merging.
Have you thought about having a keys.js file with a .gitignore on it?
I've used this in the past to use module.exports{} to get my variables usable but not going to version control for the security side of things!
I am trying to deploy my Meteor React app on Google's cloud but when I try deploying it, I get the error saying that MONGO_URL needs to be specified. I build my meteor app and cd to my bundle folder where I do gcloud app deploy. Here is my package.json
{
"private": true,
"scripts": {
"start": "node main.js",
"install": "(cd programs/server && npm install)"
},
"engines": {
"node": "6.6.0"
}
}
How can I find out my meteor mongo username and password. Running regular meteor did not ask me for my username and password. And here is my app.yaml
runtime: nodejs
env: flex
threadsafe: true
automatic_scaling:
max_num_instances: 1
env_variables:
MONGO_URL: 'mongodb://[user]:[pass]#[host]:[port]/[db]'
ROOT_URL: 'https://...'
METEOR_SETTINGS: '{}'
I don't know what to put for MONGO_URL and ROOT_URL if I am deploying on gcloud. Also I have settings file for my project. Should it go under METER_SETTINGS in app.yaml? I apologize for asking too many question but this is my first time dealing with gcloud :)
This question is a little old, but it's still getting some views from Google so let's answer by parts, first you need to understand how Meteor interacts with MongoDB in development and production. When you're coding your app, just executing meteor run does all the magic, because Meteor deploys an internal MongoDB. This is not recommended for real production usage and won't work well under any container based architecture (such as Docker, Google App Engine, Heroku etc.).
Given that, you'll need to deploy a separate instance in Google Compute Engine based on MongoDB. Google has them ready to launch in the Google Cloud Launcher, just search for "MongoDB".
I recommend the Bitnami's one, which is easier to configure if you're just beginning.
Google will create an instance automatically and you'll be given a root username and password, alongside a public IP address to connect to the instance.
Run the command below to access Mongo from a terminal:
# Use this template for the command
mongo "mongodb://root:PASSWORD#IP_ADDRESS/" --authenticationDatabase admin
# For example, with sample values
mongo "mongodb://root:8sdjkfh8876#127.0.0.1/" --authenticationDatabase admin
Now, create a new user for Meteor to connect on your newly created database. Never give it the root credentials, it won't work and it's not safe. For example, naming the database as myapp.
use myapp;
db.createUser({
user: "meteor_app",
pwd: "A_SECURE_PASSWORD",
roles: [ "readWrite", "dbAdmin" ]
})
Now, you exit this connection and test your new user.
mongo "mongodb://meteor_app:A_SECURE_PASSWORD#IP_ADDRESS/myapp"
If everything is OK, you now have your MONGO_URL.
# Put this in the app.yaml file, env variables sections
MONGO_URL: "mongodb://meteor_app:A_SECURE_PASSWORD#IP_ADDRESS/myapp"