How does Gatsby hide API-keys on the frontend - shopify

So, I'm struggling to understand how Gatsby works. I'm using the https://www.gatsbyjs.org/starters/AlexanderProd/gatsby-shopify-starter/ which uses a Gatsby plugin called gatsby-source-shopify. The plugin takes two params: shopName and accessToken. It looks like this in gatsby-config.js:
{
resolve: `gatsby-source-shopify`,
options: {
// The domain name of your Shopify shop. This is required.
shopName: process.env.SHOP_NAME,
// An API access token to your Shopify shop. This is required.
accessToken: process.env.SHOPIFY_ACCESS_TOKEN,
},
},
Will the access token be available for people to look at when I deploy the app? Do I need to use something like Serverless functions to hide my API keys, or is this fine. Any general explanation of how this works in Gatsby would be awesome.
Thanks Gatsby fam!

As the code shows, it uses process.env.SHOP_NAME where SHOP_NAMEis the name of the environment variable. Those files are declared at the root of the project using some naming such as .env.domain1.com. In this file, you can store any desired variable to use it in your Gatsby configurations. When dealing with delicate variables (API keys, tokens, passwords, etc) it's recommended to use that way and ignore all .env files in your .gitignore.
When you trigger a command in Gatsby, you can pass it some variables, for example:
"develop": "GATSBY_ACTIVE_ENV=domain1.com gatsby develop"
In this case, GATSBY_ACTIVE_ENV var will have domain1.com as a value. Then, in you gataby-config.js, when you can use environment variables (above module.exports):
require("dotenv").config({
path: `.env.${process.env.NODE_ENV}`,
})
Then, you can create an environment file such as .env.domain1.com in your root project and store any desired variable:
SHOP_NAME: 12345
Taking into account the code you've provided if you run develop (with all I've explained) command it will take SHOP_NAME as 12345.
So, answering your question, you won't have access to that tokens. You need to store them in your local machine and in your deploy server, not in your repository.
From Gatsby docs:
Please note that you shouldn’t commit .env.* files to your source
control and rather use options given by your Continuous Deployment
(CD) provider...
Edit: Thanks to #Hans Martin Henken for providing the following article about Gatsby security

Related

Pushwoosh how to export presets

In Pushwoosh I have to configure over 200 presets in 3 environments(test, UAT, and Production). Is there a way to export and import presets?
It would be too time-consuming if I have to manually create them in each environment.
There is a couple of ways to clone presets programmatically.
Open API
This way is preferrable if you'd like to clone presets across different accounts.
1.1. Obtain the list of presets via listPresets API
1.2. Filter the list (if needed)
1.3. For each preset that you'd like to clone, obtain preset information using getPreset API
1.4. Prepare mapping of properties as per the guide
1.5. Create new presets at target account using createPreset API
If your preferred scripting language is Python, you may use this library for easy access to these API methods.
Internal Browser API
If you want to simply clone presets between two apps/projects of the same account, you may opt to use Javascript macros from this Gist.
This is how you do it:
2.1. Log in to Pushwoosh account where you want to clone presets/events
2.2. Make sure that DESTINATION app has all platforms configured, that are selected in presets
2.3. Make sure the Max Presets limit of your account would allow the total number of presets to be created.
2.4. Open the Console of your browser where you logged in to your Pushwoosh account
Set up HOST variable to point to your dedicated server. E.g. if your dedicated server address is subdomain.pushwoosh.com, you should do the following:
type const HOST="subdomain"; and press Enter
If your account is on go.pushwoosh.com, set the HOST variable to "go".
2.5. Copy-paste contents of migrate-presets-events.js to Console and hit Enter.
2.6. Now launch command to migrate all presets from SRC to DST:
await migrate_presets('SRC_APP_CODE', 'DST_APP_CODE');
If either of methods looks challenging, feel free to contact our support for assistance: help#pushwoosh.com

VueJS 3 CLI environment variables secret isn't working

I'm new to vue .env. I looked everywhere for a straight answer till I got lost. According to VueJS documentation that if we have .env.local file that will be loaded in all cases but will be ignored by git which exactly what we want to hide secret API keys from the public. But it also says that if we add VUE_APP before the key name in .env.local that will make our key load to the public.
My question is. How to securely hide API key from the public and still be able to use it in production and in development without any security risks?
my .env.local file
VUE_APP_DEEPGRAM_KEY=some_API_key_that_is_secret
the above works if I log it to the console from my app. but if i removed VUE_APP It won't work so is it safe to leave it like this?
Anothe thing, in Laravel we used to save API keys in .env and refer to them from config file and then call them in app from config. So is Vue different? if not, then how to do the same here?
To answer my own question, documentation is actually pretty obvious but I got a bit confused. it simply has to start with VUE_APP_ for it to work in Vue CLI

How/Where to store sensitive information in .netCore project in Azure DevOps/Local

