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.