asp.net-web-api - mvc - web api authorization filter

filtro de acción asíncrono: Async y AuthorizeAttribute en ASP.NET WEB API

Question

Tengo mi lógica de autenticación en una clase, derivada de System.Web.Http.AuthorizeAttribute (método OnAuthorization anulado). Hago una llamada a un DB desde ese método y quiero que esa llamada sea asincrónica (afortunadamente, la nueva API asíncrona ADO.NET lo permite).

Luego aplico este atributo a un controlador para que todas las llamadas pasen por el filtro de autenticación. Hasta aquí todo bien.

Pero al hacerlo, me encuentro con el siguiente problema. El marco (ASP.NET Web API) no parece saber cuáles son mis intenciones :) Parece que continúa con la ejecución de la acción del controlador antes de que finalicen los métodos OnAuthorizaion de mi filtro (regresa de la llamada asincrónica). De ahí el excepción del marco a la "proceso de solicitud finalizado antes de que se completen todas las operaciones asíncronas pendientes ..."

¿Hay alguna forma lista para tratar con eso?

¡Gracias!

PD. Mi instinto me dice que me gustaría una creación de filtro de acción personalizada. Luego necesitaré anular ExecuteActionFilterAsync y realizar allí mi autenticación manejando todo lo relacionado con la Tarea sin ayuda del marco de trabajo ...)

Answer 1

Ok, esto es lo que se me ocurrió (después de echar un vistazo debajo del capó con reflector):

public class SecurityFilterAttribute : FilterAttribute, IAuthorizationFilter
{
    public async Task<HttpResponseMessage> ExecuteAuthorizationFilterAsync(HttpActionContext actionContext, CancellationToken cancellationToken, Func<Task<HttpResponseMessage>> continuation)
    { 
        await OnAuthentication(actionContext);

        return actionContext.Response ?? await continuation();
    }

    private async Task OnAuthentication(HttpActionContext actionContext)
    {
         //some lengthy I/O operations (XXXAsync/await)
    }
}

De esta forma, al aplicarlo a un controlador / acción, toda la lógica se ejecutará en el orden correcto mientras se mantiene el hilo desbloqueado durante la E / S. No muy respetuoso con la cancelación, sin embargo. Pero debería estar bien para mis propósitos ...

De todos modos, realmente me pregunto qué hizo que los creadores de la API Web no fueran de la misma manera ... ¿Ideas?