Ler em inglês

Partilhar via


Alterações significativas no .NET Core 3.1

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

ASP.NET Core

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

Alguns navegadores, como o Chrome e o Firefox, fizeram alterações significativas nas suas implementações de SameSite cookies. As alterações afetam cenários de autenticação remota, como OpenID Connect e WS-Federation, que devem desativar enviando SameSite=None. No entanto, SameSite=None quebra no iOS 12 e algumas versões mais antigas de outros navegadores. O aplicativo precisa farejar essas versões e omitir SameSite.

Para discussão sobre esta questão, consulte dotnet/aspnetcore#14996.

Versão introduzida

3.1 Pré-visualização 1

Comportamento antigo

SameSite é uma extensão padrão preliminar de 2016 para cookies HTTP. Destina-se a mitigar a falsificação de solicitação entre sites (CSRF). Isso foi originalmente projetado como um recurso que os servidores optariam adicionando os novos parâmetros. ASP.NET Core 2.0 adicionou suporte inicial para SameSite.

Novo comportamento

O Google propôs um novo projeto de padrão que não é compatível com versões anteriores. O padrão altera o modo padrão e Lax adiciona uma nova entrada None para desativar. Lax suficiente para a maioria dos cookies de aplicativos; no entanto, ele quebra cenários entre sites, como OpenID Connect e login WS-Federation. A maioria dos logins OAuth não é afetada devido a diferenças na forma como a solicitação flui. O novo None parâmetro causa problemas de compatibilidade com clientes que implementaram o rascunho anterior do padrão (por exemplo, iOS 12). O Chrome 80 incluirá as alterações. Consulte Atualizações do SameSite para obter a cronologia de lançamento do produto Chrome.

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

Para outras alterações recentes nesta área, consulte HTTP: Alguns padrões de cookies do SameSite foram alterados para Nenhum. 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).

Razão para a alteração

Alterações no navegador e nas especificações, conforme descrito no texto anterior.

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

  • Teste esses cenários em vários navegadores.
  • Aplique a mitigação de deteção de navegador da política de cookies discutida em Suporte a navegadores mais antigos.

Para obter instruções de teste e deteção do navegador, consulte a seção a seguir.

Determinar se você é afetado

Teste seu aplicativo Web usando uma versão de cliente que possa optar pelo novo comportamento. Chrome, Firefox e Microsoft Edge Chromium têm novos sinalizadores de recursos de aceitação que podem ser usados para testes. Verifique se a sua aplicação é compatível com versões de cliente mais antigas depois de aplicar os patches, especialmente o Safari. Para obter mais informações, consulte Suporte a navegadores mais antigos.

Chrome

O Chrome 78 e versões posteriores produzem resultados de testes enganosos. Essas versões têm uma mitigação temporária em vigor e permitem cookies com menos de dois minutos de idade. Com os sinalizadores de teste apropriados ativados, o Chrome 76 e 77 produzem resultados mais precisos. Para testar o novo comportamento, alterne chrome://flags/#same-site-by-default-cookies para habilitado. O Chrome 75 e versões anteriores apresentam falhas com a nova None configuração. Para obter mais informações, consulte Suporte a navegadores mais antigos.

A Google não disponibiliza versões mais antigas do Chrome. Você pode, no entanto, baixar versões mais antigas do Chromium, o que será suficiente para testes. Siga as instruções em Download Chromium.

Safari

O Safari 12 implementou estritamente o rascunho anterior e falha se vir o novo None valor nos cookies. Isso deve ser evitado através do código de deteção do navegador mostrado em Suporte a navegadores mais antigos. Certifique-se de testar o Safari 12 e 13, bem como logins baseados em WebKit, no estilo do sistema operacional, usando a Biblioteca de Autenticação da Microsoft (MSAL), a Biblioteca de Autenticação do Ative Directory (ADAL) ou qualquer biblioteca que você esteja usando. O problema depende da versão subjacente do sistema operacional. OSX Mojave 10.14 e iOS 12 são conhecidos por terem problemas de compatibilidade com o novo comportamento. A atualização para o OSX Catalina 10.15 ou iOS 13 corrige o problema. Atualmente, o Safari não tem um sinalizador de aceitação para testar o novo comportamento da especificação.

Firefox

O suporte do Firefox para o novo padrão pode ser testado na versão 68 e posterior, optando na about:config página com a bandeira network.cookie.sameSite.laxByDefaultde recurso. Nenhum problema de compatibilidade foi relatado em versões mais antigas do Firefox.

Microsoft Edge

