Reduce spread of [GeneralWebHook] support
#258
Comments
|
Self-assigning because this needs to be done in the Preview2 milestone. Will otherwise be locked into the current approach. |
dougbu
added
enhancement
cost: M
|
@mkArtakMSFT doing this may reduce the size of other tasks and issues in this repo a bit. Issue is itself on the S / M border because it should mostly be mechanical. |
|
BTW this is tied to main ASP.NET Core WebHooks 1.0.0 rock because |
|
/fyi @rynowak |
- #258 - centralize and minimize metadata lookups, especially per-request lookups - add `abstract` `WebHookReceiverMetadataProvider` and implementation (`DefaultWebHookMetadataProvider`) - add core constraints and filters to actions from `IApplicationModelProvider` implementations, not globally - these use `WebHookReceiverMetadataProvider` in `[GeneralWebHook]` scenarios - add receiver-specific filters to actions from `WebHookActionModelFilterProvider` or `WebHookReceiverFilterProvider` - pattern is somewhat simpler than that for core filters - receiver-specific filters _never_ need to check their own applicability - add an `IFilterProvider` implementation: `WebHookReceiverFilterProvider` - add `IWebHookFilterMetadata` to ease registration of receiver-specific filters - consolidate and rename lots of classes - give `IApplicationModelProvider` implementations clearer, more specific names nits: - shorten a few long lines - Vs removed some BOMs WIP - finish remaining filters - instantiate all core filters (not just `WebHookVerifyBodyTypeFilter`) in `WebHookActionModelFilterProvider` - add more metadata to `ActionModel.Properties` in `WebHookActionModelPropertyProvider` - fix tests
|
Any update on the above and associated pull request? is this the last large change which will be going in before the full aspnet core 2.1 release? Cheers |
Have been doing other things but will get back to this soon.
Not necessarily. Why do you ask? |
|
Thanks for the update. I've been working on a Webhook that I want to nuget up but have been developing it in this solution to aid with debugging and getting the latest changes as the library has been developing. Just curious how much I'd have to tweak before I can get a preview out based on a stable nuget :-) |
- #258 - centralize and minimize metadata lookups, especially per-request lookups - add `abstract` `WebHookMetadataProvider` and implementation (`DefaultWebHookMetadataProvider`) - add core constraints and filters to actions from `IApplicationModelProvider` implementations, not globally - constraints and filters use `WebHookMetadataProvider` in `[GeneralWebHook]` scenarios - add receiver-specific filters to actions from `WebHookActionModelFilterProvider` or `WebHookFilterProvider` - pattern is somewhat simpler than that for core filters; these filters need to check their own applicability - add `WebHookFilterProvider`, an `IFilterProvider` implementation - add `IWebHookFilterMetadata` to ease registration of receiver-specific filters - implement `IOrderedFilter` in all filters - consolidate and rename lots of classes - give `IApplicationModelProvider` implementations clearer, more specific names nits: - make doc comments more consistent - correct a few oddly-named fields and variables - shorten a few long lines
dougbu
added
cost: S
|
Reduced cost to track the review process that remains in this milestone. |
- #275 - register `DefaultWebHookMetadataProvider` in DI - register `IWebHookFilterMetadata` implementations in DI - fix parameter reversal and overuse of `Resources.VerifyMethod_BadMethod` - add first functional tests - part of #180 - add functional test infrastructure - update `DropboxCoreReceiver` to meet new requirements e.g. add test-only secret key nits: - correct names of resources - let VS remove a few UTF8 BOMs
- register `DefaultWebHookMetadataProvider` in DI - correct names of resources
Most of the WebHook constraints and filters do runtime look-ups (Linq queries) to find their metadata. This is decentralized even though it's not required for anything but actions with
[GeneralWebHook]applied. Thought is to instead apply specific constraints and filters when processing the application model.For the
[GeneralWebHook]case, use different constraint and filter constructors that pass a newinterface. That interface would hide the runtime lookup behind its facade. When processing a request, constraints and filters would use the interface to grab the metadata they need, then proceed in the normal (receiver-specific) way.Should not repeat any requirements the application model code enforces in the code for the
[GeneralWebHook]case. Instead assume the retrieved metadata is consistent and let the constraints and filters "blow up" if not. This avoids additional code duplication and complexity.The text was updated successfully, but these errors were encountered: