Autor en Google+
Saltar al contenido

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript... y lo que venga ;)

15 años online

el blog de José M. Aguilar

Inicio El autor Contactar

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web
ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript...

¡Microsoft MVP!
Syncfusion UI Components for Blazor
martes, 9 de febrero de 2021
ASP.NET Core

Hoy voy a hablar de un cambio introducido en el framework hace ya algunos años, que, al menos en mi caso, pasó totalmente desapercibido en su momento y durante bastante tiempo después. Y he pensado que sería buena idea publicar sobre ello porque, como este mundo es así de grande, seguro que hay todavía algún despistado al que podría estar afectando a día de hoy y ni siquiera se ha dado cuenta :)

Como recordaréis, los atributos de validación [EmailAddress] y [Url], presentes en el espacio de nombres System.ComponentModel.DataAnnotations, los hemos utilizado durante años para asegurar que determinados valores de entrada eran direcciones de correo electrónico y URLs válidas, respectivamente:

public class Blog
{
    [Required, EmailAddress]
    public string ContactEmail { get; set; }
    [Required, Url]
    public string Url { get; set; }
}

Desde el principio de los tiempos, aún en ASP.NET "clásico", ambos atributos de validación utilizaban internamente complejas expresiones regulares para comprobar los valores, y la verdad es que funcionaban relativamente bien. Nuestras aplicaciones podían confiar en que valores que hubieran superado dichas validaciones serían, como mínimo, sintácticamente correctos y buenos candidatos a ser direcciones de correo o URLs válidas.

Pues bien, desde la llegada de NET 4.7.2, y luego en .NET Core, [EmailAddress] y [Url] ya no funcionan así. En palabras casi textuales del equipo de desarrollo, el objeto de estos dos atributos es simplemente prevenir algunos errores básicos al teclear, y no contemplar todas las posibilidades definidas en las respectivas RFC que describen la sintaxis de dichos valores.

Así pues, desde .NET 4.7.2 y en .NET Core, el comportamiento estándar es:

  • [EmailAddress] dará por válido cualquier valor que sea nulo o contenga un único carácter arroba "@" en una posición que no sea la primera ni la última. Eso es todo :-/ Por ejemplo, la validación podrá ser superada por valores como "hola@hola" o "_@!".

  • [Url] considerará correctos los valores que sean nulos o simplemente comiencen por "http://", "https://" o "ftp://". Por ejemplo, serán valores válidos "https://esto no es una url" o simplemente "http://".

En resumen, si tenéis aplicaciones donde usáis estos atributos para validar los datos de entrada, y en vuestro contexto es importante que éstos sean totalmente correctos, deberíais revisarlas:

  • En .NET 4.7.2 y superiores, es posible volver al comportamiento anterior (es decir, a que se utilice internamente la expresión regular) estableciendo el valor del configuración "DisableRegEx" a false en el archivo de configuración.

    <appSettings>
       <add key="dataAnnotations:dataTypeAttribute:disableRegEx" value="false"/>
    </appSettings>
    

    Aunque ojo, porque esto podría hacer al sistema vulnerable a ataques de denegación de servicio, que fue el motivo por lo que se introdujo este cambio.

  • En .NET Core, tendréis que implementar por vuestra cuenta la lógica extra para validarlos de forma apropiada, ya sea mediante expresiones regulares o bien por otros medios.

En fin, son cosas de la evolución que a veces se nos pasan por alto, pero que debemos prestarles atención en algún momento.

Publicado en Variable not found.

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

Aún no hay comentarios, ¡sé el primero!

Artículos relacionados: