Add support for multi-value keys

Wonderful. I'm happy to help with whatever you need for integration. The config export vulnerability in SA-CORE-2016-004 emphasizes the importance of keeping sensitive keys out of the database.

There is not currently a plugin solution for accepting and combining two pieces of data, though it has come up before. I've always just created two keys. Now you've got me thinking about how to implement a multi-field option.

Being able to create a key while on an integrated module's settings page has also been discussed a number of times. Perhaps the Inline Entity Form module could be used?

I'm the maintainer of the Akamai 8.x branch and have the exact same requirement. Here's a screenshot of the values I need to keep:

Akamai's recommendation is to keep the first 4 values in a file outside the docroot. It would be great to have support for a plugin type which allowed me to manage them as a unit.

Thanks for the great module!

Hey All!

Glad you're wanting to leverage Key in your modules! I think for what you're wanting to do the recent key override system for D8 will help solve the multiple value issue. I think trying to combine them into a single field could potentially muddy up the user interface to make things more difficult to adopt.

What the new override system does is allow for modules to declare to key all the form elements that are secure and it provides a tab within the key interface to manage the overrides. That interface groups the key overrides by module so it's easy to manage them all in one spot. So the steps a user would go through are:

1. Add the key values to the key module (if setting up for the first time). If they already have a key in place they can go directly to the overrides tab and import the key from the database and create a new key linked to that override.
2. Go to the overrides tab and select the values for each module's overrides they want.

I like the idea of grouping the keys by module, take a look at the new overrides interface and see if it does what you're wanting. If not we can definitely look at other ways to edit the interface to make management as simple as possible. That the main goal with the module, making key management secure and simple.

Key is built with the assumption that a key value is a string, not an array, and changing it could complicate things in a way that could be problematic. That said, it is possible, within the current architecture, to support multiple values within the key value string. The first step would be to create a new key type plugin that matches the needs of a particular module. For instance, Akamai could define a key type—perhaps called "Akamai Connection"—that would expect a string that contains all the values necessary to connect to, and authenticate with, an Akamai account. If the user wanted to store that data in a YAML file, that should work just fine with the File key provider, but then the Akamai module would be responsible for turning the string into multiple values. Ideally the integrating module should not have any special requirements with regard to the key provider that is used, so this approach would violate that tenet. We could standardize on a format for returning a multi-key value—JSON, for instance—but then why not just make it array at that point? At least that would be easily detectable within PHP. I'm going to do some more investigation and testing today.

Here's what a file multivalue key provider could look like.

And here's a patch with the proof-of-concept key provider. The only format it actually handles is JSON.

I want to store PGP key pairs for each user, can this be achieved using this patch? Has this patch been included in the module?

@marncz - It sounds as though you're looking for a key field type for entities, which the Key module does not provide.

See an alternative solution at https://www.drupal.org/project/key/issues/2929542

Thanks for the discussion in this issue. Marking as duplicate, based on the work being done in #2929542: Add support for multivalue keys and user/password key type.