Overriding volume settings is very cumbersome

[timkelty]

If you're configuring AWS or something with API secrets and you want it kept out of the DB (as it is stored unencypted), overriding volume settings is your only option.

However, it is very cumbersome to do so.

Example:

• Start by creating a test Amazon S3 volume, putting your creds in the CP because that's the only way you can save the volume.
• you can now overriding your test creds in config/volume.php, getting them from env, or wherever.
• you'll need to repeat this, matching the handle for each volume.
• At this point the creds are overridden, but still in the DB – so to get them out you'd have to hop into the DB and delete the JSON values in volumes.settings. However, if that volume ever gets saved again, they're back in the DB :(

Solutions?

This is something that in Craft 2, this might have been been solved with "environment variables". You could do everything in the CP, but reference the variables instead. Aliases work for this for path-based things, but their application seemed to be limited to paths/urls…

If creating Volumes in the CP is a requirement, it seems like there should be a manageable way to reference dynamic values for this purpose.

These examples are specifically for volumes, but the same is true for other components with credentials (e.g. email).

[brandonkelly]

Yep. I think we should add a way to access environment variables in these settings (in addition to aliases where those still make sense).

For example, Symfony sets env(VAR_NAME) variables when parsing its configuration files (https://symfony.com/doc/current/configuration/external_parameters.html#environment-variables).

doctrine:
    dbal:
        url: '%env(DATABASE_URL)%'
    # ...

[brandonkelly]

Think it should be env:X rather than env(X) though.

[timkelty]

That'd be great!

[dougstjohn]

I like the idea of using an env value. Another UI solution would be a 'Save as a new volume' dropdown option like there is for entries, etc.

[brandonkelly]

This is implemented for Craft 3.1! (237d696)

Ended up just going with $VARIABLE_NAME, rather than env:VARIABLE_NAME, etc., as it’s more concise and consistent with @aliasName (and $VARIABLE_NAME is how you reference environment variables in the terminal).

Currently supported by:

• Sites:
  • Base URL
• Volumes
  • Base URL
  • File System Path
• Email settings
  • System Email Address
  • Sender Name
  • HTML Email Template
  • Username (Gmail, SMTP)
  • Password (Gmail, SMTP)
  • Host Name (SMTP)

[timkelty]

@brandonkelly – So, for this to be useful for non-core Volume types (e.g. AWS S3) – would this have to be supported specifically supported by each Volume type, or could/should this be dynamically applied to all volume settings?

I'd love to get away from having configs like this, but I don't see any other way:

<?php
// config/volumes.php
$region = getenv('AWS_S3_REGION');
$bucket = getenv('AWS_S3_BUCKET');
$s3Creds = [
    'bucket' => $bucket,
    'region' => $region,
    'keyId' => getenv('AWS_API_KEY'),
    'secret' => getenv('AWS_API_SECRET'),
    'url' => sprintf('https://s3.%s.amazonaws.com/%s/', $region, $bucket),
];

return [
    'seoImages' => $s3Creds,
    'fpo' => $s3Creds,
    'misc' => $s3Creds,
    'heroImages' => $s3Creds,
    'icons' => $s3Creds,
    'promos' => $s3Creds,
    'documents' => $s3Creds,
    'quoteImages' => $s3Creds,
    'headshots' => $s3Creds,
    'resourceImages' => $s3Creds,
    'listingImages' => $s3Creds,
    'newsletterImages' => $s3Creds,
];

[brandonkelly]

We’ll need to update the S3 plugin to add support for it.

[timkelty]

We’ll need to update the S3 plugin to add support for it.

👍 Made an issue: craftcms/aws-s3#35