It is well known that react environment variables are embedded in the build and should not contain secrets.
If they are embedded in a build, how can you access them when you load the production application on a browser?
Found it, you have to look at the webpacked version. Harder to do if mangled, but not impossible.
I have an app written in JS,HTML and CSS which uses an API KEY. I have used environment variables locally to use API KEY. I have deployed it to heroku and while pushing to gitlab, I have added .env to gitignore and now after deployment, map is not visible because it can not access API KEY for maps.
I want to ask how to use environment variables in production (in Heroku deployment)?
You can either use their online dashboard or the CLI to add env vars.
See their docs here:
https://devcenter.heroku.com/articles/config-vars#managing-config-vars
So i have a static Webpage which uses some API. There's app.js file that has API key in it stored in an object property.I need to hide it using Netlify dev. How do I do that? How do I use Netlify dev tools in native js? I most probably need node js installed as well but this topic is not entirely clear to me... Could someone make a step by step tutorial for me?
If it's a static site, it won't be able to directly access the hidden netlify env variables.
If you are hosting the app.js file along with your static site then it will be easy for someone to browse to it and see the API key you are trying to hide.
One solution though is to define a Netlify Function that does the API call, and then the JS in your static site can call that function.
Your Netlify Function will be effectively a backend for your app, and can access the ENV variables you set in the Netlify UI, via process.env.
See this tutorial for a step-by-step guide.
Update re the new gatsby-build information in comments.
You can put variables in a git-ignored .env file, which means they will not end up on git, but will still get pulled in and included in the gatsby production code, which will be visible to the client, so isn't recommended for API access keys. Ideally you should connect via a backend to secure those keys, as in the above original answer.
However, instead of using a .env file, if you are using the Netlify Dev CLI then this will automatically pull down any env vars you have set in the online Netlify settings, and allow you to use those in your local environment.
From the cli docs:
Netlify Dev brings the functionality of your Netlify production environment directly to your local machine. This includes custom headers/redirects and environment variables.
I've created a javascript script that will get information from this api. I'm trying to set this up inside of a google cloud function. I understand how you "require" or "import" a reference normally inside of a google cloud function, and even that you can make reference to a local file. When i downloaded the api.js from the source and try to reference it, i get "bomgarState is undefined" where bomgarState is the reference that i need. I understand that it is looking for a json when an api is being defined but i need to use the api.js. I know that this code can work,when you run this in collaboration with an html that sources said api, i have no problems. I have tried many different solutions such as "require(./api.js)", getting from url, and much more but am unsure if this is something that is supported at this point.
TLDR: can't make reference or source a javascript api inside of google cloud functions, had been sourcing using html, now that we moved to google cloud functions can't figure out how to make reference.
For you to import dependencies and libraries to your Cloud Functions, there are some available options that you can take with JavaScript, but only while using Node.js - without Node it's not possible.
For example, as the documentation Specifying dependencies in Node.js indicates:
A function is allowed to use external Node.js modules as well as local data. Dependencies in Node.js are managed with npm and expressed in a metadata file called package.json.
So, you can use with Node.js the npm to import your dependencies to your Cloud Functions.
Other options are indicated in the following posts from the Community - that I would recommend you to take a look at it - one, for example, would be using the 'gcloud' command to deploy your function. This way, it would upload and deploy with all files from your directory.
Google Cloud Functions include private library
How do I structure Cloud Functions for Firebase to deploy multiple functions from multiple files?
I hope these articles help you, since they indicate the only available options, unfortunately, to upload dependencies on your Cloud Functions.
I just started learning JavaScript / node.js (a gentle introduction to back-end webdev), and thus I am completely green in the subject.
A few days ago I was reading a tutorial from which I learned to keep my confidential data (like passwords) in a config.json file.
Today I have discovered (by a chance) .env file, and the more I learn about it, it seems, the more people are using it to actually store passwords.
So when should I use .env and when should I use config.json?
The Question
When should .env be used over config.json and for what?
The answer
This is a rather difficult answer. On the one hand, you should only really ever use either of these tools while in development. This means that when in a production or prod-like environment, you would add these variables directly to the environment:
NODE_ENV=development node ./sample.js --mongodb:host "dharma.mongohq.com" --mongodb:port 10065
There is no real clear winner over the other per se as they are both helpful in different ways. You can have nested data with config.json, but on the other hand, you can also have a cleaner data structure with .env
Some thing also to note is that you never want to commit these files to source control (git, svc etc).
On the other hand, these tools make it very easy for beginners to get started quickly without having to worry about how to set the environment variables and the differences between a windows environment and a linux one.
All in all, I'd say its really up to the developer.
.env files are generally used to store information related to the particular deployment environment, while config.json files might be used to store data particular to the application as a whole.
either approach works, and whether or not your config files are stored in your repository is more a function of whether the data needs to be confidential.
This largely comes down to personal preference and the conventions of the frameworks you're using. They're just different formats for storing the same kind of information.
Some example config file formats:
.env
*.yml (YAML files)
*.ini (normally Windows-only)
*.json
At the end of the day, they all accomplish the same purpose: providing your application with environment-specific information (credentials, file paths, connection strings, etc.). Choose the format which best fits your choice of framework.
I think it's really up to you, the important thing to remember is why you're using this approach. The idea is to save your sensitive data in a file that doesn't get pushed to source control or any other place other than your local environment - this keeps the data safer. Then when you're ready to deploy to a remote server somewhere, you need to manually insert those values into that environment.
I generally use .env because the syntax for getting data from a .env file is supported in many remote environments - like heroku. When I deploy an app to heroku, I can go into the settings of the app and put in the environment variables using the heroku dashboard UI - I don't have to figure out how to get a json file manually created, etc... (maybe there are other workarounds). After the variables are in place, I just use process.env.variableName to access the data.
Statistically comparing the two NPM packages (along with other similar solutions) might be the best way to decide for yourself.
At the time of this writing, dotenv is a much smaller package with greater support (actual contributors aside, only deduced by the number of remaining issues and immense popularity). It's also newer by 2.5 years and, if fanfare is important to you, has twice as many stars.
If you are targeting deployment of your application in Docker, then .env is 100% the way to go. The ability to use nested data in config.json is great, but you'll be looking at some PITA when you need to migrate that data to a .env to make deployment with Docker work. docker build and docker-compose both are designed to use .env natively, so if you start with that then it will facilitate a smooth path to "Dockerizing" your application.
I am currently porting an application to run in Docker which was written with no such forethought, and it is quite painful... lots of refactoring, and only for the nested stuff. The basic key:value properties are easy to migrate to a .env:
~$ cat config.json
{
"PROTOCOL": "https",
"HOST": "example.com",
"PORT": 443
}
...
~$ cat .env
PROTOCOL="https"
HOST="example.com"
PORT=443
I prefer json because typescript can infer type from it, this is not possible with env file