Potential bug: Propagating App Service environment variables through IFeatureManager

[aatrisgn]

Hi,

I am experiencing some weird behaviour utilizing IFeatureManager on a regular Linux S1 App Service with Azure App Configuration integration via managed identity.

In short, it seems like IFeatureManager propagates some configuration of our App Service instance when no Feature Toggles are defined in Azure App Configuration for our application.

We have two scenarios for our usage:

1. An application has one or more feature flags enabled in Azure App Configuration
2. An application has no feature flags enabled in Azure App Configuration

We are exposing the feature flags via a configurations endpoint for our frontend application. Our feature flags are not sensitive information, but only for UX.

Our feature flags will only be defined in Azure App Configuration for deployed Azure environments. Locally, we handle it differently.

Problem
What we experience are the following three things:

1. An environment has one or more feature flags enabled:
   

Feature flag is correctly exposed to our frontend.

2. An environment has disabled feature flags:
   

We do not expose any feature flags - This is fine behaviour as well.

3. We have not deployed any feature flags (Where the problem lies):
   

This is problematic. We do not want to expose what seems to look like App Service configuration for our feature flags. It seems weird to me, that this is exposed via IFeatureManager. I can read in the documentation that IFeatureManager exposes environment settings as well, but I wouldn't expect it to do so, unless explicitly defined.

Our application code for Azure App Configuration looks like the following:

webApplicationBuilder.Services.AddFeatureManagement();

if (appConfigEndpoint != null) {
    webApplicationBuilder.Configuration.AddAzureAppConfiguration(options =>
        options.Connect(
            new Uri(appConfigEndpoint),
            new ManagedIdentityCredential(managedIdentityId))
    .UseFeatureFlags(featureFlagOptions => featureFlagOptions.CacheExpirationInterval = TimeSpan.FromMinutes(5)));
}

We expose our Feature Flags to our frontend via the following:

var featureDictionary = new Dictionary<string, bool>();

IAsyncEnumerable<string> availableFeatures = _featureManager.GetFeatureNamesAsync();

await foreach (string feature in availableFeatures) {
    if (await _featureManager.IsEnabledAsync(feature)) {
        featureDictionary.Add(feature, true);
    }
}

return featureDictionary;

As for now, we have a work-around, but we were a bit surprised by this behaviour. In our case, it werent critical information which was exposed, but if it had been a connectionstring or similar, that would have been problematic.

My question therefore is, whether this is intentional behaviour? If so, what is your recommended way of handling a scenario where you only sometimes have feature flags defined and needs to expose them?

Please let me know, if you need anything further information.

Thanks in advance

[rossgrambo]

Hello @aatrisgn,

Here's what I think is happening:

1. AddAzureAppConfiguration adds the Dotnet Provider.
   1. The Provider takes items from App Configuration's Servers, and places them into the Configuration for the app.
   2. Other things might add to this Configuration, like appsettings.json or Environment variables via calls on the ConfigurationBuilder like .AddEnvironmentVariables()
2. When calling FeatureManagement.GetFeatureNamesAsync() it:
   1. Calls GetAllFeatureDefinitionsAsync on the IFeatureDefinitionProvider from DI. This could be the problem, if you have a custom IFeatureDefintionProvider. If you don't have a custom one, it uses our ConfigurationFeatureDefinitionProvider.
   2. Our ConfigurationFeatureDefintionProvider looks in the Configuration and returns the section named "FeatureManagement". If there is no section named "FeatureManagement", it simply returns the Configuration. This could be the problem, if you leave out the "FeatureManagement" section, it's likely assuming top level for the feature flags

For your situation, I'm assuming the issue is the latter. In order for the functionality you want, you should add an empty "FeatureManagement" section when there are no Feature Flags defined.

Hope this helps!

[aatrisgn]

Hi!

Thanks for getting back to me on this.

Your explanation makes sense in comparison to what we experienced.

I am a little bit curious why it is that the FeatureManagement returns the configuration if there is no feature-section present? If I use the feature manager and do not specify any feature section, I would suspect the feature manager to return an empty collection of values and not the configuration.

Maybe I am overlooking something, but why would FeatureManager return configurations when no feature-section is found?

Thanks in advance

Have a great day :)

[rossgrambo]

It's a design choice that might be causing more harm than good. There's some more details in #144

[jimmyca15]

Fixed in 3.0