keyFilename makes 12-factor app style deployment difficult

[hulbert]

I'm trying to use cloud storage which the documentation says I should initialize as such:

var gcloud = require('gcloud'),
    bucket = new gcloud.storage.Bucket({
        bucketName: YOUR_BUCKET_NAME,
        keyFilename: '/path/to/the/key.json'
    });

I dug into the code and this keyFilename option seems to be the only way to specify this required info, and it expects a filepath string. This makes storing the key's JSON as an environmental variable pretty complicated since I'd have to write the env value to a file, then pass the path to gcloud.

This seems to be a similar issue someone faced with Google APIs, a key file, and Heroku: http://ar.zu.my/how-to-store-private-key-files-in-heroku/

As he outlines, it seems there are four options, none super simple:

1. Include the private key in my git repository.
2. Store it in S3, and pull it when needed.
3. Use custom build-pack which will include the key.
4. Store it as config vars.

Even just having the option to pass this information in as a Javascript object (which makes sense for a node library) would be nice.

[rakyll]

We should never assume that key file will be read from disk. We should require it to be passed as a plain object. Any other opinions?

[silvolu]

I would add a key option to pass the object, but keep the keyFilename is as well.
Some people like the 'download the key and pass the path to the constructor'™ approach, mostly in the getting started experience context.

[rakyll]

SGTM as we discussed offline.

[ryanseys]

Yes, both options is best. keyFilename: 'path/goes/here.json' should more or less just be an alias for key: require('path/goes/here.json') where key accepts a plain JavaScript object.

[rakyll]

keyFilename should work the way it works (without require), otherwise it becomes impossible to specify relative paths to keyFilename. See 7641028.

[ryanseys]

Interesting... I've never had issues with relative paths + require but I've never pushed it to its limits either. 😄

fs.readFile is definitely better anyway because it's async and won't automagically cache. 👍

[hulbert]

Just an end-user perspective/question, is the entire JSON really needed or is it just using the private_key value? If you were to add a key option I would potentially be confused if this is to the whole object or just the value specified for the key private_key in the downloaded JSON file.

This confusion might be worsened in my example of using environmental variables as I would likely break the JSON file into four ENV variables like so:

declared environmental vars:

GOOGLE_CLOUD_private_key_id=value
GOOGLE_CLOUD_private_key=value
GOOGLE_CLOUD_client_email=value
GOOGLE_CLOUD_client_id=value
GOOGLE_CLOUD_type=value

Initializing gcloud-node:

var gcloud = require('gcloud'),
    bucket = new gcloud.storage.Bucket({
        bucketName: YOUR_BUCKET_NAME,
        key: {
            "private_key_id": process.env.GOOGLE_CLOUD_private_key_id,
            "private_key": process.env.GOOGLE_CLOUD_private_key,
            "client_email": process.env.GOOGLE_CLOUD_client_email,
            "client_id": process.env.GOOGLE_CLOUD_client_id,
            "type": process.env.GOOGLE_CLOUD_type
        }
    });

[rakyll]

We can rename the key to credentials which is basically what Connection object is doing at the moment. It's reading the file from keyFilename, parse and set it to Connection.prototype.credentials.

Btw, you only need to provide private_key and client_email.

var gcloud = require('gcloud'),
    bucket = new gcloud.storage.Bucket({
        bucketName: YOUR_BUCKET_NAME,
        credentials: {
            "private_key": process.env.GOOGLE_CLOUD_private_key,
            "client_email": process.env.GOOGLE_CLOUD_client_email,
        }
    });

[hulbert]

@rakyll 👍 your example would address my original issue