Icke-bakåtkompatibla ändringar i .NET Core 3.1

  • Artikel

Om du migrerar till version 3.1 av .NET Core eller ASP.NET Core kan de icke-bakåtkompatibla ändringarna som anges i den här artikeln påverka din app.

ASP.NET Core

HTTP: Ändringar av webbläsarens SameSite påverkar autentiseringen

Vissa webbläsare, till exempel Chrome och Firefox, gjorde icke-bakåtkompatibla ändringar i sina implementeringar av SameSite för cookies. Ändringarna påverkar scenarier för fjärrautentisering, till exempel OpenID Anslut och WS-Federation, som måste välja bort genom att skicka SameSite=None. Pauser SameSite=None på iOS 12 och vissa äldre versioner av andra webbläsare. Appen måste sniffa dessa versioner och utelämna SameSite.

Information om det här problemet finns i dotnet/aspnetcore#14996.

Version introducerad

3.1 Förhandsversion 1

Gammalt beteende

SameSite är ett 2016 utkast till standardtillägg till HTTP-cookies. Det är avsett att minimera förfalskning av begäranden mellan webbplatser (CSRF). Detta utformades ursprungligen som en funktion som servrarna skulle välja genom att lägga till de nya parametrarna. ASP.NET Core 2.0 lade till inledande stöd för SameSite.

Nytt beteende

Google föreslog ett nytt utkast till standard som inte är bakåtkompatibelt. Standarden ändrar standardläget till och lägger till Lax en ny post None för att välja bort. Lax räcker för de flesta appcookies. Men den bryter scenarier mellan webbplatser som OpenID Anslut och WS-Federation-inloggning. De flesta OAuth-inloggningar påverkas inte på grund av skillnader i hur begäran flödar. Den nya None parametern orsakar kompatibilitetsproblem med klienter som implementerade den tidigare utkaststandarden (till exempel iOS 12). Chrome 80 innehåller ändringarna. Se SameSite Uppdateringar för tidslinjen för lanseringen av Chrome-produkten.

ASP.NET Core 3.1 har uppdaterats för att implementera det nya SameSite beteendet. Uppdateringen omdefinierar beteendet SameSiteMode.None för att generera SameSite=None och lägger till ett nytt värde SameSiteMode.Unspecified för att utelämna attributet SameSite . Alla cookie-API:er är nu standard för Unspecified, även om vissa komponenter som använder cookies anger värden som är mer specifika för deras scenarier, till exempel OpenID-Anslut korrelation och nonce-cookies.

Andra nyligen gjorda ändringar i det här området finns i HTTP: Vissa standardvärden för cookien SameSite har ändrats till Ingen. I ASP.NET Core 3.0 ändrades de flesta standardvärden från SameSiteMode.Lax till SameSiteMode.None (men använder fortfarande den tidigare standarden).

Orsak till ändringen

Webbläsar- och specifikationsändringar enligt beskrivningen i föregående text.

Appar som interagerar med fjärrwebbplatser, till exempel via inloggning från tredje part, måste:

Anvisningar för testning och webbläsarsniffning finns i följande avsnitt.

Kontrollera om du påverkas

Testa webbappen med hjälp av en klientversion som kan välja det nya beteendet. Chrome, Firefox och Microsoft Edge Chromium har alla nya funktionsflaggor som kan användas för testning. Kontrollera att appen är kompatibel med äldre klientversioner när du har tillämpat korrigeringarna, särskilt Safari. Mer information finns i Stöd för äldre webbläsare.

Chrome

Chrome 78 och senare ger missvisande testresultat. Dessa versioner har en tillfällig åtgärd på plats och tillåter cookies som är mindre än två minuter gamla. Med lämpliga testflaggor aktiverade ger Chrome 76 och 77 mer exakta resultat. Om du vill testa det nya beteendet växlar du chrome://flags/#same-site-by-default-cookies till aktiverat. Chrome 75 och tidigare rapporteras misslyckas med den nya None inställningen. Mer information finns i Stöd för äldre webbläsare.

Google gör inte äldre Chrome-versioner tillgängliga. Du kan dock ladda ned äldre versioner av Chromium, vilket räcker för testning. Följ anvisningarna på Ladda ned Chromium.

