Condividi tramite

Modifiche che causano un'interruzione in .NET Core 3.1

  • Articolo

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.

ASP.NET Core

HTTP: Le modifiche dello stesso sito browser influiscono sull'autenticazione

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.

Versione introdotta

3.1 Preview 1

Comportamento precedente

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.

Nuovo comportamento

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).

Motivo della modifica

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.

Determinare se si è interessati

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

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

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.

Firefox

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.

Microsoft Edge

Anche se Microsoft Edge supporta il vecchio standard SameSite, a partire dalla versione 44 non ha avuto problemi di compatibilità con il nuovo standard.

Microsoft Edge Chromium

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.

Electron

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.

Supportare 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
}
Opzioni di rifiuto esplicito

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"
  }
}
Altre versioni

Le patch correlate SameSite sono disponibili per:

  • ASP.NET Core 2.1, 2.2 e 3.0
  • Microsoft.Owin 4.1
  • System.Web (per .NET Framework 4.7.2 e versioni successive)

Category

ASP.NET

API interessate

Distribuzione

Percorso host x86 in Windows a 64 bit

MSBuild

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.

Versione introdotta

.NET Core SDK 3.1.400

Descrizione delle modifiche

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.

Motivo della modifica

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.

Category

MSBuild

API interessate

N/D

SDK

Manifesti degli strumenti nella cartella radice

WinForms

Controlli rimossi

A partire da .NET Core 3.1, alcuni controlli di Windows Forms non sono più disponibili.

Descrizione delle modifiche

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:

Versione di introduzione

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

Category

WinForms

API interessate

Evento CellFormatting non generato se viene visualizzata la descrizione comando

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.

Descrizione delle modifiche

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.

Versione di introduzione

3.1

Effettuare il refactoring di qualsiasi codice che dipende dall'evento CellFormatting mentre DataGridView è in modalità di modifica.

Category

WinForms

API interessate

None

Vedi anche