Shortly my scenario is to test a remote API if there was any changes in the called APIs, like some parameter removed or something like that.
To get this info I need to have a token.
My problem is, I can't store it in the Database and use windowsCredentials, because in the AzurePipeline the build agents has no access and connection to the Database. And if I pass the token through variables in the pipeline then I won't have the token when I run the code in local.
appSetting is stored in Git so it is not safe.
Any idea on this?
Thanks!
UserSecrets + Environment variables are the key here. Appsettings.json is for configuration that is non-sensitive, but there is a concept called user secrets (see link below) that will allow you to have stored an appsettings.json equivalent just on your machine and not in git. When specifying info in it it should override or add onto anything in your appsettings.json.
If that info is also needed for production, then environment variables should be used. Instead of a file, single configurations can be specified/overridden using environment variables.
This is all accomplished ONLY if the aspnet core web server configuration is setup to accept from all of these places. The default setup from the template should accomplish this but read the links below to make sure that your setup works.
All the configuration and best practices can be found here.
Non sensitive info/Defaults: appsettings.json
Sensitive info for devs/dev specific info: UserSecrets
Sensitive info for prod: Environment variables

VSTS: Different Config Files (WCF endpoint addresses) for different environments using RM

I have different projects that are consuming many WCF services. I am using VSTS to automate deployments. Those services target different URLs (endpoint addresses) based on the environment where they are going to be deployed.
I am trying to use web deploy with VSTS release management as suggested in this link:WebDeploy with VSTS, which proposes to create:
Parmeters.xml
Then, add new task "Replace Tokens" with the specified variable for each environment.
However, i don't guess this will work for me, because it generate tokens only for app settings keys (which is not my case).
Is there is a work around or any other suggestion that could help me to do the configuration part?
"Replace Tokens" task can works with any config file in your project and what content to be replaced is also controlled by you.
For example, if you want to replace a URL in "myconfig.config" file. You can set the URL in the config file to "#{targeturl}#", and add a "Replace Tokens" task in your definition with the following settings: (You can change the token prefix and suffix, but remember to update it accordingly in the config file since the task find the strings to replace base on it)
And then create a variable "targeturl" in the definition with the actual URL value:
Now, when you start the build/release, the string "#{targeturl}#" in "myconfig.config" file will be replaced with "www.test.com".

Cloudinary Invalid Cloudinary Config Provided

I am new to KeystoneJS and I am having a small problem concerning my deployment on Heroku.
This is my website: http://jeroendruwe.herokuapp.com/, when I navigate to the admin section (http://jeroendruwe.herokuapp.com/keystone/signin)
I get the Invalid Cloudinary Config Provided error
Papertrailapp log: http://pastebin.com/Yn8Pdttz
I've read the documentation (http://keystonejs.com/docs/configuration/#services-cloudinary). The weird thing is that when I try one of these (in keystone.js), the whole site stops working:
keystone.set('cloudinary config', { cloud_name: 'my-cloud', api_key: 'abc', api_secret: '123' });
// or
keystone.set('cloudinary config', 'cloudinary://api_key:api_secret#cloud_name' );
So what I've done at the moment is set the property in the keystone.init(...'cloudinary config': 'cloudinary://...'). I've also added the url to the CLOUDINARY_URL environment variable in the .env file
How can I fix this issue?
Can somebody also explain what the variables in the .env file do? There is 1 in the root and another one in the node_modules/dotenv folder, these files are not pushed to git so how do they get used?
Thanks in advance!
First, let me start by answering your last question first. The .env file is used by the dotenv module, which loads the variables/values in the .env file and makes them available to your application in process.env. Make sure you call the .load() method as early as possible in your code.
var dotenv = require('dotenv');
dotenv.load();
You should also know that Heroku has two other means to configure environment variables (See Configuration and Config Variables). One via your application dashboard and another via their CLI.
Using the Heroku Dashboard, just fill in the NEW_KEY and NEW_VALUE fields, then press Save.
Using the Heroku CLI, just use the heroku config:set command.
$ heroku config:set CLOUDINARY_URL=cloudinary://api_key:api_secret#cloud_name
Adding config vars and restarting myapp... done, v12
CLOUDINARY_URL: cloudinary://api_key:api_secret#cloud_name
If you're using Heroku, I suggest you use one of these to methods to set the CLOUDINARY_URL for your application in production.
Now back to your original question. This error typically means that there's something wrong with the Cloudinary configuration (i.e. it's either incorrect or completely missing). Without seeing the actual code that you're using it would be impossible to pinpoint the exact problem.
I'm going to assume that your replacing the api_key, api_secret and cloud_name with the actual values. That said, I would still double check to make sure those values are correct.
In my Heroku deployments, I use dovenv to set the environment variables in development, and use the either the Heroku Dashboard or CLI to set them in production.
If you're still having difficulties, please post the actual code your using (omitting your actual api key, of course), including the content of your .env file.