Safari

Safari 12 implementerade strikt det tidigare utkastet och misslyckas om det nya None värdet visas i cookies. Detta måste undvikas via webbläsarens sniffningskod som visas i Stöd för äldre webbläsare. Se till att du testar Safari 12 och 13 samt WebKit-baserade inloggningar i OS-stil med hjälp av Microsoft Authentication Library (MSAL), Active Directory Authentication Library (ADAL) eller vilket bibliotek du använder. Problemet är beroende av den underliggande operativsystemversionen. OSX Mojave 10.14 och iOS 12 är kända för att ha kompatibilitetsproblem med det nya beteendet. Om du uppgraderar till OSX Catalina 10.15 eller iOS 13 åtgärdas problemet. Safari har för närvarande ingen opt-in-flagga för att testa det nya specifikationsbeteendet.

Firefox

Firefox-stöd för den nya standarden kan testas på version 68 och senare genom att välja på about:config sidan med funktionsflaggan network.cookie.sameSite.laxByDefault. Inga kompatibilitetsproblem har rapporterats på äldre versioner av Firefox.

Microsoft Edge

Microsoft Edge stöder den gamla SameSite standarden, men från och med version 44 hade den inga kompatibilitetsproblem med den nya standarden.

Microsoft Edge Chromium

Funktionsflaggan är edge://flags/#same-site-by-default-cookies. Inga kompatibilitetsproblem observerades vid testning med Microsoft Edge Chromium 78.

Elektron

Versioner av Elektron omfattar äldre versioner av Chromium. Till exempel är den version av Electron som används av Microsoft Teams Chromium 66, som uppvisar det äldre beteendet. Utför din egen kompatibilitetstestning med den version av Electron som produkten använder. Mer information finns i Stöd för äldre webbläsare.

Stöd för äldre webbläsare

2016-standarden SameSite gav i uppdrag att okända värden skulle behandlas som SameSite=Strict värden. Därför kan alla äldre webbläsare som stöder den ursprungliga standarden brytas när de ser en SameSite egenskap med värdet None. Webbappar måste implementera webbläsarsniffning om de har för avsikt att stödja dessa gamla webbläsare. ASP.NET Core implementerar inte webbläsarsniffning åt dig eftersom User-Agent värdena för begärandehuvuden är mycket instabila och ändras varje vecka. I stället kan du lägga User-Agenttill -specifik logik med en tilläggspunkt i cookieprincipen.

Lägg till följande kod i Startup.cs:

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
}
Avaktiveringsväxlar

Med Microsoft.AspNetCore.SuppressSameSiteNone kompatibilitetsväxlingen kan du tillfälligt välja bort det nya ASP.NET Core-cookiebeteendet. Lägg till följande JSON i en runtimeconfig.template.json fil i projektet:

{
  "configProperties": {
    "Microsoft.AspNetCore.SuppressSameSiteNone": "true"
  }
}
Andra versioner

Relaterade SameSite korrigeringar kommer för:

  • ASP.NET Core 2.1, 2.2 och 3.0
  • Microsoft.Owin 4.1
  • System.Web (för .NET Framework 4.7.2 och senare)

Kategori

ASP.NET

Berörda API:er

Distribution

x86-värdsökväg i 64-bitars Windows

MSBuild

Designtidsversioner returnerar endast paketreferenser på toppnivå

Från och med .NET Core SDK 3.1.400 returneras endast paketreferenser på toppnivå av RunResolvePackageDependencies målet.

Version introducerad

.NET Core SDK 3.1.400

Ändra beskrivning

I tidigare versioner av .NET Core SDK RunResolvePackageDependencies skapade målet följande MSBuild-objekt som innehöll information från NuGet-resursfilen:

  • PackageDefinitions
  • PackageDependencies
  • TargetDefinitions
  • FileDefinitions
  • FileDependencies

Dessa data används av Visual Studio för att fylla i noden Beroenden i Solution Explorer. Det kan dock vara en stor mängd data och data behövs inte om inte noden Beroenden expanderas.

