Support for multiple secrets containing same key (hierarchy of secrets)

[madkins-webscale]

The provider crashes if you have multiple secrets that specify the same key
This occurs in the SetData method when generating the dictionary (Unhandled exception. System.ArgumentException: An item with the same key has already been added)

Our use case is wanting to have a full set of configuration, including development or placeholder values for secrets and then a separate secret which takes precedence over this and supplies the actual secret values, overriding the placeholder values

It'd be nice if there was a way to either override the SetData method (ie we could customise the provider class - protected methods and ability to pass derived class into SecretsManagerConfigurationSource etc) or a preFilter type options method that allowed you to filter _loadedValues before the call to SetData (or at the beginning of SetData):

          if (!oldValues.SetEquals(newValues))
            {
                _loadedValues = newValues;
                SetData(_loadedValues, triggerReload: true);
            }

[Kralizek]

Hi, just to understand:

you have two secrets in Secrets Manager that attempt to write the same key, is that correct?

[madkins-webscale]

We are only reading the data from the secrets, but yes we might have say:

• application/defaultConfig
• application/secrets

And for example application/config might have:

{
  "ExternalService:ApiUrl": "https://api.somewhere.com",
  "ExternalService:ClientId": "xxxxx--xxxxxxx-xxxxxxx-xxxxxx",
  "ExternalService:ClientSecret": "placeholder"
}

And application/secrets might have:

{
  "ExternalService:ClientSecret": "xxxxxxxxxxxxxxx"
}

There are other examples where we may override settings for a particular environment but this is just an example to illustrate. I guess our use case may be a little unusual in that we are using secrets as a method of delivering config as well as true secrets

[Kralizek]

So, I can take this as a "bug" but I think I'd prefer handle it in a way that somehow feels organic.

Options are

• new value wins
• old value wins

An alternative would be to add a delegate to be invoked when there is a key conflict, something like Func<string key, string currentValue, string newValue, string value> but I can't give you a timeline.

[madkins-webscale]

Thanks for the replies - I think new value wins is reasonable.
We've found a work around in the meantime though by just using a second instance of the secrets provider in our config provider stack

[to11mtm]

So, I can take this as a "bug" but I think I'd prefer handle it in a way that somehow feels organic.

Options are

* new value wins

* old value wins

An alternative would be to add a delegate to be invoked when there is a key conflict, something like Func<string key, string currentValue, string newValue, string value> but I can't give you a timeline.

'New' vs 'old' can be dependent on the order keys are retrieved however, yes?

that said, jumping in with feedback from recent use/etc, my preference would be 'delegate with a default of new value wins'.

PPS I am happy to try and give this a shot and submit a PR if that helps get it over the line!