Modifiche che causano un'interruzione in .NET Core 3.1
Se si esegue la migrazione alla versione 3.1 di .NET Core o ASP.NET Core, le modifiche di rilievo elencate in questo articolo potrebbero influire sull'app.
Alcuni browser, ad esempio Chrome e Firefox, hanno apportato modifiche di rilievo alle loro implementazioni di SameSite
per i cookie. Le modifiche influiscono sugli scenari di autenticazione remota, ad esempio OpenID Connect e WS-Federation, che devono rifiutare esplicitamente inviando SameSite=None
. Tuttavia, SameSite=None
si interrompe in iOS 12 e in alcune versioni precedenti di altri browser. L'app deve eseguire l'analisi di queste versioni e omettere SameSite
.
Per informazioni su questo problema, vedere dotnet/aspnetcore#14996.
3.1 Preview 1
SameSite
è una bozza di estensione standard 2016 per i cookie HTTP. È progettato per attenuare la richiesta cross-site forgery (CSRF). Originariamente progettato come funzionalità, i server potrebbero acconsentire esplicitamente aggiungendo i nuovi parametri. ASP.NET Core 2.0 ha aggiunto il supporto iniziale per SameSite
.
Google ha proposto un nuovo standard bozza che non è compatibile con le versioni precedenti. Lo standard modifica la modalità predefinita in Lax
e aggiunge una nuova voce None
per rifiutare esplicitamente. Lax
è sufficiente per la maggior parte dei cookie dell'app. Tuttavia, interrompe gli scenari tra siti, ad esempio OpenID Connect e l'account di accesso WS-Federation. La maggior parte degli account di accesso OAuth non è interessata a causa delle differenze nel flusso della richiesta. Il nuovo parametro None
causa problemi di compatibilità con i client che hanno implementato la bozza dello standard precedente (ad esempio, iOS 12). Chrome 80 includerà le modifiche. Vedere Aggiornamenti SameSite per la sequenza temporale di avvio del prodotto Chrome.
ASP.NET Core 3.1 è stato aggiornato per implementare il nuovo comportamento di SameSite
. L'aggiornamento ridefinisce il comportamento di SameSiteMode.None
per generare SameSite=None
e aggiunge un nuovo valore SameSiteMode.Unspecified
per omettere l'attributo SameSite
. Tutte le API dei cookie sono ora predefinite su Unspecified
, anche se alcuni componenti che usano i valori impostati dai cookie sono più specifici per i relativi scenari, ad esempio la correlazione OpenID Connect e i cookie nonce.
Per altre modifiche recenti in questa area, vedere HTTP: Alcune impostazioni predefinite di SameSite cookie sono state modificate in Nessuno. In ASP.NET Core 3.0, la maggior parte delle impostazioni predefinite è stata modificata da SameSiteMode.Lax a SameSiteMode.None (ma usando ancora lo standard precedente).
Modifiche del browser e delle specifiche, come descritto nel testo precedente.
Le app che interagiscono con siti remoti, ad esempio tramite un account di accesso di terze parti, devono:
- Testare questi scenari in più browser.
- Applicare la mitigazione dell'analisi del browser dei criteri dei cookie descritta in Supporto di browser meno recenti.
Per istruzioni su test e analisi del browser, vedere la sezione seguente.
Testare l'app Web usando una versione client che può acconsentire esplicitamente al nuovo comportamento. Chrome, Firefox e Microsoft Edge Chromium hanno tutti nuovi flag di funzionalità di consenso esplicito che possono essere usati per i test. Verificare che l'app sia compatibile con le versioni client precedenti dopo aver applicato le patch, in particolare Safari. Per altre informazioni, vedere Supporto di browser meno recenti.
Chrome 78 e versioni successive producono risultati di test fuorvianti. Queste versioni hanno una mitigazione temporanea sul posto e consentono i cookie meno di due minuti prima. Con i flag di test appropriati abilitati, Chrome 76 e 77 producono risultati più accurati. Per testare il nuovo comportamento, impostare chrome://flags/#same-site-by-default-cookies
su abilitato. È stato segnalato che Chrome 75 e versioni precedenti non funzionano con la nuova None
impostazione. Per altre informazioni, vedere Supporto di browser meno recenti.
Google non rende disponibili le versioni precedenti di Chrome. È tuttavia possibile scaricare le versioni precedenti di Chromium, che sarà sufficiente per i test. Seguire le istruzioni in Scaricare Chromium.
Safari 12 ha implementato rigorosamente la bozza precedente e ha esito negativo se vede il nuovo valore None
nei cookie. Questa operazione deve essere evitata tramite il codice di analisi del browser visualizzato in Supporto di browser meno recenti. Assicurarsi di testare Safari 12 e 13, nonché gli account di accesso basati su WebKit in stile sistema operativo usando Microsoft Authentication Library (MSAL), Active Directory Authentication Library (ADAL) o qualsiasi libreria in uso. Il problema dipende dalla versione del sistema operativo sottostante. OSX Mojave 10.14 e iOS 12 sono noti per avere problemi di compatibilità con il nuovo comportamento. L'aggiornamento a OSX Catalina 10.15 o iOS 13 risolve il problema. Safari non dispone attualmente di un flag di consenso esplicito per testare il nuovo comportamento di specifica.
Il supporto di Firefox per il nuovo standard può essere testato nella versione 68 e successive acconsentire esplicitamente alla pagina about:config
con il flag di funzionalità network.cookie.sameSite.laxByDefault
. Non sono stati segnalati problemi di compatibilità sulle versioni precedenti di Firefox.
Anche se Microsoft Edge supporta il vecchio standard SameSite
, a partire dalla versione 44 non ha avuto problemi di compatibilità con il nuovo standard.
Il flag di funzionalità è edge://flags/#same-site-by-default-cookies
. Non sono stati rilevati problemi di compatibilità durante i test con Microsoft Edge Chromium 78.
Le versioni di Electron includono versioni precedenti di Chromium. Ad esempio, la versione di Electron usata da Microsoft Teams è Chromium 66, che mostra il comportamento precedente. Eseguire test di compatibilità personalizzati con la versione di Electron usata dal prodotto. Per altre informazioni, vedere Supporto di browser meno recenti.
Lo standard SameSite
2016 imponeva che i valori sconosciuti venissero considerati come valori SameSite=Strict
. Di conseguenza, tutti i browser meno recenti che supportano lo standard originale si possono interrompere quando visualizzano una proprietà SameSite
con un valore di None
. Le app Web devono implementare l'analisi del browser se intendono supportare questi vecchi browser. ASP.NET Core non implementa l'analisi del browser perché i valori di intestazione della richiesta User-Agent
sono altamente instabili e cambiano su base settimanale. Al contrario, un punto di estensione nei criteri cookie consente di aggiungere logica specifica per User-Agent
.
In Startup.cs aggiungere le istruzioni seguenti:
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
}
L'opzione di compatibilità Microsoft.AspNetCore.SuppressSameSiteNone
consente di rifiutare temporaneamente il nuovo comportamento dei cookie di ASP.NET Core. Aggiungere il codice JSON seguente a un file runtimeconfig.template.json nel progetto:
{
"configProperties": {
"Microsoft.AspNetCore.SuppressSameSiteNone": "true"
}
}
Le patch correlate SameSite
sono disponibili per:
- ASP.NET Core 2.1, 2.2 e 3.0
Microsoft.Owin
4.1System.Web
(per .NET Framework 4.7.2 e versioni successive)
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
Percorso host x86 in Windows a 64 bit
Le compilazioni in fase di progettazione restituiscono solo riferimenti ai pacchetti di primo livello
A partire da .NET Core SDK 3.1.400, solo i riferimenti di pacchetto di primo livello vengono restituiti dalla destinazione RunResolvePackageDependencies
.
.NET Core SDK 3.1.400
Nelle versioni precedenti di .NET Core SDK, la destinazione RunResolvePackageDependencies
ha creato gli elementi MSBuild seguenti che contengono informazioni dal file di asset NuGet:
PackageDefinitions
PackageDependencies
TargetDefinitions
FileDefinitions
FileDependencies
Questi dati vengono usati da Visual Studio per popolare il nodo Dipendenze in Esplora soluzioni. Tuttavia, la quantità di dati potrebbe essere elevata e i dati non sono necessari a meno che il nodo Dipendenze non venga espanso.
A partire da .NET Core SDK versione 3.1.400, la maggior parte di questi elementi non viene generata per impostazione predefinita. Vengono restituiti solo gli elementi di tipo Package
. Se Visual Studio richiede che gli elementi popolano il nodo Dipendenze, legge le informazioni direttamente dal file di asset.
Questa modifica è stata introdotta per migliorare le prestazioni di caricamento della soluzione all'interno di Visual Studio. In precedenza, tutti i riferimenti ai pacchetti venivano caricati, comportando il caricamento di molti riferimenti mai visualizzati dalla maggior parte degli utenti.
Se disponi di una logica MSBuild che dipende da questi elementi creati, imposta la proprietà EmitLegacyAssetsFileItems
su true
nel file di progetto. Questa impostazione abilita il comportamento precedente in cui vengono creati tutti gli elementi.
MSBuild
N/D
Manifesti degli strumenti nella cartella radice
A partire da .NET Core 3.1, alcuni controlli di Windows Forms non sono più disponibili.
A partire da .NET Core 3.1, diversi controlli di Windows Forms non sono più disponibili. I controlli sostitutivi con progettazione e supporto migliori sono stati introdotti in .NET Framework 2.0. I controlli deprecati sono stati rimossi in precedenza dalle caselle degli strumenti della finestra di progettazione, ma erano ancora disponibili per l'uso.
I tipi seguenti non sono più disponibili:
- 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
Ogni controllo rimosso ha un controllo sostitutivo consigliato. Fare riferimento alla tabella seguente:
Controllo rimosso (API) | Sostituzione consigliata | API associate che vengono rimosse |
---|---|---|
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 |
WinForms
- 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
Una classe DataGridView mostra ora il testo e le descrizioni comando di errore di una cella quando si passa il mouse sopra la cella e in caso di selezione tramite la tastiera. Se viene visualizzata una descrizione comando, l'evento DataGridView.CellFormatting non viene generato.
Prima di .NET Core 3.1, una classe DataGridView con la proprietà ShowCellToolTips impostata su true
mostrava una descrizione comando per il testo e gli errori di una cella quando si passava il mouse sopra la cella. Le descrizioni comando non venivano visualizzate quando una cella veniva selezionata tramite la tastiera, ad esempio usando il tasto TAB, i tasti di scelta rapida o lo spostamento con la freccia. Se l'utente modificava una cella e quindi, mentre la classe DataGridView era ancora in modalità di modifica, passava il mouse sopra una cella per cui non era stata impostata la proprietà ToolTipText, veniva generato un evento CellFormatting per formattare il testo della cella per la visualizzazione nella cella.
Per soddisfare gli standard di accessibilità, a partire da .NET Core 3.1, una classe DataGridView con la proprietà ShowCellToolTips impostata su true
mostra le descrizioni comando per il testo e gli errori di una cella non solo quando si passa il mouse sopra la cella , ma anche quando la cella viene selezionata tramite la tastiera. In seguito a questa modifica, l'evento CellFormatting non viene generato quando si passa il mouse sopra le celle per cui non è stata impostata la proprietà ToolTipText mentre DataGridView è in modalità di modifica. L'evento non viene generato perché il contenuto della cella su cui si passa il mouse viene visualizzato come descrizione comando anziché essere visualizzato nella cella.
3.1
Effettuare il refactoring di qualsiasi codice che dipende dall'evento CellFormatting mentre DataGridView è in modalità di modifica.
WinForms
None
Feedback su .NET
.NET è un progetto di open source. Selezionare un collegamento per fornire feedback: