Alterações interruptivas no .NET Core 3.1

  • Artigo

Se você estiver migrando para a versão 3.1 do .NET Core ou do ASP.NET Core, as alterações interruptivas listadas neste artigo poderão afetar seu aplicativo.

ASP.NET Core

HTTP: as alterações do SameSite do navegador afetam a autenticação

Alguns navegadores, como Chrome e Firefox, fizeram alterações interruptivas nas respectivas implementações de SameSite para cookies. As alterações afetam cenários de autenticação remota, como OpenID Connect e Web Services Federation, que precisam fazer a recusa enviando SameSite=None. No entanto, SameSite=None falha no iOS 12 e em algumas versões mais antigas de outros navegadores. O aplicativo precisa detectar essas versões e omitir SameSite.

Para conferir a discussão sobre esse problema, veja dotnet/aspnetcore#14996.

Versão introduzida

3.1 versão prévia 1

Comportamento antigo

SameSite é uma extensão padrão de rascunho de 2016 para cookies HTTP. Seu objetivo é atenuar a CSRF (solicitação intersite forjada). Ela foi projetada originalmente como um recurso que os servidores aceitariam por meio da adição de novos parâmetros. No ASP.NET Core 2.0 foi adicionado o suporte inicial para SameSite.

Novo comportamento

O Google propôs um novo padrão de rascunho que não é compatível com versões anteriores. O padrão altera o modo padrão para Lax e adiciona uma nova entrada None para a recusa. Lax é suficiente para a maioria dos cookies de aplicativo, no entanto, ele interrompe cenários entre sites, como o logon do OpenID Connect e do Web Services Federation. A maioria dos logons do OAuth não é afetada devido a diferenças na forma como a solicitação flui. O novo parâmetro None causa problemas de compatibilidade com clientes que implementaram o padrão de rascunho anterior (por exemplo, o iOS 12). O Chrome 80 incluirá as alterações. Confira Atualizações do SameSite para a linha do tempo de lançamento do produto Chrome.

O ASP.NET Core 3.1 foi atualizado para implementar o novo comportamento de SameSite. A atualização redefine o comportamento de SameSiteMode.None para emitir SameSite=None e adiciona o novo valor SameSiteMode.Unspecified para omitir o atributo SameSite. Todas as APIs de cookie agora usam Unspecified como padrão, embora alguns componentes que usam cookies definam valores mais específicos para seus cenários, como a correlação do OpenID Connect e de cookies nonce.

Para outras alterações recentes nessa área, confira HTTP: alguns padrões de cookie do SameSite foram alterados para None. No ASP.NET Core 3.0, a maioria dos padrões foi alterada de SameSiteMode.Lax para SameSiteMode.None (mas ainda usando o padrão anterior).

Motivo da alteração

Alterações de navegador e de especificação conforme a descrição no texto anterior.

Os aplicativos que interagem com sites remotos, como por meio de logon de terceiros, precisam:

Para obter instruções de teste e de detecção de navegador, confira a seção a seguir.

Determinar se você foi afetado

Teste o aplicativo Web usando uma versão do cliente que pode aceitar o novo comportamento. O Chrome, o Firefox e o Microsoft Edge Chromium têm novos sinalizadores de recursos de aceitação que podem ser usados para teste. Verifique se o aplicativo é compatível com versões de cliente mais antigas depois de aplicar os patches, principalmente o Safari. Para obter mais informações, confira Suporte a navegadores mais antigos.

Chrome

O Chrome 78 e posterior geram resultados de teste enganosos. Essas versões têm uma mitigação temporária em vigor e permitem cookies com menos de dois minutos de duração. Com os sinalizadores de teste apropriados habilitados, o Chrome 76 e 77 geram resultados mais precisos. Para testar o novo comportamento, habilite chrome://flags/#same-site-by-default-cookies. O Chrome 75 e as versões anteriores são relatados como falhando com a nova configuração None. Para obter mais informações, confira Suporte a navegadores mais antigos.

O Google não disponibiliza versões mais antigas do Chrome. No entanto, você pode baixar versões mais antigas do Chromium, o que será suficiente para o teste. Siga as instruções em Baixar Chromium.

Safari

