Integration with the Key module would allow site administrators to choose how the MailChimp API password is stored—in a file outside the web root, for instance, or on another server altogether. This would allow for a greater level of security than storing the key in plaintext in the database.
The steps for using Key with MailChimp would be:
1) Create a key using the MailChimp API key on the Key admin page; store the key in a supported location, preferably not in the database

2) Enable integration with MailChimp API on the Key integration admin page

3) Choose the new key on the MailChimp settings admin page

Comments
Comment #1
rlhawkComment #2
rlhawkHere's a patch that adds integration with Key.
Comment #3
rlhawkIgnore the previous patch and use this one instead.
Comment #4
CountPacMan commented@rlhawk: this looks like a nice solution to this problem, but I'm unable to test it as I'm getting this error:
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'mailchimp.key_integration' doesn't exist: SELECT * FROM {key_integration} ORDER BY name ASC; Array ( ) in _key_integration_plugin_process() (line 740 of ../mailchimp/sites/all/modules/key/key.module)
even after rebuilding the registry. It seems like the key module is not creating the key_integration table required. Do you have any ideas?
Comment #5
rlhawkThanks for catching that. There was an error when creating an index. I've fixed it and created a new beta version of Key.
Comment #6
CountPacMan commented@rlhawk: still getting same PDOException error with Key-beta6. It's triggered by the Plugin definition for the MailChimp API.
Comment #7
rlhawkCan you uninstall and re-install Key? The key_integration table should be created properly now with beta 6.
Comment #8
CountPacMan commentedI did, but there's only an uninstall for Key UI. It doesn't drop the key_config table. After I went in the db and did that manually, it installed fine and created the key_integration table. That error doesn't exist anymore and I don't get that error anymore. I can add mailchimp in the Keys -> Integration tab, but now I get a new error:
Notice: Undefined index: plugin module in ctools_plugin_get_function() (line 777 of ../../mailchimp_dev/modules/contrib/ctools/includes/plugins.inc). =>
Comment #9
rlhawkThe Key module is currently being refactored. A new patch will be submitted when ready.
Comment #11
rlhawkHere's a new patch, rerolled for Drupal 8. It assumes that Key is to be made a dependency of MailChimp, which is the cleanest way to provide integration. If you'd like to support both using Key and entering the MailChimp API directly, that can certainly be done, but it's a bit more complicated. Here's what this patch adds:
Comment #12
rlhawkWhoops, changing version.
Comment #15
Andreas Radloff commentedThis would solve the problem I have, since the key is currently exported into mailchimp.settings.yml I have to gitignore that file to prevent sensitive data ending up in version control. That means I loose all mailchimp settings when I do a clean install on my local machine etc...
Comment #16
greg boggsFor clean installs on your local machine, you can keep the settings in local.settings and preserve that file through the install process. This feature will be a great one to have though!
Comment #17
Andreas Radloff commentedThanks, Greg! That works perfectly, free banana for you! :)
Comment #18
asrobComment #19
nicksanta commentedRerolled rlhawk's patch from #11 against 8.x-1.x HEAD.
Comment #20
nicksanta commentedAdded some missing methods to the MailchimpApiKeyType class.
Comment #21
nicksanta commentedKey 8.x-1.5 has a new feature which enables overriding *any* config value with a secret. I wrote a blog post describing how to implement this on the MailChimp module - https://www.previousnext.com.au/blog/securing-drupal-storing-api-tokens-...
Comment #22
samuel.mortenson@nicksanta If we documented how to use Key overrides with Mailchimp, or linked to your blog, would that be an acceptable solution? Adding a new module dependency that not all users need is quite disruptive in a release.
Comment #23
rlhawkThat sounds like a good solution to me. It would be great if more modules supported Key natively, but with overrides available, that's not necessary.
Comment #24
nicksanta commentedRe: #22 - I think thats fine. Given the relatively low number of modules supporting key natively, the config overrides approach can be applied essentially for all modules.
Comment #25
samuel.mortensonI added a brief note about the blog post to the project page. Thanks all!