For WebJobs v2, bulk of the work for Invocation Filters was checked in via https://github.com/Azure/azure-webjobs-sdk/issues/980. However, there are some remaining work items we're tracking before the feature can be considered complete:
In v3 the Filters feature is currently marked Obsolete due to the above issues: https://github.com/Azure/azure-webjobs-sdk/pull/1912. The feature is not going away - we applied Obsolete because we had to GA v3 before the feature was complete, so we wanted to convey that there may be breaking changes in this area as we complete the work above.
We should split "Finalize design for FunctionResultException" into a separate work item.
@MikeStall - Moved the Result work out into its own issue here: https://github.com/Azure/azure-webjobs-sdk/issues/1314
Has there been any progress on this? I noticed FunctionInvocationFilterAttribute is still marked Obsolete ("..in preview..."). Any idea when it will be finished up?
Yeah! Very strange that it is taking this long. Is it because of the latest changes on DI forAzure functions?
https://docs.microsoft.com/en-us/azure/azure-functions/functions-dotnet-dependency-injection
I just love the part that it says:
Microsoft.NET.Sdk.Functions package version 1.0.28 or later
And version 1.0.28 is the latest version and is only 25 days old :)
I hope it means that we get this feature soon as well
Yes, we want to finish the feature up properly, integrating it with the new DI work naturally. The feature was marked Obsolete because we anticipated there might be some breaking changes as we finished it up. I'd like to complete this in the next major release. @fabiocav
Any update on this? When is the next Major release?
Will it be implemented in 3.0 version?
Any update on this feature? Will this be part of V3?
Any updates on this feature?
This feature has not been prioritized as part of the 3.0 work. This is not currently part of the immediate roadmap, so we don't have an ETA we can share.
/cc @mathewc @mattchenderson
Thanks for the update @fabiocav.
Reason for why I'm looking for a filter right now is in fact to have a custom authorization done before the function code gets called. Specifically, I want to implement a role authorization provider and validate that an authenticated user is indeed allowed to call a particular function in a function app.
Since filters are, due to their lack of tread-safe nature, a no-go, is there another way in which this can be achieved?
That's too bad because this is something useful that I would like to see in the platform.
any update on this?
Seems like the lack of update indicates that this feature is dead.
I'm eagerly excited for this feature to make it to the day-light and be thread-safe. :-)
Any update on the roadmap would be much appreciated, @anthonychu @fabiocav
Thanks for the update @fabiocav.
Reason for why I'm looking for a filter right now is in fact to have a custom authorization done before the function code gets called. Specifically, I want to implement a role authorization provider and validate that an authenticated user is indeed allowed to call a particular function in a function app.
Since filters are, due to their lack of tread-safe nature, a no-go, is there another way in which this can be achieved?
Since filters are not going to be available anytime soon and we are activiely looking for a way to authorize the Azure functions using JWT tokens, I propose that Microsoft issue sample code(C#) demonstrating how to validate and authorize HTTP functions using JWT tokens.
Thank you.
This is a bit frustrating as now we have to write boilerplate and duplicated error handling/authorization logic. Come on Microsoft! You obviously know this is an important part of any web framework as it was created for MVC AND WebApi. Why is this suddenly not a priority? By the way, I love how the error handling section of Azure HTTP Trigger functions states
https://docs.microsoft.com/en-us/azure/azure-functions/functions-bindings-error-pages
"Use structured error handling
Capturing and publishing errors is critical to monitoring the health of your application. The top-most level of any function code should include a try/catch block. In the catch block, you can capture and publish error" ....no kidding Microsoft!

@fabiocav will this functionality get re-prioritized?
Adding @jeffhollan for awareness/priority discussions, but this has not yet changed.
@moorechr4484 did you have specific feedback/something you'd like to see changed on the doc, or are you pointing out something that seems obvious to you?
Can anyone elaborate on what "Integrate Filters fully with DI" means? What integration is missing? Thanks.
Can anyone elaborate on what "Integrate Filters fully with DI" means? What integration is missing? Thanks.
Filters are not constructed using DI. I.e., you must use service location to "inject" dependencies into them.
@davidpeden3 , thank you. I'll note here a few observations about _global_ filters for others who are interested.
IFunctionFilter _must_ be registered as a Singleton. You get a runtime error otherwise.IServiceScopeFactory and create a scope to resolve such services.Startup:services.AddSingleton<IFunctionFilter, MyFunctionFilter>();
services.AddSingleton<IOtherService, OtherService>();
services.AddTransient<ITransientHelper, TransientHelper>();
In MyFunctionFilter:
public class MyFunctionFilter : IFunctionInvocationFilter
{
private readonly IServiceScopeFactory _serviceScopeFactory;
private readonly IOtherService _otherService;
public MyFunctionFilter(IServiceScopeFactory serviceScopeFactory, IOtherService otherService)
{
_serviceScopeFactory = serviceScopeFactory;
_otherService = otherService
}
public async Task OnExecutingAsync(FunctionExecutingContext executingContext, CancellationToken cancellationToken)
{
await _otherService.DoSomething();
using (var scope = _serviceScopeFactory.CreateScope())
{
var helper = scope.ServiceProvider.GetRequiredService<ITransientHelper>();
// use helper
}
}
public Task OnExecutedAsync(FunctionExecutedContext executedContext, CancellationToken cancellationToken)
{
throw new NotImplementedException();
}
}
Following this.
After reading all of them. Even the Microsoft is made IFunctionInvocationFilter, IFunctionExceptionFilter obsoleted I feel, Its safe to use for the basic support of global exception handling and authorizing the requests for my HTTP trigger function.
@mathewc @paulbatum Any suggestions?
Why this is not based on attribute?
@MrMaheshwari, I haven't tried it myself, but I believe you can implement invocation filters as attributes. See the example here:
https://www.c-sharpcorner.com/article/do-you-know-azure-function-have-function-filters/
@MrMaheshwari, I haven't tried it myself, but I believe you can implement invocation filters as attributes. See the example here:
https://www.c-sharpcorner.com/article/do-you-know-azure-function-have-function-filters/
Thanks for sharing such a nice article
Any ETA to release this feature?
@MrMaheshwari, I haven't tried it myself, but I believe you can implement invocation filters as attributes. See the example here:
https://www.c-sharpcorner.com/article/do-you-know-azure-function-have-function-filters/
@NSouth Here is a limitation, we can not return back the HttpResponseMessage object
Microsoft Azure dev team: issues "preview" of highly-requested feature
Also Microsoft Azure dev team: doesn't bother finishing said feature more than 3 years later
Have you guys, you know, considered hiring more devs so work actually gets done in a reasonable timeframe? It's not as if you work for a small mom-and-pop shop...
I can see some interest in this and so going to give the answer that may help folks plan the best, but things can always change. We don't have any plans to bring functions filters as currently implemented as this preview feature forward. That said, the scenario that many people are interested in using function filters for, namely to add some logic and middleware before an execution triggers, is something we do want to solve for. We have recently prototyped some features as part of the upcoming out of process .NET work that allows users to add some middleware to execute before a function triggers for something like token validation or whatnot. If you were to ask me today that's what I would say is the future of this scenario, and not function filters as implemented.
I'm happy to keep this issue open to continue discussion around it, but don't want folks to hold out thinking we are holding out and waiting to move this from preview to GA. There were always some tradeoffs with the approach we took with filters and we feel we may be able to provide the benefits in a more flexible way with something like middleware.
// @anthonychu as FYI who is helping PM these features.
We have recently prototyped some features as part of the upcoming out of process .NET work that allows users to add some middleware to execute before a function triggers for something like token validation or whatnot. If you were to ask me today that's what I would say is the future of this scenario, and not function filters as implemented.
Honestly, that's exactly how I'd want it to work.
Not to be a downer or fail to give credit where it's due to you guys for your efforts, but for better or worse the ASP.NET Core "way" of doing dependency injection, middleware, etc. is effectively the standard in the .NET world, and Azure Functions' differences (seemingly at times just for the sake of being different) and limitations compared to ASP.NET Core have always frustrated me.
Converging Azure Functions towards the way that ASP.NET Core works is probably the best decision that could be made in terms of helping adoption and maintainability. In an ideal world, I'd love to be able to write an ASP.NET Core web API application - then simply add an Azure Functions NuGet package(s), annotate the endpoints with attributes from that package, and when I press F5 in Visual Studio, func.exe launches instead of Kestrel. If I remove the package and attributes, the app goes back to being a standard web API.
Yes. Yes. A million times Yes. At its core, Azure Functions should just be an ASP.NET Core app with an extra service (plus configuration), i.e.:
services.AddAzureFunctions(options => { ... });
@jeffhollan @anthonychu is there somewhere where work on middleware is being planned or tracked?
@jeffhollan where is our middleware?
It might be worth noticing that Azure Function in .NET 5 will have support for middleware directly. My guess would be that supporting both approaches might not be in the pipeline for the future, though I don't know of course
@MartinWickman Middlewares definitely help out with cross-cutting concerns, although they currently lack any real substance right now to make them useful. E.g., no access to the request/response and no ability to terminate the pipeline.
Also, they don't really make sense as a replacement for filters that are intended to be applied to a specific function (e.g., an authorization-type filter).
Most helpful comment
Thanks for the update @fabiocav.
Reason for why I'm looking for a filter right now is in fact to have a custom authorization done before the function code gets called. Specifically, I want to implement a role authorization provider and validate that an authenticated user is indeed allowed to call a particular function in a function app.
Since filters are, due to their lack of tread-safe nature, a no-go, is there another way in which this can be achieved?