Meteor: how to load different files based on CLI parameter? - meteor

In my Meteor (1.2) app I've separated files for development and production
e.g.
client/lib/appVars.config.PROD.js
client/lib/appVars.config.CONFIG.js
Ideally the "twin" files have the same variables, functions etc. with little differences but (global) variables and functions which are common to debug and production have the same name.
Is there a way to call meteor run with a command line parameter DEBUG_MODE = true | false so that I cad load either one or the other file, depending on the current mode (debug, production)?

Set different environmental variables and run via CLI with meteor run --settings settings.json
Then you just need a development and production (and staging?) settings.json
Example of a settings file:
{
"awsBucket": "my-example-staging",
"awsAccessKeyId": "AABBCCddEEff12123131",
"awsSecretKey": "AABBCCddEEff12123131+AABBCCddEEff12123131",
"public": {
"awsBucketUrl": "https://my-meteor-example.s3.amazonaws.com",
"environment": "staging"
},
"googleApiKey": "AABBCCddEEff12123131"
}
EDIT ADD:
To access your environmental keys, just select
Meteor.settings.awsBucket
Security Update (thanks Dave Weldon)
See https://docs.meteor.com/#/full/structuringyourapp
Re production vs development, you should have two settings.json files, the standard one for production (.config/settings.json) and a development one (.config/development/config.json) and when you boot outside of production you boot meteor --settings .config/development/settings.json
Re client side, note that if you make the key public e.g.
{
"service_id":"...",
"service_secret":"...",
"public":{
"service_name":"..."
}
}
Then only Meteor.settings.public.service_name will be accessible on the client

Related

How do I deploy Cloud Functions while ignoring existing functions?

Say I have the following four functions in my Firebase projects:
openDoor(europe-west1)
closeDoor(europe-west1)
openWindow(europe-west1)
closeWindow(europe-west1)
Now, these functions live in two separate Node packages, i.e. one that contains openDoor and closeDoor and another one that contains openWindow and closeWindow.
Error
If I try to run firebase deploy from the package with the door functions, the following error will be thrown (in non-interactive mode):
Error: The following functions are found in your project but do not exist in your local source code:
openWindow(europe-west1)
closeWindow(europe-west1)
This is a problem because it will cancel any CD workflow that tries to deploy these functions.
Force delete
There is an option to force-delete any existing functions:
-f, --force delete Cloud Functions missing from the current
working directory without confirmation
However, I want the opposite. I want to keep all existing functions.
Theoretical workaround
There is one workaround that I found would work in theory, which is:
yes N | firebase deploy --interactive
Piping N into the interactive deploy command, which will answer N to the deletion prompt:
The following functions are found in your project but do not exist in your local source code:
openWindow(europe-west1)
closeWindow(europe-west1)
If you are renaming a function or changing its region, it is recommended that you create the new function first before deleting the old one to prevent event loss. For more info, visit https://firebase.google.com/docs/functions/manage-functions#modify
? Would you like to proceed with deletion? Selecting no will continue the rest of the deployments. (y/N)
The problem now is that I am using https://github.com/w9jds/firebase-action to deploy the functions, which means that I need to have a built-in Firebase solution.
You can make use of the new codebases feature in Firebase.
By specifying a codebase in your firebase.json functions configuration, this problem is solved. The Firebase CLI will no longer prompt you to delete other functions as it only considers the functions of the same codebase.
If your firebase.json previously looked like this:
{
"functions": {
"source": "cloud_functions",
"ignore": [...],
"predeploy": [...],
"postdeploy": [...]
}
}
You only need to add "codebase": "<name>" to the config:
{
"functions": {
"source": "cloud_functions",
"codebase": "window",
"ignore": [...],
"predeploy": [...],
"postdeploy": [...]
}
}
The deploy will now look like this:
i functions: updating Node.js 16 function window:openWindow(europe-west1)...
i functions: updating Node.js 16 function window:closeWindow(europe-west1)...
Note that the actual function name does not change, i.e. the function will still only be called openWindow (without the prefix) in the Firebase / Google Cloud Console. So this is basically the perfect solution to the problem.
Alternatively, you can also specify the function names when performing deployment.
firebase deploy --only functions:openDoor,functions:closeDoor

