Blah blah blah... Don't use client tech to secure yourself. Use client tech with vendor lock in.
Edit: imho you should use a separate server based application and pass a short lived token through to your live app. This doesn't need to be something with vendor lock in. The client app I'm working on now gets 3 values injected at deploy. LoginUtl. LogoutUrl and optionally manage users url.
It's meant to be integrated into different systems and works fine standing alone. The token after auth is sent with every API request and no secrets leaped to the client build.
Awesome reply! I'll have to look into that. I know this may be common knowledge to most, but there is some confusing information out there. Some of the common google search returns still suggest using .env files and if you don't read carefully, you may be inclined to use .env when deploying your react app. I wanted to find out why this isn't safe and tried to clearly explain it.
This is an aggregation of several different sources that I used to make a couple API calls. Having all this information in one place will hopefully make someone's life a littler easier, I'm still a newb and I would have loved to be able to follow something like this from the beginning.
I can understand that... I actually do use .env files, but the front end only uses them for the build/dev server to inject the 3 values... for the most part, I only use them for dev, and in the .gitignore so they don't get added. I then inject the necessary environment variables into the CI/CD for build and/or deploy environments. My front end usually has a limited number of them.
And you are right, it's too easy to accidentally inject unexpected values into a build. If you stick to just what you intend to inject such as with process.env.VARNAME in the webpack config, or in a separately loaded JS file that gets injected into the client.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Blah blah blah... Don't use client tech to secure yourself. Use client tech with vendor lock in.
Edit: imho you should use a separate server based application and pass a short lived token through to your live app. This doesn't need to be something with vendor lock in. The client app I'm working on now gets 3 values injected at deploy. LoginUtl. LogoutUrl and optionally manage users url.
It's meant to be integrated into different systems and works fine standing alone. The token after auth is sent with every API request and no secrets leaped to the client build.
An API gateway, imho, is the best way to roll
Awesome reply! I'll have to look into that. I know this may be common knowledge to most, but there is some confusing information out there. Some of the common google search returns still suggest using .env files and if you don't read carefully, you may be inclined to use .env when deploying your react app. I wanted to find out why this isn't safe and tried to clearly explain it.
This is an aggregation of several different sources that I used to make a couple API calls. Having all this information in one place will hopefully make someone's life a littler easier, I'm still a newb and I would have loved to be able to follow something like this from the beginning.
I can understand that... I actually do use .env files, but the front end only uses them for the build/dev server to inject the 3 values... for the most part, I only use them for dev, and in the .gitignore so they don't get added. I then inject the necessary environment variables into the CI/CD for build and/or deploy environments. My front end usually has a limited number of them.
And you are right, it's too easy to accidentally inject unexpected values into a build. If you stick to just what you intend to inject such as with process.env.VARNAME in the webpack config, or in a separately loaded JS file that gets injected into the client.