3

I've two environment, dev and staging. I'm using the ReCaptcha module.

In the developpement environment, I have some api keys a other config which until now, are exported thanks to drush cex inside the recaptcha.settings file

site_key: mysite_key
secret_key: mysite_secret
verify_hostname: false
use_globally: false
widget:
  theme: dark
  type: image
  size: ''
  tabindex: 0
  noscript: false
_core:
  default_config_hash: mydefault_hash
langcode: fr

If I update my staging files website, the config from the development is imported with drush cim.

How can I, without another module, prevent this ?

In my settings.local.dev.php, I've added this line and ran drush cex :

$settings['config_exclude_modules'] = ['recaptcha'];

And it gave me this result

enter image description here

The config is completly deleted, but I'd like to keep all the config but not the site_key / secret_key (such as theme etc...)

I wish I could have a config for the development and the staging separetly, but still using drush commands.

1
  • 1
    You don't need to mess around with exports here, your secret key should never be in the codebase anyway. Use a config override in settings.php instead, much simpler
    – Clive
    Aug 11 '21 at 14:00
4

You don't need to exclude the API keys from export; instead, you can set them in code, and then it doesn't matter what gets exported. (...probably. Some modules will not work with this approach.)

You can override config directly in settings.php.

Here's an example with Swiftmailer module taken from one of my sites.

swiftmailer.transport.yml

transport: smtp
smtp_host: smtp.example.com
smtp_port: 465
smtp_encryption: ssl
smtp_credential_provider: swiftmailer
smtp_credentials:
  swiftmailer:
    username: ''
    password: ''
sendmail_path: /usr/sbin/sendmail
sendmail_mode: bs
spool_directory: ''
_core:
  default_config_hash: RSNbRD3ekSaZoE19f3eHhm93gKOcD2PtmaAVmV3XMes
langcode: ja

Now I want to use a different API key for dev + production. So, in settings.php, I set the config manually:

  $config['swiftmailer.transport']['smtp_credentials']['swiftmailer']['username'] = 'apikey';
  $config['swiftmailer.transport']['smtp_credentials']['swiftmailer']['password'] = 'ABCDEFGHIJKLMNOP'

In my case I'm using a switch to detect an environment variable (live, test, dev, etc.) because that's how the host Pantheon does it, but you can do the same thing with settings.local.dev.php files.

Config in settings.php will never be exported; drush will ignore it. However, Drupal will always prioritize config set in code over .yml files. As a result, if you need to change this, you will have to update the code itself; you won't be able to make changes from the UI anymore.

Also note that it is a potential security issue to check API keys into version control like this.

The Config Override module adds a warning to admin screens that reminds you that you are overriding values in code.

If security is a concern, there's the Lockr module, which was built specifically to handle the use case of juggling API keys, but you have to pay for that.

6
  • This is tricky, because my client will probably change the key one day or another (my question is more global than only one module in fact), so in this case, I don't think doing it by the code is the best approach... But if I end up by doing by the code, if I understand well, I have to add this $config['recaptcha.settings']['site_key'] = "mycustomky"; inside settings.local.dev.php ?
    – mt.i.1
    Aug 11 '21 at 14:07
  • @mt.i.1 Yes, that looks correct. Aug 11 '21 at 14:15
  • It's working well on front, is it possible to "link" key in the database so that it appears in the backend ? Those fields are required, and I can't submit the form to save the other settings
    – mt.i.1
    Aug 11 '21 at 14:49
  • @mt.i.1 You can use the production field value or a dummy field value (a bad API key that validates) to allow you to save the config. Aug 11 '21 at 17:28
  • 1
    If you don't want to save passwords and API keys in the active config (where they will be exported as YAML and exposed in the code repo in plaintext) or in a settings file (also exposed in the code repo as plaintext) you can store these values in a secrets.php file, unique per environment, which can be sourced by settings.php or settings.local.php. Aug 11 '21 at 23:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.