Firebase CLI suddenly ignoring environment variables on Functions deployment

I have a Firebase code project with Functions meant to be deployed to multiple Firebase projects over multiple regions.
I used to set the deployment region like this:
return functions
.region(process.env.REGION)
// ...
and used this command to deploy:
$ REGION=us-central1 firebase deploy --only functions
it worked like a charm until recently. Now it seems to completely ignore REGION=us-central1 even if I export it before I run firebase deploy.
EDIT 2022-06-13 - Possible solution
I changed the code to dump the contents of process.env to a file during deployment. This is what I got:
{
"FIREBASE_CONFIG": "{\"projectId\":\"REDACTED\",\"storageBucket\":\"REDACTED.appspot.com\",\"locationId\":\"us-central\"}",
"GCLOUD_PROJECT": "REDACTED",
"CLOUD_RUNTIME_CONFIG": "{REDACTED}",
"__CF_USER_TEXT_ENCODING": "REDACTED"
}
so definitely is not the same list of variables I have in my local environment.
I could use the locationId from FIREBASE_CONFIG to get the target location, or CLOUD_RUNTIME_CONFIG (it contains the dump of the functions .config() object, so I could set the target there).
I also believe that I could use the .env and .env.{project alias or ID} files and their contents would be available in process.env at deployment time.
As per Osvaldo López's suggestion, here are some other details:
Running on MacOS
No errors are reported
No recent changes to the CLI
Any input would be very welcome! Thanks.

Auth0 and Next.js deployed to Vercel: Location header error

I started with this sample repo: https://github.com/vercel/next.js/tree/canary/examples/auth0
My current repo: https://github.com/rebeccapeltz/next-auth-app-1
Login/Logout work fine locally. When I deploy to Vercel and logout I get this message in the browser:
Invalid character in header content ["Location"]
I've double checked the Auth0 env variables and they seem correct. Login works fine on Vercel. Can't figure out how to troubleshoot the header Location value that is causing the problem.
Nothing much going on yet and easy to reproduce: https://next-auth-app-1.now.sh/
Solved this by removing all env variables added to the Vercel online application settings. Then added the secrets using the now CLI now secrets add and deployed the app by setting up other env variables in now.json and using now --prod. Working OK now. For further external env secrets and references, I'm wondering if t's better to add them via now.json or to use the online settings GUI. One thing that wasn't clear is that when you add variables with now add secrets you need to prefix the value in the now.json with #. Kind of like accessing bash env variables with $. So after adding secrets my now.json looks like this
{
"build": {
"env": {
"AUTH0_DOMAIN": "<name of auth0 domain>",
"AUTH0_CLIENT_ID": "<what you get from auth0>",
"AUTH0_CLIENT_SECRET": "#auth0_client_secret",
"REDIRECT_URI": "<name of vercel app or domain name>/api/callback",
"POST_LOGOUT_REDIRECT_URI": "<name of vercel app>/",
"SESSION_COOKIE_SECRET": "#session_cookie_secret"
}
}
}
Should you add all env using secrets add and then just reference by name in the now.json? not sure.

Where to put secret keys in Netlify? [duplicate]

