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.
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.
3.1 Pré-visualização 1
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
.
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).
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.
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.
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.
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.
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.laxByDefault
de recurso. Nenhum problema de compatibilidade foi relatado em versões mais antigas do Firefox.
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.
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.
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.
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-Agent
uma 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
}
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"
}
}
Patches relacionados SameSite
estão disponíveis para:
- ASP.NET Core 2.1, 2.2 e 3.0
Microsoft.Owin
4.1System.Web
(para .NET Framework 4.7.2 e posterior)
ASP.NET
- Microsoft.AspNetCore.Builder.CookiePolicyOptions.MinimumSameSitePolicy
- Microsoft.AspNetCore.Http.CookieBuilder.SameSite
- Microsoft.AspNetCore.Http.CookieOptions.SameSite
- Microsoft.AspNetCore.Http.SameSiteMode
- Microsoft.Net.Http.Headers.SameSiteMode
- Microsoft.Net.Http.Headers.SetCookieHeaderValue.SameSite
Caminho do host x86 no Windows de 64 bits
A partir do .NET Core SDK 3.1.400, somente referências de pacote de nível superior são retornadas RunResolvePackageDependencies
pelo destino.
SDK do .NET Core 3.1.400
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.
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.
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.
MSBuild
N/A
Manifestos da ferramenta na pasta raiz
A partir do .NET Core 3.1, alguns controles do Windows Forms não estão mais disponíveis.
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:
- ContextMenu
- DataGrid
- DataGrid.HitTestType
- DataGrid.HitTestInfo
- DataGridBoolColumn
- DataGridCell
- DataGridColumnStyle
- DataGridColumnStyle.DataGridColumnHeaderAccessibleObject
- DataGridColumnStyle.CompModSwitches
- DataGridLineStyle
- DataGridParentRowsLabelStyle
- DataGridPreferredColumnWidthTypeConverter
- DataGridTableStyle
- DataGridTextBox
- DataGridTextBoxColumn
- GridColumnStylesCollection
- GridTablesFactory
- GridTableStylesCollection
- IDataGridEditingService
- IMenuEditorService
- MainMenu
- Menu
- Menu.MenuItemCollection
- MenuItem
- ToolBar
- ToolBarAppearance
- ToolBarButton
- ToolBar.ToolBarButtonCollection
- ToolBarButtonClickEventArgs
- ToolBarButtonStyle
- ToolBarTextAlign
3.1
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 |
Windows Forms
- System.Windows.Forms.ContextMenu
- System.Windows.Forms.GridColumnStylesCollection
- System.Windows.Forms.GridTablesFactory
- System.Windows.Forms.GridTableStylesCollection
- System.Windows.Forms.IDataGridEditingService
- System.Windows.Forms.MainMenu
- System.Windows.Forms.Menu
- System.Windows.Forms.Menu.MenuItemCollection
- System.Windows.Forms.MenuItem
- System.Windows.Forms.ToolBar
- System.Windows.Forms.ToolBar.ToolBarButtonCollection
- System.Windows.Forms.ToolBarAppearance
- System.Windows.Forms.ToolBarButton
- System.Windows.Forms.ToolBarButtonClickEventArgs
- System.Windows.Forms.ToolBarButtonStyle
- System.Windows.Forms.ToolBarTextAlign
- System.Windows.Forms.DataGrid
- System.Windows.Forms.DataGrid.HitTestType
- System.Windows.Forms.DataGridBoolColumn
- System.Windows.Forms.DataGridCell
- System.Windows.Forms.DataGridColumnStyle
- System.Windows.Forms.DataGridLineStyle
- System.Windows.Forms.DataGridParentRowsLabelStyle
- System.Windows.Forms.DataGridPreferredColumnWidthTypeConverter
- System.Windows.Forms.DataGridTableStyle
- System.Windows.Forms.DataGridTextBox
- System.Windows.Forms.DataGridTextBoxColumn
- System.Windows.Forms.Design.IMenuEditorService
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.
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.
3.1
Refatore qualquer código que dependa do CellFormatting evento enquanto o DataGridView está no modo de edição.
Windows Forms
Nenhum
Comentários do .NET
O .NET é um projeto código aberto. Selecione um link para fornecer comentários: