Comments (6)
@ianpaul10 just want to add another perspective here. You don't want an unauthorized user to poke around and see what exists (401) and what doesn't (404). So from a security perspective, it's a good idea you always respond 401/403 for unauthenticated/unauthorized users regardless of the state of a feature.
from featuremanagement-dotnet.
@ianpaul10
Don't use the [FeatureGate]
attribute.
Its design is, frankly, broken.
Just implement an IActionConstraint
which checks the IFeatureManagerSnaphot
and register that on your controller action.
IActionConstraint
acts at the routing level and if the feature your constraint is checking, is disabled - then the constraint can report as violated and cause the routing system to completely skip the action as a valid routable endpoint. Then it's the routing system itself which will fall through to its fallback endpoint, most likely a 404 handler, and you don't need to futz about with any custom handlers needing to be wedged into the correct spot in the stack of MVC filters.
An action constraint is always how the entire thing should have been designed, but sadly wasn't.
Alternatively - and a bit more advanced - implement the behavior as an IEndpointSelectorPolicy
and you can apply feature gating to more types of endpoints than just the MVC controllers...
from featuremanagement-dotnet.
Using IActionConstraint
is a valid suggestion to handle routing based off of feature state. IActionConstraint
doesn't provide asynchronous evaluation so that might be a factor to limit adoption.
I don't consider the design of [FeatureGate]
to be broken. It solves the problem differently. IActionConstraint will make the action not routable, as you said. FeatureGate
will route to the action and provide a chance to customize the response using IDisabledFeaturesHandler
with the original action's context available.
from featuremanagement-dotnet.
It looks to me like in cases (2) and (4) both requests are coming from an unauthenticated user. If 404 was returned for case 4, wouldn't your issue exist based off of the difference between (2) and (4)?
from featuremanagement-dotnet.
After taking a second look I see the issue here. It seems that you do want this action to be not routable if the feature is disabled. @rjgotten's approach would be better here but there is no integration point for that in the feature management library. The FeatureGateAttribute is better suitable if you do want an action to still be routed to even when a feature is disabled, you just want the response to be customized, like maybe a custom page.
We can look to see how we can best integrate with the routing system to provide a better solution for your scenario where you don't want the action to be routable.
from featuremanagement-dotnet.
@zhenlan
You don't want an unauthorized user to poke around and see what exists (401) and what doesn't (404).
Conversely, you may also not want e.g. a tenant in a multi-tenant application to be aware certain features used for other tenants, exist - regardless of whether they have the necessary permission level to access them or not.
Both are valid scenarios.
For completeness sake: the 401 could also be returned from whatever is your configured fallback route. If you route to an error controller, that controller could also be set up to require authentication and authorization, only showing the error response to authenticated users and showing a 401 Unauthorized for others. (Actually; in that case a 403 may be more appropriate even.)
I'd also argue that that is actually the correct way to handle it, as it properly separates concerns; does not rely on weird quirks in the order of filter evaluation on MVC actions; and can also cover any other scenario. E.g. if you want a consistent 401/403 instead of a 404, you'll also have to cover e.g. non-existent controllers or action methods -- and solving this at the routing level within a fallback error controller accomplishes just that.
@jimmyca15
UsingIActionConstraint
is a valid suggestion to handle routing based off of feature state.IActionConstraint
doesn't provide asynchronous evaluation so that might be a factor to limit adoption.
IEndpointSelectorPolicy
though, does. 😉
from featuremanagement-dotnet.
Related Issues (20)
- Silent failure in TargetingTelemetryInitializer HOT 10
- The TargetingId should be included in the FeatureEvaluation event even if it's null/empty. HOT 5
- Targeting evaluation is CPU dependent. HOT 4
- Remove the support for variants and telemetry from the .NET feature flag schema HOT 14
- Include Targeting Information on outgoing telemetry HOT 2
- Support .NET 8 Targeting framework in Microsoft.FeatureManagement.Telemetry.ApplicationInsights.AspNetCore
- Target netstandard2.* in Microsoft.FeatureManagement.Telemetry.ApplicationInsights
- The approach to telemetry (using custom `ITelemetryPublisher`) seems overengineered and counter to modern OpenTelemetry abstractions HOT 37
- Add Default Http Targeting Context Accessor
- Consider moving `TargetingHttpContextMiddleware` to the App Insights package HOT 2
- No instance of ITargetingContextAccessor is available for variant assignment. HOT 6
- FeatureManagerSnapshot should snapshot TargetingContext as well
- EvaluationDataToApplicationInsights example
- Can't Set FeatureFilters In FeatureManager In .NET Framework Application HOT 10
- Update Package metadata
- Add a link to preview on main readme HOT 1
- Cannot use the TargetingFilter in .NET class library project HOT 3
- Nuget "Microsoft.FeatureManagement.AspNetCore" Version 3.3.0 - Multiple feature filters match the configured filter named 'Microsoft.TimeWindow' HOT 8
- Consider using `TimeProvider` using Microsoft.Bcl.TimeProvider nuget package HOT 2
- Bug 4.0.0-preview: NullReferenceException when TargetingContext.UserId is null and TargetingEvaluationOption.IgnoreCase = true
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from featuremanagement-dotnet.