Action Filters en ASP.Net MVC

Bienvenidos a mi tutorial de los ActionFilter. Soy Juan Luis y en este vídeo veremos qué es un filtro de acción,cómo podemos usarlo y qué opciones tenemos de usarlo. 

Para este ejemplo estoy usando el IDE Visual Studio, Un proyecto MVC en ASP.NET. Y una base de datos montada en SQL Server con una sola tabla.

Empecemos.

 

Un Action Filter, o filtro de acción, es una función o componente que nos permite una modificación del comportamiento lógico de nuestros métodos de acción. En concreto nos permite insertar funciones o código, antes o después de la llamada a dicho método.

Por ejemplo, si lo que queremos es insertar un nuevo registro en nuestra Base de Datos, podremos ejecutar un método antes de su inserción, como el de comprobar los parámetros, comprobar si el usuario está logueado, hacer una breve espera…

En .Net podemos usar ciertos tipos de Filtros de acción ya predefinidos por el framework, y seguramente hayamos usado algunos. Algunos de los filtros de acción más famosos se recogen en tres tipos: filtros de Autorización, de Cache y de Error. Estos son los filtros más comunes y comenzaremos.

Filtros de Autorización 

Los filtros de autorización restringen el acceso a un rol específico. Esto nos sirve para elegir qué tipo de usuarios accederán a ciertas partes de la página como paneles de administración, zonas con Login requerido.

Filtros de Cache 

Los filtros de Cache almacenan un resultado de un método durante un periodo de tiempo, siendo útil para no tener que volver a procesar la lógica del método cada vez que una petición entra a nuestro servidor. Si por ejemplo un usuario nos pide cierta información concreta almacenada en la base de datos como un horario, la primera vez la solicitud a la base se procesará, pero a partir de ahí si otro usuario o el mismo repite la petición, no se volverá a procesar la llamada sino que el resultado de la primera llamada se guardará hasta que el tiempo de Caché expire, volviendo a procesar la acción si es solicitado de nuevo. 

Esto nos serviría para acciones concretas cuyo resultado se repite en un lapso de tiempo, resultando una mejora en el rendimiento de nuestro servidor y en una mayor velocidad en la respuesta. 

 

Filtros de Error 

Este tipo de filtros se encarga de manejar y redireccionar peticiones en las que ocurre una excepción, con la funcionalidad también de redireccionar a una vista de error. Este filtro nos sería útil para no llevar al usuario a una página muerta 

ValidateAntiForgeryToken 

Con este filtro podemos validar la sesión de quién nos envía la petición, autenticando el token que previamente hemos enviado al usuario para verificar su autenticidad. Principalmente sirve para filtrar el acceso a ciertos usuarios que se hayan validado o hayan obtenido. 

A parte de estos filtros predefinidos, podemos crear los nuestros propios personalizados, dotándolos de la funcionalidad que queramos. Este tipo de filtros nos da la posibilidad de añadir funciones en uno de los 4 puntos de la ejecución, antes de la llamada a la acción, después de la llamada pero antes del resultado de la ejecución, justo antes del renderizado de la vista y después del render de la vista.

Bien, pasando a un ejemplo práctico, vamos a ver cómo se comportan estos Action Filters en la práctica. 

Una vez abierto el proyecto adjunto vemos la estructura de directorios formada para MVC. 

Tenemos dos vistas montadas en el directorio Users en Views conectados a su controlador. También usamos un repositorio casero de Usuarios, mapeado por EntityFramework con su respectivo Nuget instalado. La base de datos corre en un SQL Server de fondo con una sencilla tabla en la base. Esta es Users.

 

Bien, empecemos con el filtro de cache. CacheOutput como ya dije repite un mismo resultado almacenado cada cierto tiempo sin volver a procesarlo por cada petición. Para usarlo nos inventaremos que estamos en una página de apuestas y que queremos ver la cuota de una apuesta de fútbol. Para ello simularemos que contactamos con una API.

