azure-webjobs-sdk
azure-webjobs-sdk copied to clipboard
Azure
Allow Invocation Filters to Short Circuit / Provide Response
Provide a way for filters to specify a result (e.g. in a validation filter scenario, allow the filter to specify the HttpResponse for a 400 BadRequest).
As part of this we should also consider adding a way for filters to short circuit/skip the function invocation, e.g. as ASP.NET filters allow via a Cancel property on the context)
One challenge we have beyond ASP.Net is that ASP.Net is http-specific; whereas our filters are trigger agnostic. So providing "400" on a QueueTrigger doesn't make sense. This feature is tied to the trigger mechanism. This specific example (400) will likely involve cooperation from the Http Trigger extension.
In one prototype (code here) I experimented with a custom exception type FunctionResultException which allows a function or filter to specify the return value for the function (in the case of an http function the http response).
Initially I had prototyped with ASP.NET's HttpResponseException, but in .NET Core that went away. So if we want to use an exception model we'd define our own.
+1 on a feature like this. Without the ability to provide http responses through exceptions, or otherwise wrap function execution and provide a http response it is very difficult to cleanly handle certain cross cutting validation concerns - especially when migrating code from a traditional app service to a functions app.
In the meantime, I have emulated the required behavior with minimal changes to my code by wrapping the body of each function that might throw HttpResponseException with a method like the following:
private static async Task<HttpResponseMessage> HandleHttpExceptions(Func<Task<HttpResponseMessage>> action)
{
try
{
return await action();
}
catch (HttpResponseException e)
{
return e.Response;
}
}
[FunctionName("MyFunction")]
public static async Task<HttpResponseMessage> MyFunction(
[HttpTrigger(AuthorizationLevel.Anonymous, "get")]
HttpRequestMessage req,
TraceWriter log)
{
return await HandleHttpExceptions(async () =>
{
EnsureUserInRole(req, "Admin"); // this may throw HttpResponseException
// complex logic here
return req.CreateResponse(HttpStatusCode.OK, "ok");
});
}
Im currently trying to migrate our WebApi to function apps for effective granular scaling. One of the things we need to migrate are the several types of middleware (intercepting HttpRequests for authentication, authorization, exceptionpromotion). For this we think we need to use IFunctionFilter derived types .(?) Can anyone tell what the current status is regarding a solution for:
- Short circuiting a function (cancelling sequential function filters and the function itself)
- setting an adequate 'result' object in the FunctionExecutingContext, FunctionExecutedContext and/or FunctionExceptionContext
The status is as the issue description states - we haven't addressed this issue yet.
I'm going to assume that @mathewc did not intend to close this issue and reopen.
We would also like an update and if possible provide your recommended way of handling cross cutting concerns such as authentication until this feature is implemented.
+1 I second that. This seems pretty essential, especially when it comes down to API services that are being built on top of Azure Functions.
+1 - I agree that without the ability to return a certain result object, such as BadRequestObjectResult based on the exception, the FunctionExceptionFilterAttribute isn't overly useful.
@MikeStall +1. No progress since 2017? I'm pretty sure many people want a feature like this. I need to send a proper response message when authentication tokens are not valid. Filters are a great fit for this purpose.
Take a look at this for auth purposes: https://blog.darkloop.com/post/bringing-authorizeattribute-to-net-azure-functions-v2 Yes, exceptions are thrown, but the authentication flow happens with correct status codes sent to the caller
+1 for this
This is a much needed feature coming across from the many additional features that dotnet core api filters provide.
Will 2020 be the year we get this? This feature would reduce a lot of unnecessary boilerplate in our functions projects.
Adding another +1 for this! I've built Web APIs using .NET and now .NET Core for years and Exception Filters make error handling so so so easy. I am dreading wrapping the code at the function level for every API endpoint as we consider moving our platform serverless.
Logged https://github.com/Azure/azure-functions-host/issues/6445 just in case it gets more visibility over there. Without some way of affecting the resulting output in some way, it's not overly useful for things like validation which is mentioned explicitly as one of the scenarios in the wiki on filters
+1, Even am counting on this.
So many duplicate threads on the same issue. Although IFunctionInvocationFilter, IFunctionExceptionFilter APis are obsoleted, shall We can consider using this until this ticket is addressed?
Three years on and still no progress? This is really NOT optional, it needs doing.
So many duplicate threads on the same issue. Although IFunctionInvocationFilter, IFunctionExceptionFilter APis are obsoleted, shall We can consider using this until this ticket is addressed?
@vijaymarada the only reason they are marked Obsolete is that there's no equivalent [Preview] attribute they could use. My understanding from interacting with the team is that they have every intention to ship the feature as stable at some point.
There's absolutely no way it's been 3 years and this still isn't a feature. You guys are like trying to come out with your own car on Azure and it's released without a defroster system for the windshield after years. 🤣
Any update on it or is there an alternative approach that can help us for now? 😖