Från och med .NET Core SDK version 3.1.400 genereras de flesta av dessa objekt inte som standard. Endast objekt av typen Package returneras. Om Visual Studio behöver objekten för att fylla i noden Beroenden läser den informationen direkt från resursfilen.

Orsak till ändringen

Den här ändrades för att förbättra prestanda för lösningsbelastning i Visual Studio. Tidigare skulle alla paketreferenser läsas in, vilket innebar att många referenser lästes in som de flesta användare aldrig skulle visa.

Om du har MSBuild-logik som är beroende av att dessa objekt skapas anger du EmitLegacyAssetsFileItems egenskapen till true i projektfilen. Den här inställningen aktiverar det tidigare beteendet där alla objekt skapas.

Kategori

MSBuild

Berörda API:er

Ej tillämpligt

SDK

Verktygsmanifest i rotmappen

Windows Forms

Borttagna kontroller

Från och med .NET Core 3.1 är vissa Windows Forms-kontroller inte längre tillgängliga.

Ändra beskrivning

Från och med .NET Core 3.1 är olika Windows Forms-kontroller inte längre tillgängliga. Ersättningskontroller som har bättre design och stöd introducerades i .NET Framework 2.0. De inaktuella kontrollerna har tidigare tagits bort från designerverktygslådor men var fortfarande tillgängliga för användning.

Följande typer är inte längre tillgängliga:

Version introducerad

3.1

Varje borttagen kontroll har en rekommenderad ersättningskontroll. Se följandet tabell:

Borttagen kontroll (API) Rekommenderad ersättning Associerade API:er som tas bort
ContextMenu ContextMenuStrip
Datagrid Datagridview DataGridCell, DataGridRow, DataGridTableCollection, DataGridColumnCollection, DataGridTableStyle, DataGridColumnStyle, DataGridLineStyle, DataGridParentRowsLabel, DataGridParentRowsLabelStyle, DataGridBoolColumn, DataGridTextBox, GridColumnStylesCollection, GridTableStylesCollection, HitTestType
MainMenu MenuStrip
Meny ToolStripDropDown, ToolStripDropDownMenu MenuItemCollection
Menuitem ToolStripMenuItem
Verktygsfältet Toolstrip ToolBarAppearance
ToolBarButton ToolStripButton ToolBarButtonClickEventArgs, ToolBarButtonClickEventHandler, ToolBarButtonStyle, ToolBarTextAlign

Kategori

Windows Forms

Berörda API:er

CellFormateringshändelsen aktiveras inte om knappbeskrivningen visas

A DataGridView visar nu en cells text- och felknappbeskrivningar när den hovras av en mus och när den väljs via tangentbordet. Om en knappbeskrivning visas DataGridView.CellFormatting utlöses inte händelsen.

Ändra beskrivning

Före .NET Core 3.1 visade en DataGridView som hade ShowCellToolTips egenskapen inställd på true en knappbeskrivning för en cells text och fel när cellen hovrades av en mus. Knappbeskrivningar visades inte när en cell valdes via tangentbordet (till exempel med hjälp av tabbtangenten, genvägstangenterna eller pilnavigering). Om användaren redigerade en cell och sedan, medan den DataGridView fortfarande var i redigeringsläge, hovrade över en cell som inte hade ToolTipText egenskapen inställd, skapades en CellFormatting händelse för att formatera cellens text för visning i cellen.

För att uppfylla tillgänglighetsstandarder, med början i .NET Core 3.1, en DataGridView som har ShowCellToolTips egenskapen inställd på true visar knappbeskrivningar för en cells text och fel inte bara när cellen hovrar, utan även när den väljs via tangentbordet. Till följd av den här ändringen CellFormatting utlöses inte händelsen när celler som inte har egenskapsuppsättningen ToolTipText hovras medan den DataGridView är i redigeringsläge. Händelsen aktiveras inte eftersom innehållet i den hovrade cellen visas som en knappbeskrivning i stället för att visas i cellen.

Version introducerad

3.1

Omstrukturera all kod som är beroende av CellFormatting händelsen medan den DataGridView är i redigeringsläge.

Kategori

Windows Forms

Berörda API:er

Inga

Se även