Using dotenv .env config file correctly
lovegrovegeorge opened this issue · comments
Description
How the .env file and imports should be setup for the project correctly as currently the build is breaking.
Expected behavior
- add .env file with config in root
- npm install --save dotenv
- import dotenv using require('dotenv').config(); or ES6 syntax in index.js file
- consume using process.env.CONFIG_NAME across application
Actual behavior
Using the expected behaviour approach I get the above error. I've also tried both installing dotenv and not installing it (as ejecting the repository shows dotenv is already a dependency).
Environment
react-scripts@0.6.1
node - v6.6.0
npm - 3.10.8
Using a Chrome (53.0.2785.143) on a Mac.
I'm trying to get this working too, I don't think you are supposed to actually install dotenv. For some reason env variables are not being imported from my .env file though.... so I am having a similar problem.
@zackify Are you on windows?
@georgelovegrove @zackify
Please have a look at this, for adding env variables.
https://github.com/facebookincubator/create-react-app/blob/master/packages/react-scripts/template/README.md#adding-custom-environment-variables
No. mac os sierra.
On Thu, Oct 6, 2016 at 22:28 Amila Welihinda notifications@github.com
wrote:
@zackify https://github.com/zackify Are you on windows?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#865 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAbacK7VBi5QJtdlCEfjXgZ6LtcdiuYwks5qxa5ggaJpZM4KQK0_
.
Thanks but I have already. I have added the file. I'm using dotenv on other
projects and it works fine. In this case, I'm on the latest version of
create react app. Made a .env file at the root. Process.env is an empty
object in the app. Really weird for sure....
On Thu, Oct 6, 2016 at 22:29 Shriyans notifications@github.com wrote:
@georgelovegrove https://github.com/georgelovegrove @zackify
https://github.com/zackify
Please have a look at this,for adding env variables.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#865 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAbacLSpvpJBJEzMc7c2C42haipHxJqcks5qxa6XgaJpZM4KQK0_
.
@georgelovegrove @zackify Is your os sierra too ? i am unable to reproduce it.
Also to add one more thing , in your .env file , what are the names of env variables. You have to append REACT_APP_ to them , to make it work.
eg:
This works.
REACT_APP_SECRET=mySecret 👍
and this doesn't
SECRET=anotherSecret 👎
I'm on OS Sierra but @shrynx made me look closer at the information I read before. I missed the appending 'REACT_APP_' to the start of the key. That's a bit of a verbose pain to add that to every key, could that not be shortened or removed entirely in the scripts?
Closing now, thanks for help.
It is intentionally verbose. Otherwise there is a risk of accidentally exposing a private key on the machine that happens to have the same name.
@gaearon fair point, may be worth a one liner in the docs. p.s thanks for redux! aha
@georgelovegrove PRs are welcome to the docs 😉
But you know the right place to put it. We can polish the message later, PR is a start.
Haha! Knew there had to be something simple. Agree, it's a little confusing
especially if you are used to setting up env files yourself.
On Fri, Oct 7, 2016 at 06:53 Dan Abramov notifications@github.com wrote:
But you know the right place to put it. We can polish the message later,
PR is a start.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#865 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAbacMKHz45JK1x8FrRQDY0vVXV8U64Dks5qxiSrgaJpZM4KQK0_
.
It is intentionally verbose. Otherwise there is a risk of accidentally exposing a private key on the machine that happens to have the same name.
Can someone help me understand the security risks involved in having a sensitive value attached to process.env? It is my understanding that process.env won't be available during runtime.
If I understand that correctly, why is the code that exposes these variables so defensive? I guess what I'm looking for is a security use-case that would inform a design decision like this.
@wpcarro Say you were working on some other project and set an environment variable of SECRET=my-secret-token. If you then build your project that uses process.env.SECRET without specifying a new value, the app will then have my-secret-token baked into the source. This is now viewable by anyone with access to the built files (eg everyone if it's a public web app).
@cdriehuys thanks for the response. I still have a few questions regarding the security risks.
In the example you provided, isn't the only security offense including process.env.SECRET in the source code?
To me, it seems like including process.env.SECRET in any built source is a risk that CRA cannot really protect against. Is anything stopping someone from building process.env.REACT_APP_SECRET? Aren't the risks the same?
It's possible that I'm misunderstanding the problem, but if I'm not, this feels like CRA is creating the illusion of enhanced security without actually conferring the benefits. Would love to understand more though!
My understanding of it is that its more likely for someone to accidentally set the environment variable SECRET for a different project and accidentally include it than it is for them to set a variable prefixed with REACT_APP. The prefix provides an indication when setting it that "hey, this will probably get bundled in a publicly available build. I should be careful with the information I pass in."
@cdriehuys At this point I think we're on the same page then in terms of our understanding. I definitely agree that it's more likely for someone to set SECRET and include process.env.SECRET than it is to set REACT_APP_SECRET and include process.env.REACT_APP_SECRET...
I feel like the only security concern here is anytime a developer includes process.env.SOME_SECRET in the build. I don't think that prepending REACT_APP_ decreases these risks. I think it has the potential to introduce a false sense of security while introducing verboseness all for a small win.
@wpcarro the important bit is that the secret thing that gets included in the build is from some other unrelated project, that happens to be on the machine the build happens on. Like, that other project might set something like API_URL=internal:secretpassword@api.clients.com.
Meanwhile, the React project coincidentally also allows an API_URL to be set, coz sometimes you want corp.net/testapi/ instead of corp.net/api/, but this build it notices there's an API_URL env var and rolls it into the build, and the whole world gets to see your client's password is secretpassword. It was okay for the React dev to allow the API url into the built code – it was never supposed to include a password. The problem was just that an environment var from some other project used the same name. That's the risk the explicit prefix is avoiding.