I am building my web app in Next.js, and I have been doing some tests. What I am doing is to push my code to GitHub and from there deploy the project on to Vercel.
I am using Google APIs dependencies which require some Client ID and Client secret for me to be able to send emails using node-mailer from my client side to inbox (I'm doing this via a contact form).
However, on localhost everything is working fine but when I deploy onto Vercel, I am not able to make my contact form send mails (an issue that has to do with environment variables).
I tried Options A and B
Option A
Created a .env.local, added my variables there, then accessed them in next.config.js as shown in the code below (console log shows that I can access the variables anywhere on my app)
.env.local
env:{
CLIENT_URL:'vxcxsfddfdgd',
MAILING_SERVICE_CLIENT_ID:'1245785165455ghdgfhasbddahhhhhhhhm',
MAILING_SERVICE_CLIENT_SECRET:'Rdfvcnsf4263543624362536',
MAILING_SERVICE_REFRESH_TOKEN:'000000',
USER_EMAIL_ADDRESS:'yesyesyesyesyesyes#gmail.com',
}
next.config.js
module.exports = {
env:{
CLIENT_URL: process.env.CLIENT_URL,
MAILING_SERVICE_CLIENT_ID: process.env.MAILING_SERVICE_CLIENT_ID,
MAILING_SERVICE_CLIENT_SECRET: process.env.MAILING_SERVICE_CLIENT_SECRET,
MAILING_SERVICE_REFRESH_TOKEN: process.env.MAILING_SERVICE_REFRESH_TOKEN,
USER_EMAIL_ADDRESS: process.env.USER_EMAIL_ADDRESS,
}
}
If I do like Option A as per above, then send emails does not work on localhost neither does it work on Vercel.
Option B
I put my variables in next.config.js as below add the next.config.js to .gitignore then push to GitHub.
module.exports = {
env:{
CLIENT_URL:'http://localhost:3000',
MAILING_SERVICE_CLIENT_ID:'7777777777777777777777',
MAILING_SERVICE_CLIENT_SECRET:'R123456789',
MAILING_SERVICE_REFRESH_TOKEN:'1123456789',
USER_EMAIL_ADDRESS:'seiseibaba#gmail.com',
}
}
Option B works on localhost, but if I add environment variable on Vercel as shown in here then send mail does not work.
How can I set this to work properly for me?
Simply creating a .env.local (or .env) file with your environment variables should be enough to be picked by Next.js on the server. There's no need to add anything to your next.config.js.
# .env.local
CLIENT_URL=vxcxsfddfdgd
MAILING_SERVICE_CLIENT_ID=1245785165455ghdgfhasbddahhhhhhhhm
MAILING_SERVICE_CLIENT_SECRET=Rdfvcnsf4263543624362536
MAILING_SERVICE_REFRESH_TOKEN=000000
USER_EMAIL_ADDRESS=yesyesyesyesyesyes#gmail.com
However, if you need to expose a variable to the browser you have to prefix the variable with NEXT_PUBLIC_.
NEXT_PUBLIC_CLIENT_URL=vxcxsfddfdgd
This will be available on the browser using:
process.env.NEXT_PUBLIC_CLIENT_URL
For more details about environment variables in Next.js refer to https://nextjs.org/docs/basic-features/environment-variables.
The same principle applies to environment variables you create in Vercel (or any other hosting service), adding the prefix will make them available to the browser.
You can add environment variables in Vercel through the Environment Variables page of your Project Settings, that match the variables in your .env.local.
For more details about environment variables in Vercel refer to https://vercel.com/docs/concepts/projects/environment-variables.
Related
How do I get Firebase Auth to work on Heroku Deployment?
Auth works in MERN app's local development without any issues. All private information is stored in an .env file and then called in my react app with process.env.VARIABLE_NAME.
However, when I deploy to Heroku production and add the env files as shown here, I get the error: "Your API key is invalid, please check you have copied it correctly"
This is my deployed Heroku app: https://evening-fortress-01391.herokuapp.com/login
REACT_APP_FIREBASE_API_KEY=XXXXXXXX
REACT_APP_FIREBASE_AUTH_DOMAIN=XXXXXXXX
REACT_APP_FIREBASE_PROJECT_ID=XXXXXXXX
REACT_APP_FIREBASE_STORAGE_BUCKET=XXXXXXXX
REACT_APP_FIREBASE_MESSAGING_SENDER_ID=XXXXXXXX
REACT_APP_FIREBASE_APP_ID=XXXXXXXX
Also, running the command heroku config displays the inputted env variables in the terminal.
Any idea why Auth works locally but not in deployment? Thank you!
Answer because too long for a comment.
Sounds super hard to debug - also your app just shows a login and not the API key error =) To me it sounds like either just like it says, an incorrect API key or a formatting issue.
I would make a test config variable using the same characters as your API key like REACT_APP_FIREBASE_POTATO=p07470-test-example-foooobar and then in your frontend app just console.log("TEST" + process.env.REACT_APP_FIREBASE_POTATO);. Then publish that and check it in production.
This tests are the environment variables working at all and are there some character encoding issues (do you see the exact characters in the console as you should)
I am building my web app in Next.js, and I have been doing some tests. What I am doing is to push my code to GitHub and from there deploy the project on to Vercel.
I am using Google APIs dependencies which require some Client ID and Client secret for me to be able to send emails using node-mailer from my client side to inbox (I'm doing this via a contact form).
However, on localhost everything is working fine but when I deploy onto Vercel, I am not able to make my contact form send mails (an issue that has to do with environment variables).
I tried Options A and B
Option A
Created a .env.local, added my variables there, then accessed them in next.config.js as shown in the code below (console log shows that I can access the variables anywhere on my app)
.env.local
env:{
CLIENT_URL:'vxcxsfddfdgd',
MAILING_SERVICE_CLIENT_ID:'1245785165455ghdgfhasbddahhhhhhhhm',
MAILING_SERVICE_CLIENT_SECRET:'Rdfvcnsf4263543624362536',
MAILING_SERVICE_REFRESH_TOKEN:'000000',
USER_EMAIL_ADDRESS:'yesyesyesyesyesyes#gmail.com',
}
next.config.js
module.exports = {
env:{
CLIENT_URL: process.env.CLIENT_URL,
MAILING_SERVICE_CLIENT_ID: process.env.MAILING_SERVICE_CLIENT_ID,
MAILING_SERVICE_CLIENT_SECRET: process.env.MAILING_SERVICE_CLIENT_SECRET,
MAILING_SERVICE_REFRESH_TOKEN: process.env.MAILING_SERVICE_REFRESH_TOKEN,
USER_EMAIL_ADDRESS: process.env.USER_EMAIL_ADDRESS,
}
}
If I do like Option A as per above, then send emails does not work on localhost neither does it work on Vercel.
Option B
I put my variables in next.config.js as below add the next.config.js to .gitignore then push to GitHub.
module.exports = {
env:{
CLIENT_URL:'http://localhost:3000',
MAILING_SERVICE_CLIENT_ID:'7777777777777777777777',
MAILING_SERVICE_CLIENT_SECRET:'R123456789',
MAILING_SERVICE_REFRESH_TOKEN:'1123456789',
USER_EMAIL_ADDRESS:'seiseibaba#gmail.com',
}
}
Option B works on localhost, but if I add environment variable on Vercel as shown in here then send mail does not work.
How can I set this to work properly for me?
Simply creating a .env.local (or .env) file with your environment variables should be enough to be picked by Next.js on the server. There's no need to add anything to your next.config.js.
# .env.local
CLIENT_URL=vxcxsfddfdgd
MAILING_SERVICE_CLIENT_ID=1245785165455ghdgfhasbddahhhhhhhhm
MAILING_SERVICE_CLIENT_SECRET=Rdfvcnsf4263543624362536
MAILING_SERVICE_REFRESH_TOKEN=000000
USER_EMAIL_ADDRESS=yesyesyesyesyesyes#gmail.com
However, if you need to expose a variable to the browser you have to prefix the variable with NEXT_PUBLIC_.
NEXT_PUBLIC_CLIENT_URL=vxcxsfddfdgd
This will be available on the browser using:
process.env.NEXT_PUBLIC_CLIENT_URL
For more details about environment variables in Next.js refer to https://nextjs.org/docs/basic-features/environment-variables.
The same principle applies to environment variables you create in Vercel (or any other hosting service), adding the prefix will make them available to the browser.
You can add environment variables in Vercel through the Environment Variables page of your Project Settings, that match the variables in your .env.local.
For more details about environment variables in Vercel refer to https://vercel.com/docs/concepts/projects/environment-variables.
I am running puppeteer on a docker container in headless mode to test our website. The first page is the login page. The puppeteer script and docker files are stored in an internal git repo. What is a good way of securely storing the login credentials?
Obviously not as a file in the fit repo. Docker secrets is an option, what are some other options? I need puppeteer to read them without any user intervention.
You can pass the credentials as environment variables to your docker container. The following line starts the docker container and passes the variables LOGIN_USER and LOGIN_PASSWORD from your host to your docker environment. That way, you specify them as environment variables inside your host system, but you do specify them inside your code or repository.
Starting Docker
docker run -e LOGIN_USER LOGIN_PASSWORD [...]
Inside the container
Inside your container, you then use the variable by accessing process.env.LOGIN_USER and process.env.LOGIN_PASSWORD like this (example using page.type):
page.type('#input-field', process.env.LOGIN_USER);
Setting the environment variables
There are multiple options to set the environment variables. You can either set the permanently (in case you want to run multiple docker containers) or only for a single command. Check out this answer on askubuntu for more information.
My Node.js Express application runs in AWS Beanstalk. I've created three Beanstalk Environments for my application, namely:
DEV (Development)
UAT (User Acceptance Testing)
PROD (Production)
Dependent upon the environment my application is running in I would like to connect to different databases and use different cascading style sheets.
What is the best practice for figuring out in which AWS Beanstalk Environment my Node.js application is currently running?
I get the impression I should be using Beanstalk Environment Tags, but I've not been able to figure out how to access them via my Node.js application.
That's correct, use the environment variables you have configured from the Beanstalk console to let the instance of the application know which environment it is running in. You don't get that many options in a node beanstalk app, but if you say only want to pass a db connection string and a css path, you could do that with PARAM1 and PARAM2, then access these from within your app with
process.env.PARAM1 & process.env.PARAM2
(I've usually pushed these in to more appropriate names/places on application bootstrap).
Your other option is just to pass in some soft of 'env' variable in PARAM1, then have your app work out what to do with your various configurations (but this adds another hidden layer of config into your application).
I'm really enjoying learning about web development with Parse.com. I have a cloud app that serves jade templates and a few cloud functions that I'd like to call from .js in the browser.
I'm trying to setup for development and production using the parse docs here, but I've become confused. It's my understanding that I'll have one source tree on my development machine, but two parse applications that I'll deploy to alternatively as development and production.
It seems using the command line parse add <alias> will add credentials to my config/global.json file, but what about my statically served .js files that need to make cloud calls? They start out:
Parse.$ = jQuery;
Parse.initialize("my app id", "my app js key");
If I have only one code repository, I'll have to touch these keys before I deploy to production. That can't be right, can it? If I forget, I'll deploy a broken app. Am I mixed up, or is this just something I must deal with?
For a given session you only need to initialize Parse once. This means that you can do this when the browser loads from a single location.
You could create some sort of build script that modifies the keys.
Alternatively, on load, make a call to a seperate service which holds your keys and which returns the correct key depending on your environment.
In case anyone else has this problem, here's what I did (thanks to #Kenneth for suggesting). The script first checks to see if git has any un-staged changes. It refuses to run unless I've checked in all the changes.
Then it replaces all my dev ids/keys in .js files with production versions, deploys to my parse production app and finally restores .js files to contain their development keys...
#!/bin/bash
if git diff-index --quiet HEAD --; then
echo 'Replacing app id and js keys with production keys'
sed -i '' 's/my-development-app-id/my-production-app-id/g' ./public/*.js
sed -i '' 's/my-development-js-key/my-production-js-key/g' ./public/*.js
parse deploy production
echo 'Changing back to development keys'
git checkout *.js
else
echo 'Must commit all changes before deploying to production'
fi
Similarly, to separate our environments we deployed a Parse app for each one needed (say dev, qa, prod) and used the different resulting urls (the subdomain, but really any different part can do) to tell them apart and discover our environment in the code. We then stored the environment in an attribute.
var APP_ID, JS_KEY;
switch(location.host.split(".")[0]){ //Figure out environment off of the url (subdomain here)
case 'myappprod': //ex: myappprod.parseapp.com
MyApp.env = 'prod'
APP_ID = 'theprodappid';
JS_KEY = 'theprodjskey';
break;
case 'myappqa':
MyApp.env = 'qa'
APP_ID = 'theqaappid';
JS_KEY = 'theqajskey';
break;
default: //otherwise dev
MyApp.env = 'dev'
APP_ID = 'thedevappid';
JS_KEY = 'thedevjskey';
break;
}
You can also hint at the environment (app) you want to use in your local setup using this same technique. Just have the virtual host you use with your web server match all three local urls. For example, with nginx:
server_name myappdev.parseapp.dev myappqa.parseapp.dev myappprod.parseapp.dev;