O Safari 12 implementou estritamente o rascunho anterior e falhará se o novo valor None estiver em cookies. Isso precisa ser evitado por meio do código de detecção de navegador mostrado em Suporte a navegadores mais antigos. Teste logons no estilo do sistema operacional Safari 12 e 13, bem como baseados em WebKit usando a MSAL (Biblioteca de Autenticação da Microsoft), a ADAL (Biblioteca de Autenticação do Active Directory) ou qualquer biblioteca que você esteja usando. O problema depende da versão subjacente do sistema operacional. Sabe-se que o OSX Mojave 10.14 e o iOS 12 têm problemas de compatibilidade com o novo comportamento. A atualização para o OSX Catalina 10.15 ou iOS 13 corrige o problema. No momento, o Safari não tem um sinalizador de aceitação para testar o novo comportamento de especificação.

Firefox

O suporte do Firefox ao novo padrão pode ser testado na versão 68 e posterior aceitando-o na página about:config com o sinalizador de recurso network.cookie.sameSite.laxByDefault. Nenhum problema de compatibilidade foi relatado em versões mais antigas do Firefox.

Microsoft Edge

Embora o Microsoft Edge dê suporte ao padrão antigo SameSite, da versão 44 em diante, ele não teve problemas de compatibilidade com o novo padrão.

Microsoft Edge Chromium

O sinalizador de recurso é edge://flags/#same-site-by-default-cookies. Nenhum problema de compatibilidade foi observado em testes com o Microsoft Edge Chromium 78.

Electron

As versões do Electron incluem versões mais antigas do Chromium. Por exemplo, a versão do Electron usada pelo Microsoft Teams é a Chromium 66, que exibe o comportamento mais antigo. Execute seu próprio teste de compatibilidade com a versão do Electron que o seu produto usa. Para obter mais informações, confira Suporte a navegadores mais antigos.

Suporte a navegadores mais antigos

O padrão SameSite de 2016 determina que valores desconhecidos sejam tratados como valores SameSite=Strict. Consequentemente, todos os navegadores mais antigos que dão suporte ao padrão original podem ser interrompidos quando veem uma propriedade SameSite com o valor None. A detecção de navegador precisa ser implementada nos aplicativos Web quando o objetivo é dar suporte a esses navegadores antigos. O ASP.NET Core não implementa a detecção de navegador, pois os valores de cabeçalho de solicitação User-Agent são altamente instáveis e são alterados semanalmente. Nesse caso, um ponto de extensão na política de cookie permite adicionar uma lógica específica do User-Agent.

No Startup.cs, adicione as seguintes instruções:

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
}
Opções de recusa

A opção de compatibilidade Microsoft.AspNetCore.SuppressSameSiteNone permite que você recuse temporariamente o novo comportamento de cookie do ASP.NET Core. Adicione o seguinte JSON a um arquivo runtimeconfig.template.json no projeto:

{
  "configProperties": {
    "Microsoft.AspNetCore.SuppressSameSiteNone": "true"
  }
}
Outras versões

Em breve haverá patches relacionados ao SameSite:

  • ASP.NET Core 2.1, 2.2 e 3.0
  • Microsoft.Owin 4.1
  • System.Web (para .NET Framework 4.7.2 e versões posteriores)

Categoria

ASP.NET

APIs afetadas

Implantação

Caminho do host x86 no Windows 64 bits

MSBuild

Builds de tempo de design retornam apenas referências de pacote de nível superior

Do SDK do .NET Core 3.1.400 em diante, somente as referências de pacote de nível superior são retornadas pelo destino RunResolvePackageDependencies.

Versão introduzida

SDK do .NET Core 3.1.400

Descrição das alterações

Em versões anteriores do SDK do .NET Core, o destino RunResolvePackageDependencies criava os seguintes itens do MSBuild que continham informações do arquivo de ativos NuGet:

  • PackageDefinitions
  • PackageDependencies
  • TargetDefinitions
  • FileDefinitions
  • FileDependencies

Esses dados eram usados pelo Visual Studio para popular o nó Dependências no Gerenciador de Soluções. Mas isso pode representar uma grande quantidade de dados que não serão necessários, a menos que o nó Dependências seja expandido.

