"application/json" content type is not handled in KeyVault references

Internally AzureKeyVaultKeyValueAdapter doesn't handle ContentType property of secret value and returns naked value.

So we have dual behavior when same JSON setting stored directly or using keyvault reference with application/json content type returned as object or string.

I think problem seats at this peace of AzureKeyVaultKeyValueAdapter code
if (client) { // TODO: what if error occurs when reading a key vault value? Now it breaks the whole load. const secret = await client.getSecret(secretName, { version }); return [setting.key, secret.value]; // here it returns raw value without considering secret.properties.contentType value }

Thank you,

Good catch, it's a bug. Secret value is directly returned without being processed by JSON adapter. Will fix it soon.

Avani Gupta (@avanigupta)

Avani Gupta (@avanigupta)
AFAIK dotnet provider doesn't honor content type of a key vault secret either, and it flattens JSON into configuration entries. This use case is valid for JavaScript, not sure if it also applies to dotnet and if we want to support this in dotnet provider.

Besides content type, there are also some other properties we might honor, activation date and expiration date. probably we should do some verification, not to return the value (or throw an exception) if current date is not within the range [activation, expiration].

Vyacheslav Putsenko (@vputsenko)

Vyacheslav Putsenko (@vputsenko)
It's still under discussion with some concerns. So I closed the quickfix PR in favor of a general solution for similar use cases.

Currently you can use KeyVaultOptions.secretResolver to resolve the secret reference with customized logic as a workaround.

    /**
     * Specifies the callback used to resolve key vault references that have no applied SecretClient.
     * @param keyVaultReference The Key Vault reference to resolve.
     * @returns The secret value.
     */
    secretResolver?: (keyVaultReference: URL) => string | Promise<string>;

Note: Here I think secretResolver should return known type instead of string, as we allow values of the config map to be any type.

e.g.

const settings = await load(connectionString, {
    keyVaultOptions: {
        secretResolver: (kvrUrl) => {
            // create a secret client to fetch secret value from Azure Key Vault
            const secretClient = new SecretClient(kvrUrl, new DefaultAzureCredential());
            const secret = secretClient.getSecret(secretName);
            // an example to parse JSON for specific content type, can be more robust to deal with complicated MIME types
            if (secret.properties.contentType === "application/json") {
                return JSON.parse(secret.value) ;
            } else {
                return secret.value;
            }
        }
    }
});

Hi, i understand that .NET impl has different handling for JSON secrets, but also we need to answer question "How contentType of keyvault secret should be used then ?)" I thought that its direct role to tell how data should be interpreted ... I understand that fix should be common for all platforms, may be we can add some flag for .NET client to have this behavior there too ? I would say more that flattening is not always desired behavior too.

Zhiyuan Liang (@zhiyuanliang-ms)

Zhiyuan Liang (@zhiyuanliang-ms) it's on your radar now ;)

@vputsenko It's still under discussion with some concerns. So I closed the quickfix PR in favor of a general solution for similar use cases.

Currently you can use KeyVaultOptions.secretResolver to resolve the secret reference with customized logic as a workaround.
/**
 * Specifies the callback used to resolve key vault references that have no applied SecretClient.
 * @param keyVaultReference The Key Vault reference to resolve.
 * @returns The secret value.
 */
secretResolver?: (keyVaultReference: URL) => string | Promise<string>;
Note: Here I think secretResolver should return known type instead of string, as we allow values of the config map to be any type.

e.g.

const settings = await load(connectionString, {
keyVaultOptions: {
secretResolver: (kvrUrl) => {
// create a secret client to fetch secret value from Azure Key Vault
const secretClient = new SecretClient(kvrUrl, new DefaultAzureCredential());
const secret = secretClient.getSecret(secretName);
// an example to parse JSON for specific content type, can be more robust to deal with complicated MIME types
if (secret.properties.contentType === "application/json") {
return JSON.parse(secret.value) ;
} else {
return secret.value;
}
}
}
});

Hi, should you at least fix typing for secretResolver (now it expected to return only strings, but i fact it should be T or unknown)

Vyacheslav Putsenko (@vputsenko)

Hi, Vyacheslav Putsenko (@vputsenko) Thanks for reaching out!

Hi, should you at least fix typing for secretResolver (now it expected to return only strings, but i fact it should be T or unknown)

That makes sense to me!

linglingye001

Fixed in #323

Will release in 2.5.0 linglingye001

Vyacheslav Putsenko (@vputsenko)

Hi Vyacheslav Putsenko (@vputsenko) JS provider v2.5.0 has been released

Thank you.

so we can close this?

Navigation Menu

Repository navigation

"application/json" content type is not handled in KeyVault references #78

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

"application/json" content type is not handled in KeyVault references #78

Description

Activity

Eskibear commented on Jul 4, 2024

Eskibear commented on Jul 5, 2024

Eskibear commented on Jul 9, 2024

Eskibear commented on Aug 14, 2024

vputsenko commented on Dec 27, 2024

Eskibear commented on Dec 30, 2024

vputsenko commented on Jun 12, 2026

zhiyuanliang-ms commented on Jun 13, 2026

zhiyuanliang-ms commented on Jun 13, 2026

linglingye001 commented on Jun 25, 2026

vputsenko commented on Aug 25, 2026

Eskibear commented on Sep 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions