Cloudinary Invalid Cloudinary Config Provided - cloudinary

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.

Related

Nuxt JS - reading conf/env file in static site generation

My project with Nuxt JS is set with target:static and ssr: false.
This app need to connect to a local endpoint to retrieve some informations.
I have multiple endpoints and I need multiple instances of the app, every app must read only his endpoint.
The question is: how change the endpoint address for every app without rebuild everyone?
I tried with env file or a json file in the static folder (in order to have access to this file in the dist folder after the build process).
But if I modify the content of the env/json file in the dist folder and then reload the webpage (or also restart the web server that serve the dist folder), the app continue to use the original endpoint provided at the build time.
There is a way or I have to switch to server side rendering mode (which I would rather not use)?
Thank you!
When you use SSG, it will bundle your app at build time. Last time I checked, there was no hack regarding that. (I don't have the Github issue under my hand but it's a popular one)
And at the same time, I don't really see how it would be done since you want to mix something static and dynamic at the same time.
SSR is the only way here.
Otherwise, you may have some other logic to generate dynamic markup when updating your endpoints (not related to Nuxt) by fetching a remote endpoint I guess.
With the module nuxt content it's possible to create a folder "/content" in project directory and read json files from that directory.
After, when creating the dist with nuxt generate command, the "content" folder it's included in "_nuxt" folder of the dist and if you modify the content of the json file and refresh the webpage that read it, will take the new values.

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

Is there a way to have a generated nuxt app and only change the .env file in the server without having to regenerate the code?

The request is to edit the .env and the generated nuxt app to catch the changes, to have different variables for different servers, is that doable somehow?
As I know there is no way to change .env file without regenerating code
Therefor most developer use Docker to solve this problem:
https://jonathanmh.com/deploying-a-nuxt-js-app-with-docker/

How does Gatsby hide API-keys on the frontend

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

Prevent file differences between live and staging websites AND system scripts (PHP)

I'm trying to find a good way to maintain PHP configuration differences between a dev and live environment. I know how to handle differences when scripts are run by Apache (see below), but not when they are run on the command line, e.g. via cron.
Background info:
What do I mean by "configuration differences"? Like most code shops, we run a non-public 'staging' version of our website where we test code before it goes to the live website. We use Subversion and have the live website as 'Trunk' and 'Staging' as a branch. It makes life easier when code goes from staging to live if the repository version of the files have minimal differences. But obviously, some details need to be different, e.g. the DB connection details.
How configuration differences are solved with Apache
In PHP, we set branch specific variables as follows:
switch ($_SERVER['HTTP_HOST']) {
case 'ourstagingurl.com':
$dbPassword = "blahblah";
break;
default:
$dbPassword = "blahblah";
}
or we put the following in the .htaccess file relevant to the specific site:
php_value dbPassword "blahblah"
Why I can't resolve configuration differences using the CLI?
When a script is run on the CLI, there's no super globals such as $_SERVER. I could include a config file using a absolute path but how can I know whether the script is from live or staging? I could pass in a command line argument that specifies the environment but I was hoping there was a better way?
Hey, I work for a company with a similar setup. What I generally do is set up a scenerio where the staging and live servers both modify a common and generic config file. When the site is deployed on both the staging and live the information will be incorrect and will need to be modified once in each location. However, this will ONLY need to happen once because the parts you modify will be noted as modified by subversion and will not be overwritten by subversion in subsequent svn updates.
$host = isset( $_SERVER['HTTP_HOST'] ) ? $SERVER_['HTTP_HOST'] : php_uname('n');
switch ( $host )
{
case 'ourstagingurl.com':
$dbPassword = "blahblah";
break;
default:
$dbPassword = "blahblah";
}
If php version is => 5.3 then gethostname() could be used instead.
If live and staging are the same server (why don' t you use virtualisation?) then you'll probably have to resort to passing arguments to your scripts ie. call php script.php staging for staging and php script.php live for live site. BTW In case you wouldn' t know, the arguments are accessible using $argv in your PHP script -> http://www.php.net/manual/en/reserved.variables.argv.php.
Though maybe you could get part of the path of the file and use that as your "environment". ie. when file layout is /project/staging/script.php for staging and /project/live/script.php for live it should be easy to get the environment from the script itself using dirname(__FILE __) - extra space after FILE needs to be removed - and stripping the /project folder from it. Pretty stupid but it will work :p.
You can do as Jurassic suggested, or you can set an environment variable and read it in through $_ENV.
In some of my applications, I attempt to include a file that only exists to override values on the development server. I use the dreaded # operator, but you could do an is_file() as well.
#include 'includes/debug.php';
debug.php would attempt to set some variables:
define('DEBUG', true);
define('DB_PASSWORD', 'foobar');
I tell svn to ignore this file. It sticks around in my development checkout, and has a minimal impact on production.
More generally I use hostname checking as it works in both CLI and web apps, but you've stated you have both branches on the same box, so that's out.