-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds default http targeting context accessor #416
Adds default http targeting context accessor #416
Conversation
If someone has an idea for a shared place for the |
Just for ideas... you either make it a public property or use InternalsVisibleToAttribute between the two packages. Like you said, none of them are clean ways. |
I know adding a scoped service will be an approach that we will want to propose to float the resolved targeting context along, but I also thing we should consider an alternative option -- exposing a public extension method on HttpContext from the
|
src/Microsoft.FeatureManagement.AspNetCore/DefaultHttpTargetingContextAccessor.cs
Outdated
Show resolved
Hide resolved
src/Microsoft.FeatureManagement.AspNetCore/DefaultHttpTargetingContextAccessor.cs
Show resolved
Hide resolved
@jimmyca15 @rossgrambo Are we going to include this PR into the next preview release (preview3)? |
Would be nice- but I don't think it's a blocker. |
src/Microsoft.FeatureManagement.AspNetCore/DefaultHttpTargetingContextAccessor.cs
Outdated
Show resolved
Hide resolved
…gContextAccessor.cs Co-authored-by: Weihan Li <[email protected]>
@@ -18,7 +18,7 @@ public class TargetingHttpContextMiddleware | |||
private readonly RequestDelegate _next; | |||
private readonly ILogger _logger; | |||
|
|||
private const string TargetingIdKey = $"Microsoft.FeatureManagement.TargetingId"; | |||
private const string TargetingContextLookup = "FeatureManagement.TargetingContext"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any reason why we removed Microsoft
prefix here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not that I can recall... I'll add it back.
Is there a plan to use this built-in targeting context accessor in our FeatureFlagDemo example? (include the change in this PR or create a new PR after this PR is merged?) |
Yes, I'm planning on a separate PR to update examples. |
There have been some developments as we have discussed the middleware and telemetry initializer across different PRs/issues. My expectation at this point is that:
As such, I don't expect any changes in the middleware/initializer as part of this PR. |
Agreed. This PR is on hold until the caching rework is completed. |
src/Microsoft.FeatureManagement.AspNetCore/DefaultHttpTargetingContextAccessor.cs
Outdated
Show resolved
Hide resolved
…gContextAccessor.cs Co-authored-by: Zhiyuan Liang <[email protected]>
...ights.AspNetCore/Microsoft.FeatureManagement.Telemetry.ApplicationInsights.AspNetCore.csproj
Outdated
Show resolved
Hide resolved
…ttps://github.com/microsoft/FeatureManagement-Dotnet into rossgrambo/default-http-targeting-context-accessor
....FeatureManagement.Telemetry.ApplicationInsights.AspNetCore/TargetingTelemetryInitializer.cs
Outdated
Show resolved
Hide resolved
/// <summary> | ||
/// The key used to store and retrieve the <see cref="TargetingContext"/> from the <see cref="HttpContext"/> items. | ||
/// </summary> | ||
public const string TargetingContextLookup = $"Microsoft.FeatureManagement.TargetingContext"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's debatable who should own this cache key. It's odd to see the more generic initializer and middleware reference the cache key from a very specific targeting context accessor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed... I still am unable to come up with a satisfying place to put this. I suppose the owner could be the middleware- because the middleware's whole goal is to ensure that the TargetingContext
is available at that key.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The targeting context accessor doesn't need to share a key.
private static object _cacheKey = new object();
should work fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's 3 classes that interact with HttpContext.Items for targeting context. Initializer
, Middleware
, and the TargetingContextAccessor
.
Initializer
depends upon the Middleware
. The Middleware
depends upon a TargetingContextAccessor
existing. The Middleware
and Initializer
are tightly coupled- so they definitely need to share a key. The TargetingContextAccessor
doesn't have to share the same key, but it reduces our HttpContext.Items footprint if it does- and is a clear shared cache location.
So for Initializer
and Middleware
, we are going to have a shared key- it could be either an object ref or the string key "Microsoft.FeatureManagement.TargetingContext"
. I slightly prefer the string key since it's public (on the HttpContext.Items and as a public property). The key needs a home, and if it was just these two classes it would either be on the middleware or a shared constants class.
Now the DefaultTargetingContextAccessor
comes in- which is our default implementation. It needs a cache key as well. It could either define its own key (as a string or object ref) or used a shared constants class.
I think the shared constants class makes things the most clear- as FM is defining where TargetingContext
should live on HttpContext.Items
. I ended up not liking adding the constants class because it introduces yet another public class, and I ended up going with the DefaultTargetingContextAccessor
.
This PR has been dissolved into two:
|
Why this PR?
a. Add Default Http Targeting Context Accessor #415
b. The TargetingId should be included in the FeatureEvaluation event even if it's null/empty. #399
Next Steps:
Visible Changes
Developers will now have a new type available to them,
DefaultHttpTargetingContextAccessor
. Instead of defining their own, they can use this type when adding targeting viaWithTargeting
like:The default accessor will extract the targeting info from
HttpContext.User
.Groups
will be extracted from claims of typeRole
.UserId
is taken from theIdentity.Name
field.