I'm trying to set an environment variable for an API key that I don't want in my code. My source javascript looks something like this :
.get(`http://api-url-and-parameters&api-key=${process.env.API_KEY}`)
I'm using webpack and the package dotenv-webpack https://www.npmjs.com/package/dotenv-webpack to set API_KEY in a gitignored .env file and it's all running fine on my local. I'd like to also be able to set that variable when deploying through Netlify, I've tried adding it through to GUI to the 'build environment variables', and also to set it directly in the build command, but without success.
Any idea what might be the issue ?
WARNING: If this is a secret key, you will not want to expose this environment variable value in any bundle that gets returned to the client. It should only be used by your build scripts to be used to create your content during build.
Issue
dotenv-webpack expects there to be a .env file to load in your variables during the webpack build of your bundle. When the repository is checked out by Netlify, the .env does not exist because for good reason it is in .gitignore.
Solution
Store your API_KEY in the Netlify build environment variables and build the .env using a script prior to running the build command.
scripts/create-env.js
const fs = require('fs')
fs.writeFileSync('./.env', `API_KEY=${process.env.API_KEY}\n`)
Run the script as part of your build
node ./scripts/create-env.js && <your_existing_webpack_build_command>
Caveats & Recommendations
Do not use this method with a public facing repository [open] because any PR or branch deploy could create a simple script into your code to expose the API_KEY
The example script above is for simplicity so, make any script you use be able to error out with a code other than 0 so if the script fails the deploy will fail.
You can set Dotenv-webpack to load system environment variables as well as those you have declared in your .env file by doing the following:
plugins: [
new Dotenv({
systemvars: true
})
]
I.e Setting the systemvars attribute of your webpack dotenv plugin to true.
Note that system environment variables with the same name will overwrite those defined in your .env file.
Source: https://www.npmjs.com/package/dotenv-webpack#properties
if you go to corresponding site's settings in Netlify, under build&deploy you can find a section called environment variables you can easily add your environment variables from there. if you add MY_API_KEY variable to environment variables you will be able to access it inside your project via process.env.MY_API_KEY.
If you're using Nuxt JS there is a more "straight forward" approach.
Just edit the nuxt.config.js like so:
module.exports = {
env: {
GOOGLE_API_KEY: process.env.GOOGLE_API_KEY
},
// ...
Then add the GOOGLE_API_KEY to Netlify through the build environment variables as usual.
Credit goes to yann-linn and his answer on github.
What you can also do is also to define a global constant in Webpack. Netlify environment variables defined in UI will work with it. You don't need dotenv or dotenv-webpack.
webpack.config.js
const webpack = require("webpack");
module.exports = {
plugins: [
new webpack.DefinePlugin({
"process.env.API_KEY": JSON.stringify(process.env.API_KEY)
}),
]
}
However again, of course you shouldn't do it just inputting enviornmental variables in the frontend if your API key is confidential and project public. The API key will appear in the source code of the website and will be easily accessible for everyone visiting it. Lambda function would be a better option.
You can use the Netlify's config file also ...
You can find documentation here.
Also i wanted to have the same ENV variables with with different values per branch/environment.
This workaround worked for me:
Create a netlify.toml file like:
[build]
NUXT_ENV_BASE_API = "/api"
NUXT_ENV_HOST_DOMAIN = "https://your-domain.gr"
[context.branch-deploy]
environment = { NUXT_ENV_BASE_API = "/dev-api", NUXT_ENV_HOST_DOMAIN = "https://dev.your-domain.gr" }
[context.production]
environment = { NUXT_ENV_BASE_API = "/api", NUXT_ENV_HOST_DOMAIN = "https://your-domain.gr" }
And deploy in Netlify ...

How to set arbitrary environment upon starting Meteor?

So, lets say I have 4 environments
Local
Stage
Preprod
Prod
I want to set up a flag on start of local so that I can identify whether it is local or not.
I am aware of isDevelopment, but that only differentiates between prod and any development environment.
What I imagine is starting Meteor something like
meteor --local
and then having access to a global variable isLocal set to true.
One way of doing this would be to create multiple settings files.
E.g.
settings-local.json
{
local: true,
}
settings-stage.json:
{
stage: true
}
All you need to do then is start meteor using whichever settings file you wish to use:
meteor --settings settings-stage.json
Then in your code you can test against these
if (Meteor.settings.stage) { //do something }

Resources