Compartir a través de

Cambios importantes en .NET Core 3.1

  • Artículo

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.

Para obtener información sobre esta incidencia, vea dotnet/aspnetcore#14996.

Versión introducida

3.1, versión preliminar 1

Comportamiento anterior

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 otros cambios recientes en esta área, vea HTTP: Cambio a Ninguno de algunos valores predeterminados de cookie de SameSite. En ASP.NET Core 3.0, la mayoría de los valores predeterminados se han cambiado de SameSiteMode.Lax a SameSiteMode.None, aunque se sigue usando la norma anterior.

Motivo del cambio

Cambios en el explorador y la especificación, como se ha explicado en el texto anterior.

Las aplicaciones que interactúan con sitios remotos, por ejemplo mediante inicio de sesión de terceros, necesitan:

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

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:

{
  "configProperties": {
    "Microsoft.AspNetCore.SuppressSameSiteNone": "true"
  }
}
Otras versiones

Próximamente habrá revisiones de SameSite relacionadas para:

  • ASP.NET Core 2.1, 2.2 y 3.0
  • Microsoft.Owin 4.1
  • System.Web (para .NET Framework 4.7.2 y posterior)

Category

ASP.NET

API afectadas

Implementación

Ruta de acceso de host x86 en Windows de 64 bits

MSBuild

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.

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.

Categoría

MSBuild

API afectadas

N/D

SDK

Manifiestos de herramienta en la carpeta raíz

Windows Forms

Controles eliminados

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.

Los siguientes tipos ya no están disponibles:

Versión introducida

3.1

Cada control eliminado tiene un control de reemplazo recomendado. Consulte la tabla siguiente:

Control eliminado (API) Reemplazo recomendado API asociadas que se han eliminado
ContextMenu ContextMenuStrip
DataGrid DataGridView DataGridCell, DataGridRow, DataGridTableCollection, DataGridColumnCollection, DataGridTableStyle, DataGridColumnStyle, DataGridLineStyle, DataGridParentRowsLabel, DataGridParentRowsLabelStyle, DataGridBoolColumn, DataGridTextBox, GridColumnStylesCollection, GridTableStylesCollection, HitTestType
MainMenu MenuStrip
Menú ToolStripDropDown, ToolStripDropDownMenu MenuItemCollection
MenuItem ToolStripMenuItem
ToolBar ToolStrip ToolBarAppearance
ToolBarButton ToolStripButton ToolBarButtonClickEventArgs, ToolBarButtonClickEventHandler, ToolBarButtonStyle, ToolBarTextAlign

Categoría

Windows Forms

API afectadas

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

Refactorice cualquier código que dependa del evento CellFormatting mientras DataGridView está en modo de edición.

Categoría

Windows Forms

API afectadas

None

Vea también