Azure-webjobs-sdk: FunctionInvocationFilterAttribute preview

[giotab]

FunctionInvocationFilterAttribute has been in "preview" and hence "obsolete" since 2018.

Are there alternatives or plans to finalize it?

Repro steps

1. Create azure functions project in dotnet

2. Implement FunctionInvocationFilterAttribute

Expected behavior

The attribute filter has been in "preview" and hence "obsolete" since 2018. Are there any plans to finalize it?

Actual behavior

Implementing and using FunctionInvocationFilterAttribute does not complain about obsolete class.

Known workarounds

Ignore warning

Related information

File can be found here

[jamesharling]

Also interested in an update on this. The limited functionality provided by the current Filters API and a lack of DI support means it's extremely difficult to bring HTTP APIs hosted by Azure Functions in line with those in App Services. For example, you cannot change the response code of an HTTP trigger using Filters, which is the the ideal place for cross-cutting concerns that do exactly this (auth, validation, etc.)

[giotab]

Also interested in an update on this. The limited functionality provided by the current Filters API and a lack of DI support means it's extremely difficult to bring HTTP APIs hosted by Azure Functions in line with those in App Services. For example, you cannot change the response code of an HTTP trigger using Filters, which is the the ideal place for cross-cutting concerns that do exactly this (auth, validation, etc.)

@jamesharling
We are using the attribute for authentication actually.
Although dependency injection is not supported through constructors/parameters, you can still use something like
request.HttpContext.RequestServices.GetRequiredService<ITokenValidator>()
(ITokenValidator is interface we created).

As for modifying the response etc., we have something like this

var claims = tokenValidator.ValidateTokenAndGetClaimsAsync(request.Headers, validAudiences).Result;

if (claims == null)
{
    request.HttpContext.Response.StatusCode = 401;
    request.HttpContext.Response.Body.FlushAsync();
    request.HttpContext.Response.Body.Close();
    throw new UnauthorizedException();
}

It works nicely, but it is annoying that it is marked as Preview for two years and hence all compilers complain about it.

[GeraltTheWolf]

Is there any progress on this issue?

[v-anvari]

Please find the discussion in #1284

[gwinnem]

OMG I have been waiting for so long, and im still writing boiler plate code in each function.. When can the community expect someone to take action and bring this issue to an end ?