Skip to content

Conversation

@jimmyca15
Copy link
Member

This PR adds support for feature flags containing the ':' character.

Currently a feature with the name "Feature:With:Colons" cannot be found by the feature manager. With this change, the feature will now be found and evaluated as expected.

@jimmyca15
Copy link
Member Author

cc @MaryanneNjeri I wasn't able to add you as a reviewer.

}
}

configuration = section;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If featureName is Feature:With:Colons, after the foreach loop ends, we'll set configuration to the section named Colons . Then we call ReadFeatureDefinition(configuration), and that method will return the FeatureDefinition object where FeatureDefinition.Name will be set to Colons instead of Feature:With:Colons (code).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. This made me realize a bigger problem which is how this works with GetFeatureDefinitionAsync. We may not be able to handle that

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GetFeatureDefinitionAsync can't detect features that have :. That's a glaring hole in supporting :. We may just want to block : because of that.

Comment on lines +106 to +108
sections = section == null ?
GetFeatureDefinitionSections() :
section.GetChildren();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

section == null will only be true for the first iteration in the foreach loop. Instead of doing this check inside the loop every time, can we initialize sections to GetFeatureDefinitionSections() before the loop?

{
//
// Feature names with configuration path delimiters require traversing children sections for resolution
IEnumerable<string> sectionNames = featureName.Split(SectionSeparator, StringSplitOptions.None);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we define SectionSeparator as a string instead of string[]? Another option is to directly use ConfigurationPath.KeyDelimiter because this is a special delimiter that's unlikely to change in .NET.

Copy link
Member Author

@jimmyca15 jimmyca15 Nov 25, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just stored it that way since Split accepts string[] and ConfigurationPath.KeyDelimiter is a string instead of a char. It's an optimization instead of creating a new string array every time.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, Split also accepts string delimiter.

@jimmyca15 jimmyca15 closed this Nov 25, 2021
@fpaganetto
Copy link

fpaganetto commented Mar 11, 2022

Hi guys, is there an update for this feature? Why this was closed?
I would like to have an object on the app to represent the actions we have available on our API (without having a plane object):

"EndpointEnabledStatus": {
    "Path": {
      "Subpath": {
        "Create":  false,
        "Read" : true,
        "Update" : false,
        "Delete" : true
      }
    }
  }

I've been doing some testing and seems the GetChildren is the main issue because it just takes the children of the root.

@jimmyca15
Copy link
Member Author

@fpaganetto We abandoned this due to the complexity of supporting the ':' character in .NET Core. This character separates configuration sections and as you mentioned breaks the way the feature manager works today. It's not possible to deterministically enumerate all defined features if the : character is allowed. Without redesign at least.

@fpaganetto
Copy link

Just to be clear, I want to have subsections on the appsetings.json with nested objects and access using the : on the FeatureGate annotation constant. Is that not going to be possible?

I don't understand if this is because of allowing the : character on the key name. That contradicts the PR #95 where the usage of : is being rejected.

An example of what I want:

[FeatureGate("Authentication:User:Read")]
public async Task<IActionResult> ReadUser(int id){}

[FeatureGate("Authentication:User:Create")]
public async Task<IActionResult> CreateUser(User user){}

On my appsettings.json:

"EndpointEnabledStatus": {
    "Authentication": {
      "User": {
        "Create":  false,
        "Read" : true,
      }
    }
  }

@jimmyca15
Copy link
Member Author

@fpaganetto Thanks for the clarification. That is not going to be possible. The PR that you linked does need to be completed to make it clear that the ':' character is not supported. I will bump it for review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants