Skip to content
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

Allow Invocation Filters to Short Circuit / Provide Response #1314

Open
mathewc opened this issue Aug 22, 2017 · 15 comments

Comments

Projects
None yet
@mathewc
Copy link
Contributor

commented Aug 22, 2017

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)

@MikeStall

This comment has been minimized.

Copy link
Contributor

commented Aug 28, 2017

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.

@mathewc

This comment has been minimized.

Copy link
Contributor Author

commented Sep 12, 2017

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.

@apmorton

This comment has been minimized.

Copy link

commented Oct 30, 2017

+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");
        });
}
@tjgalama

This comment has been minimized.

Copy link

commented May 14, 2018

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
@mathewc

This comment has been minimized.

Copy link
Contributor Author

commented May 14, 2018

The status is as the issue description states - we haven't addressed this issue yet.

@mathewc mathewc closed this May 14, 2018

@sinapis

This comment has been minimized.

Copy link

commented May 22, 2018

Why is this issue closed if it hasn't been addressed yet?

@paulbatum

This comment has been minimized.

Copy link
Member

commented May 22, 2018

I'm going to assume that @mathewc did not intend to close this issue and reopen.

@paulbatum paulbatum reopened this May 22, 2018

@mathewc

This comment has been minimized.

Copy link
Contributor Author

commented May 22, 2018

Sorry for accidentally closing this guys

@getkanchan

This comment has been minimized.

Copy link

commented Aug 31, 2018

+1 on a feature like this.
Any updates ?

@sinapis

This comment has been minimized.

Copy link

commented Sep 2, 2018

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.

@ginomessmer

This comment has been minimized.

Copy link

commented Sep 5, 2018

+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.

@patricknolan

This comment has been minimized.

Copy link

commented Sep 27, 2018

+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.

@adrianknight89

This comment has been minimized.

Copy link

commented Nov 17, 2018

@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.

@artmasa

This comment has been minimized.

Copy link

commented Mar 30, 2019

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

@SeanFeldman

This comment has been minimized.

Copy link

commented Apr 18, 2019

Could really use this feature for what doing now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.