Embora o Microsoft Edge suporte o padrão antigo SameSite , a partir da versão 44 ele não teve nenhum problema de compatibilidade com o novo padrão.

Microsoft Edge Crómio

O sinalizador de recurso é edge://flags/#same-site-by-default-cookies. Não foram observados problemas de compatibilidade durante os 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 é o Chromium 66, que exibe o comportamento mais antigo. Realize seus próprios testes de compatibilidade com a versão do Electron que seu produto usa. Para obter mais informações, consulte Suporte a navegadores mais antigos.

Suporte a navegadores mais antigos

A norma de 2016 SameSite determinava que os valores desconhecidos fossem tratados como SameSite=Strict valores. Consequentemente, qualquer navegador mais antigo que suporte o padrão original pode quebrar quando vir uma SameSite propriedade com um valor de None. Os aplicativos da Web devem implementar a deteção de navegador se pretenderem oferecer suporte a esses navegadores antigos. ASP.NET Core não implementa a deteção do navegador para você porque User-Agent os valores de cabeçalho de solicitação são altamente instáveis e mudam semanalmente. Em vez disso, um ponto de extensão na política de cookies permite que você adicione User-Agentuma lógica específica.

No Startup.cs, adicione o seguinte 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
}
Comutadores de exclusão

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

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

Patches relacionados SameSite estão disponíveis para:

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

Categoria

ASP.NET

APIs afetadas


Implementação

Caminho do host x86 no Windows de 64 bits

MSBuild

As compilações em tempo de design retornam apenas referências de pacotes de nível superior

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

Versão introduzida

SDK do .NET Core 3.1.400

Alterar a descrição

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

  • PackageDefinitions
  • PackageDependencies
  • TargetDefinitions
  • FileDefinitions
  • FileDependencies

Esses dados são usados pelo Visual Studio para preencher o nó Dependências no Gerenciador de Soluções. No entanto, pode ser uma grande quantidade de dados e os dados não são necessários, a menos que o nó Dependências seja expandido.

A partir do SDK do .NET Core versão 3.1.400, a maioria desses itens não é gerada por padrão. Apenas os itens do tipo Package são devolvidos. Se o Visual Studio precisar dos itens para preencher o nó Dependências, ele lê as informações diretamente do arquivo de ativos.

Razão para a alteração

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

Ação recomendada

Se você tiver lógica MSBuild que depende desses itens que estão sendo criados, defina a EmitLegacyAssetsFileItems propriedade como true em seu arquivo de projeto. Essa configuração habilita o comportamento anterior onde todos os itens são criados.

Categoria

MSBuild

APIs afetadas

N/A


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.

Alterar a descrição

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 melhor design e suporte foram introduzidos no .NET Framework 2.0. Os controles preteridos foram removidos anteriormente 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

Ação recomendada

Cada controlo removido tem um controlo de substituição recomendado. Veja a seguinte tabela:

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

Categoria

Windows Forms

APIs afetadas


Evento CellFormatting não gerado se a dica de ferramenta for mostrada

A DataGridView agora mostra o texto de uma célula e dicas de ferramentas de erro quando pairado por um mouse e quando selecionado através do teclado. Se uma dica de ferramenta for mostrada, o DataGridView.CellFormatting evento não será gerado.

Alterar a descrição

Antes do .NET Core 3.1, um DataGridView que tinha a ShowCellToolTips propriedade definida para true mostrar uma dica de ferramenta para o texto de uma célula e erros quando a célula era pairada por um mouse. As dicas de ferramentas não eram mostradas quando uma célula era selecionada através do teclado (por exemplo, usando a tecla Tab, teclas de atalho ou navegação por seta). Se o usuário editou uma célula e, enquanto a DataGridView ainda estava no modo de edição, passou o mouse sobre uma célula que não tinha a ToolTipText propriedade definida, um CellFormatting evento foi gerado para formatar o texto da célula para exibição na célula.

Para atender aos padrões de acessibilidade, a partir do .NET Core 3.1, um DataGridView que tem a ShowCellToolTips propriedade definida para true mostrar dicas de ferramentas para o texto de uma célula e erros não apenas quando a célula é focalizada, mas também quando é selecionada através do teclado. Como consequência dessa alteração, o evento não é gerado quando as CellFormatting células que não têm a ToolTipText propriedade definida são pairadas enquanto o 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

Ação recomendada

Refatore qualquer código que dependa do CellFormatting evento enquanto o DataGridView está no modo de edição.

Categoria

Windows Forms

APIs afetadas

Nenhum


Consulte também