Esta cada vez que la llamemos nos generará un valor aleatorio de 1 a 15, un poco irreal para una apuesta pero lo que queremos ver es cómo se comporta.

Para usar el sistema de Caching, tenemos que añadir esta línea en la acción de nuestro controlador y posteriormente llamar al método del repositorio, retornando un valor aleatorio. Con esto sólo no nos bastaría.

Establecemos que la cache expire en diez segundos, y vemos que pasa. 

Si llamamos durante ese intervalo de 10 segundos el método nos devolverá el mismo valor una y otra vez ya que está almacenado en la caché del servidor, procesándolo por supuesto una única vez en la primera llamada.

Pasando los diez segundos volvemos a tener otro valor y así en franjas de otros 10 segundos. Este filtro es muy usado en el mundo web, ya que reducir el procesamiento lógico del servidor ante multitud de peticiones es crucial de cara al rendimiento y al coste de mantenimiento. 

Otras situaciones en las que podemos usar el OutputCache son durante la carga de imágenes o archivos que no cambian tan a menudo.

Comentando otro ActionFilter tenemos HandleError, el filtro para controlar Excepciones . Para usar este filtro nos simularemos un error de servidor interno, usando también el repositorio.

Cuando el usuario entre a una página en la que parte de la lógica resulte ser errónea, y por ende esta lance una excepción, redirigiremos al usuario a una página segura. Ya hemos visto este tipo de páginas varias veces por internet. Insertaremos un código que provocará una excepción en el servidor y volver a la acción para después leer qué debería hacer.

Añadimos este nodo en web.config para habilitar el sistema de errores, y el ActionFilter de HandleError en nuestra acción del controlador, junto al parámetro View, que es la vista a redireccionar.

Viéndolo en el caso práctico… Si nos encontramos con uno de estos errores veriamos una pagina muy parecida a esta. Página que nos indica que algo no va bien con el servidor.

Viendo como funcionaría este filtro en acción, usando el link que hemos creado, link que redirecciona a una excepción genérica no controlada, redireccionamos a la sencilla página que hemos creado o a la que queramos. En este caso sería una página personalizada con varios enlaces para ayudar al usuario a que vuelva a navegar. Y todo con tan sólo activar el modo en webConfig y usar el tag. 

 Es muy importante tener estas excepciones controladas y bien dirigidas, ya que mostrar avisos del servidor puede terminar siendo beneficioso para los hackers que estén en fase de búsqueda de vulnerabilidades. 

Pasando a nuestros filtros personalizados, vamos a ver cómo podemos insertar métodos durante la ejecución de la lógica. De las cuatro fases que hemos visto, probaremos con OnActionExecuting.

Con esta función de los filters, podemos comprobar si la contraseña a insertar cumple ciertos requisitos como su longitud, que de otro modo no nos validaría. Bastaría insertar la etiqueta en la acción del controlador y añadir la lógica en la clase creada. De esta forma nos aseguramos que el usuario no pueda insertar contraseñas fuera de los requisitos de nuestra aplicación.

Este sería el único filtro que me interesa a la hora de solucionar este problema en la comprobación del password, pero si quisiéramos usar los otros tres, bastaría con usar este mismo código pero reemplazandolo por los otros objetos.

Bueno, hasta aquí mi presentación de los Action Filters, herramienta bastante útil que nos sacará más de una vez de algún apuro a la hora de encaminarnos en rutas de la lógica de nuestro proyecto, pudiendo interceptar peticiones de diversas formas.

Espero que os haya gustado y hasta la próxima!

 

Autor: Juan Luis Sánchez Ángeles

Curso: Microsoft MCSA Web Applications + Microsoft MCSD App Builder + Xamarin 

Centro: Tajamar 

Año académico: 2018-2019

Recursos utilizados:

Github (Base de datos en PostJL.txt)

https://github.com/jltajamar/PostJLProyect

LinkedIn:

https://www.linkedin.com/in/juan-luis-s%C3%A1nchez-%C3%A1ngeles-a41b36119/