Do SDK do .NET Core versão 3.1.400 em diante, a maioria desses itens não é gerada por padrão. Somente itens do tipo Package são retornados. Se o Visual Studio precisar dos itens para popular o nó Dependências, ele lerá as informações diretamente do arquivo de ativos.

Motivo da alteração

Essa alteração foi introduzida para aprimorar o desempenho do carregamento de solução dentro do Visual Studio. Antes, todas as referências de pacote eram carregadas, o que envolvia o carregamento de muitas referências que a maioria dos usuários nunca visualizava.

Se você tiver uma lógica do MSBuild que dependa da criação desses itens, defina a propriedade EmitLegacyAssetsFileItems como true no arquivo de projeto. Essa configuração habilita o comportamento anterior em que todos os itens eram criados.

Categoria

MSBuild

APIs afetadas

N/D

SDK

Manifestos da ferramenta na pasta raiz

Windows Forms

Controles removidos

A partir do .NET Core 3.1, alguns controles do Windows Forms não estão mais disponíveis.

Descrição das alterações

A partir do .NET Core 3.1, vários controles do Windows Forms não estão mais disponíveis. Controles de substituição que têm design e suporte aprimorados foram introduzidos no .NET Framework 2.0. Os controles preteridos já foram removidos das caixas de ferramentas do designer, mas ainda estavam disponíveis para serem usados.

Os seguintes tipos não estão mais disponíveis:

Versão introduzida

3.1

Cada controle removido tem um controle de substituição recomendado. Consulte a tabela a seguir:

Controle removido (API) Substituição recomendada APIs associadas que foram removidas
ContextMenu ContextMenuStrip
DataGrid DataGridView DataGridCell, DataGridRow, DataGridTableCollection, DataGridColumnCollection, DataGridTableStyle, DataGridColumnStyle, DataGridLineStyle, DataGridParentRowsLabel, DataGridParentRowsLabelStyle, DataGridBoolColumn, DataGridTextBox, GridColumnStylesCollection, GridTableStylesCollection, HitTestType
MainMenu MenuStrip
Menu ToolStripDropDown, ToolStripDropDownMenu MenuItemCollection
MenuItem ToolStripMenuItem
ToolBar ToolStrip ToolBarAppearance
ToolBarButton ToolStripButton ToolBarButtonClickEventArgs, ToolBarButtonClickEventHandler, ToolBarButtonStyle, ToolBarTextAlign

Categoria

Windows Forms

APIs afetadas

O evento CellFormatting não é gerado quando a dica de ferramenta é mostrada

Um DataGridView agora mostra as dicas de texto e de erro de uma célula quando focalizado por um mouse e quando selecionado por meio do teclado. Se uma dica de ferramenta for mostrada, o evento DataGridView.CellFormatting não será gerado.

Descrição das alterações

Antes do .NET Core 3.1, um DataGridView que tinha a propriedade ShowCellToolTips definida como true mostrava uma dica de ferramenta para o texto e os erros da célula quando ela era focalizada por um mouse. As dicas de ferramenta não eram mostradas quando uma célula era selecionada por meio do teclado (por exemplo, usando a tecla Tab, teclas de atalho ou a navegação com as setas). Se o usuário editava uma célula e, enquanto DataGridView ainda estava no modo de edição, passava sobre uma célula que não tinha a propriedade ToolTipText definida, um evento CellFormatting era gerado para formatar o texto da célula da exibição na célula.

Para atender aos padrões de acessibilidade, começando no .NET Core 3.1, um DataGridView que tem a propriedade ShowCellToolTips definida como true mostra as dicas de ferramentas do texto e os erros de uma célula não apenas quando a célula é focalizada, mas também quando ela é selecionada por meio do teclado. Como consequência dessa alteração, o evento CellFormattingnão é gerado quando células que não têm o conjunto de propriedades ToolTipText são focalizadas enquanto DataGridView está no modo de edição. O evento não é gerado porque o conteúdo da célula focalizada é mostrado como uma dica de ferramenta em vez de ser exibido na célula.

Versão introduzida

3.1

Refatorar códigos que dependem do evento CellFormatting enquanto DataGridView está no modo de edição.

Categoria

Windows Forms

APIs afetadas

Nenhum

Confira também