Si va a migrar a la versión 3.1 de .NET Core y ASP.NET Core, es posible que los cambios importantes de este artículo afecten a la aplicación.
ASP.NET Core
HTTP: los cambios de SameSite del explorador afectan a la autenticación
Algunos exploradores, como Chrome y Firefox, han realizado cambios importantes en sus implementaciones de SameSite para las cookies. Los cambios afectan a escenarios de autenticación remota, como OpenID Connect y WS-Federation, que deben no participar mediante el envío de SameSite=None. Sin embargo, SameSite=None se interrumpe en iOS 12 y en algunas versiones anteriores de otros exploradores. La aplicación debe detectar estas versiones y omitir SameSite.
SameSite es una extensión de proyecto de norma de 2016 para cookies HTTP. Su objetivo era mitigar la falsificación de solicitud entre sitios (CSRF). Originalmente se diseñó como una característica en la que los servidores participaban si agregaban los nuevos parámetros. ASP.NET Core 2.0 agregó compatibilidad inicial con SameSite.
Comportamiento nuevo
Google ha propuesto un nuevo proyecto de norma que no es compatible con versiones anteriores. La norma cambia el modo predeterminado a Lax y agrega una nueva entrada None para no participar. Lax basta para la mayoría de las cookies de aplicación, aunque interrumpe escenarios entre sitios como el inicio de sesión de OpenID Connect y WS-Federation. La mayoría de los inicios de sesión de OAuth no se ven afectados debido a las diferencias respecto al flujo de la solicitud. El nuevo parámetro None origina problemas de compatibilidad con los clientes que han implementado el proyecto de norma anterior (por ejemplo, iOS 12). Chrome 80 va a incluir los cambios. Vea Actualizaciones de SameSite para conocer la escala de tiempo de lanzamiento del producto Chrome.
ASP.NET Core 3.1 se ha actualizado para implementar el nuevo comportamiento de SameSite. La actualización vuelve a definir el comportamiento de SameSiteMode.None para emitir SameSite=None y agrega un nuevo valor SameSiteMode.Unspecified para omitir el atributo SameSite. Todas las API de cookies ahora tienen como valor predeterminado Unspecified, aunque algunos componentes que usan cookies establecen valores más específicos en sus escenarios, como la correlación de OpenID Connect y las cookies nonce.
Para obtener instrucciones para las pruebas y la detección de exploradores, vea la sección siguiente.
Procedimiento para determinar la afectación
Pruebe la aplicación web con una versión cliente que pueda participar en el nuevo comportamiento. Chrome, Firefox y Microsoft Edge Chromium tienen nuevas marcas de características de participación que se pueden usar para las pruebas. Compruebe que la aplicación es compatible con versiones cliente anteriores después de haber aplicado las revisiones, especialmente en el caso de Safari. Para obtener más información, vea Compatibilidad con exploradores anteriores.
Chrome
Chrome 78 y versiones posteriores generan resultados de prueba engañosos. Esas versiones tienen aplicada una mitigación temporal y permiten las cookies con menos de dos minutos de antigüedad. Con las marcas de prueba adecuadas habilitadas, Chrome 76 y 77 generan resultados más precisos. Para probar el nuevo comportamiento, cambie chrome://flags/#same-site-by-default-cookies a habilitado. Se ha notificado que en Chrome 75 y versiones anteriores se produce un error con el nuevo valor None. Para obtener más información, vea Compatibilidad con exploradores anteriores.
Google no tiene disponibles versiones anteriores de Chrome. Sin embargo, puede descargar versiones anteriores de Chromium, lo que basta para las pruebas. Siga las instrucciones de Descargar Chromium.
Safari 12 ha implementado estrictamente el proyecto anterior, con lo que se produce un error si se detecta el nuevo valor None en las cookies. Esto se debe evitar con el código de detección de exploradores mostrado en Compatibilidad con exploradores anteriores. Asegúrese de probar Safari 12 y 13, así como los inicios de sesión de estilo sistema operativo basados en WebKit mediante la Biblioteca de autenticación de Microsoft (MSAL), la Biblioteca de autenticación de Active Directory (ADAL) o cualquier biblioteca que esté usando. El problema depende de la versión del sistema operativo subyacente. Se sabe que OSX Mojave 10.14 e iOS 12 tienen problemas de compatibilidad con el nuevo comportamiento. La actualización a OSX Catalina 10.15 o iOS 13 corrige el problema. Safari no tiene actualmente una marca de participación para probar el comportamiento de la nueva especificación.
Firefox
La compatibilidad de Firefox con la nueva norma se puede probar en la versión 68 y posteriores mediante la participación en la página about:config con la marca de características network.cookie.sameSite.laxByDefault. No se han comunicado problemas de compatibilidad en versiones anteriores de Firefox.
Microsoft Edge
Aunque Microsoft Edge admite la antigua norma SameSite, a partir de la versión 44 no tiene ningún problema de compatibilidad con la nueva.
Microsoft Edge Chromium
La marca de características es edge://flags/#same-site-by-default-cookies. No se ha observado ningún problema de compatibilidad al realizar pruebas con Microsoft Edge Chromium 78.
Electron
Las versiones de Electron incluyen versiones anteriores de Chromium. Por ejemplo, la versión de Electron usada por Microsoft Teams es Chromium 66, que exhibe el comportamiento anterior. Realice sus propias pruebas de compatibilidad con la versión de Electron que use el producto. Para obtener más información, vea Compatibilidad con exploradores anteriores.
Compatibilidad con exploradores anteriores
La norma SameSite de 2016 obligaba a tratar los valores desconocidos como valores SameSite=Strict. Por tanto, los exploradores anteriores que admiten la norma original se pueden interrumpir al detectar una propiedad SameSite con un valor de None. Las aplicaciones web deben implementar la detección de exploradores si pretenden admitir estos exploradores antiguos. ASP.NET Core no implementa la detección de exploradores automáticamente porque los valores de encabezado de solicitud User-Agent son muy inestables y cambian semanalmente. En su lugar, un punto de extensión de la directiva de cookies permite agregar lógica específica de User-Agent.
En Startup.cs, agregue el siguiente código:
private void CheckSameSite(HttpContext httpContext, CookieOptions options)
{
if (options.SameSite == SameSiteMode.None)
{
var userAgent = httpContext.Request.Headers["User-Agent"].ToString();
// TODO: Use your User Agent library of choice here.
if (/* UserAgent doesn't support new behavior */)
{
options.SameSite = SameSiteMode.Unspecified;
}
}
}
public void ConfigureServices(IServiceCollection services)
{
services.Configure<CookiePolicyOptions>(options =>
{
options.MinimumSameSitePolicy = SameSiteMode.Unspecified;
options.OnAppendCookie = cookieContext =>
CheckSameSite(cookieContext.Context, cookieContext.CookieOptions);
options.OnDeleteCookie = cookieContext =>
CheckSameSite(cookieContext.Context, cookieContext.CookieOptions);
});
}
public void Configure(IApplicationBuilder app)
{
// Before UseAuthentication or anything else that writes cookies.
app.UseCookiePolicy();
app.UseAuthentication();
// code omitted for brevity
}
Modificadores de no participación
El modificador de compatibilidad Microsoft.AspNetCore.SuppressSameSiteNone permite no participar temporalmente en el nuevo comportamiento de cookies de ASP.NET Core. Agregue el siguiente JSON a un archivo runtimeconfig.template.json del proyecto:
Las compilaciones en tiempo de diseño solo devuelven referencias de paquete de nivel superior
A partir del SDK de .NET Core 3.1.400, el destino de RunResolvePackageDependencies solo devuelve las referencias de paquete de nivel superior.
Versión introducida
SDK 3.1.400 de .NET Core
Descripción del cambio
En versiones anteriores del SDK de .NET Core, el destino RunResolvePackageDependencies creó los siguientes elementos de MSBuild que contenían información del archivo de recursos de NuGet:
PackageDefinitions
PackageDependencies
TargetDefinitions
FileDefinitions
FileDependencies
Visual Studio usa estos datos para rellenar el nodo Dependencias en el explorador de soluciones, pero puede ser una gran cantidad de datos y estos no son necesarios a menos que se expanda el nodo Dependencias.
A partir de la versión 3.1.400 del SDK de .NET Core, la mayoría de estos elementos no se generan de forma predeterminada. Solo se devuelven los elementos de tipo Package. Si Visual Studio necesita que los elementos rellenen el nodo dependencias, lee la información directamente del archivo de recursos.
Motivo del cambio
Este cambio se presentó para mejorar el rendimiento de carga de la solución dentro de Visual Studio. Anteriormente, todas las referencias de paquete se cargaban, lo que implicaba la carga de muchas referencias que la mayoría de los usuarios nunca veían.
Acción recomendada
Si tiene lógica de MSBuild que depende de la creación de estos elementos, establezca la propiedad EmitLegacyAssetsFileItems en true en el archivo del proyecto. Esta configuración habilita el comportamiento anterior en el que se crean todos los elementos.
A partir de .NET Core 3.1, algunos controles de Windows Forms ya no están disponibles.
Descripción del cambio
A partir de .NET Core 3.1, varios controles de Windows Forms ya no están disponibles. Los controles de reemplazo, con un mejor diseño y soporte técnico, se introdujeron en .NET Framework 2.0. Los controles en desuso se eliminaron previamente de los cuadros de herramientas del diseñador, pero todavía estaban disponibles para su uso.
El evento CellFormatting no se produce si se muestra información en pantalla.
Ahora, DataGridView muestra información en pantalla del texto y los errores de una celda cuando se mantiene el mouse sobre ella y cuando se selecciona mediante el teclado. Si se muestra información en pantalla, no se produce el evento DataGridView.CellFormatting.
Descripción del cambio
Antes de .NET Core 3.1, un elemento DataGridView con la propiedad ShowCellToolTips establecida en true mostraba información en pantalla del texto y los errores de una celda cuando se mantenía el mouse sobre ella. La información en pantalla no se mostraba si la celda se seleccionaba mediante el teclado (por ejemplo, mediante la tecla Tab, teclas de método abreviado o las teclas de dirección). Si el usuario editaba una celda y, luego, mientras el elemento DataGridView aún estaba en modo de edición, mantenía el mouse sobre una celda que no tenía establecida la propiedad ToolTipText, se producía un evento CellFormatting para dar formato al texto de la celda para su presentación en ella.
Para cumplir los estándares de accesibilidad, a partir de .NET Core 3.1, un elemento DataGridView que tenga la propiedad ShowCellToolTips establecida en true muestra información en pantalla del texto y los errores de una celda no solo cuando se mantiene el mouse sobre la celda, sino también cuando se selecciona mediante el teclado. Como consecuencia de este cambio, el evento CellFormattingno se produce cuando se mantiene el mouse sobre las celdas que no tienen establecida la propiedad ToolTipText mientras DataGridView está en modo de edición. El evento no se produce porque el contenido de la celda se muestra como información en pantalla en lugar de mostrarse en la celda.
Versión introducida
3.1
Acción recomendada
Refactorice cualquier código que dependa del evento CellFormatting mientras DataGridView está en modo de edición.
El origen de este contenido se puede encontrar en GitHub, donde también puede crear y revisar problemas y solicitudes de incorporación de cambios. Para más información, consulte nuestra guía para colaboradores.
Comentarios de .NET
.NET es un proyecto de código abierto. Seleccione un vínculo para proporcionar comentarios:
Cree una interfaz de usuario con enlace de datos. La interfaz de usuario se actualiza automáticamente en función de los datos más recientes, mientras que los datos se actualizan en respuesta a los cambios en la interfaz de usuario.