Share via

Belangrijke wijzigingen in .NET Core 3.1

  • Artikel

Als u migreert naar versie 3.1 van .NET Core of ASP.NET Core, kunnen de belangrijke wijzigingen in dit artikel van invloed zijn op uw app.

ASP.NET Core

HTTP: Wijzigingen in browser samesite zijn van invloed op verificatie

Sommige browsers, zoals Chrome en Firefox, hebben belangrijke wijzigingen aangebracht in hun implementaties van SameSite cookies. De wijzigingen zijn van invloed op scenario's voor externe verificatie, zoals OpenID Verbinding maken en WS-Federation, die zich moeten afmelden door te verzendenSameSite=None. SameSite=None Breekt echter af op iOS 12 en sommige oudere versies van andere browsers. De app moet deze versies snuiven en weglaten SameSite.

Zie dotnet/aspnetcore#14996 voor discussie over dit probleem.

Versie geïntroduceerd

3.1 Preview 1

Oud gedrag

SameSite is een conceptstandaardextensie voor 2016 voor HTTP-cookies. Het is bedoeld om aanvraagvervalsing op meerdere sites (CSRF) te beperken. Dit is oorspronkelijk ontworpen als een functie waaraan de servers zouden kiezen door de nieuwe parameters toe te voegen. ASP.NET Core 2.0 heeft initiële ondersteuning toegevoegd voor SameSite.

Nieuw gedrag

Google heeft een nieuwe conceptstandaard voorgesteld die niet compatibel is met eerdere versies. De standaardinstelling wijzigt de standaardmodus Lax in en voegt een nieuwe vermelding None toe om u af te melden. Lax Het is echter voldoende voor de meeste app-cookies. De standaardmodus wordt echter verbroken, zoals OpenID-Verbinding maken en WS-Federation-aanmelding. De meeste OAuth-aanmeldingen worden niet beïnvloed vanwege verschillen in de manier waarop de aanvraag verloopt. De nieuwe None parameter veroorzaakt compatibiliteitsproblemen met clients die de vorige conceptstandaard hebben geïmplementeerd (bijvoorbeeld iOS 12). Chrome 80 bevat de wijzigingen. Zie samesite-updates voor de tijdlijn van de chrome-productlancering.

ASP.NET Core 3.1 is bijgewerkt om het nieuwe SameSite gedrag te implementeren. De update herdefinieert het gedrag van SameSiteMode.None verzenden SameSite=None en voegt een nieuwe waarde SameSiteMode.Unspecified toe om het SameSite kenmerk weg te laten. Alle cookie-API's zijn nu standaard ingesteldUnspecified, hoewel sommige onderdelen die cookies gebruiken waarden specifieker hebben ingesteld voor hun scenario's, zoals de OpenID Verbinding maken correlatie en niet-cookies.

Voor andere recente wijzigingen in dit gebied raadpleegt u HTTP: Sommige cookie SameSite-standaardinstellingen zijn gewijzigd in None. In ASP.NET Core 3.0 zijn de meeste standaardwaarden gewijzigd van SameSiteMode.Lax in SameSiteMode.None (maar nog steeds met de vorige standaard).

Reden voor wijziging

Browser- en specificatiewijzigingen zoals beschreven in de voorgaande tekst.

Apps die communiceren met externe sites, zoals via aanmelding van derden, moeten:

  • Test deze scenario's in meerdere browsers.
  • Pas de sniffing-beperking van de cookiebeleidsbrowser toe die wordt besproken in oudere browsers ondersteunen.

Zie de volgende sectie voor het testen en sniffen van browsers.

Bepalen of u last hebt van

Test uw web-app met behulp van een clientversie die kan kiezen voor het nieuwe gedrag. Chrome, Firefox en Microsoft Edge Chromium hebben allemaal nieuwe markeringen voor opt-in-functies die kunnen worden gebruikt voor het testen. Controleer of uw app compatibel is met oudere clientversies nadat u de patches hebt toegepast, met name Safari. Zie Ondersteuning voor oudere browsers voor meer informatie.

Chrome

Chrome 78 en hoger leveren misleidende testresultaten op. Deze versies hebben een tijdelijke oplossing en staan cookies toe die minder dan twee minuten oud zijn. Als de juiste testvlagmen zijn ingeschakeld, levert Chrome 76 en 77 nauwkeurigere resultaten op. Als u het nieuwe gedrag wilt testen, schakelt chrome://flags/#same-site-by-default-cookies u in of uit op ingeschakeld. Chrome 75 en eerder worden gerapporteerd dat ze mislukken met de nieuwe None instelling. Zie Ondersteuning voor oudere browsers voor meer informatie.

Google maakt geen oudere Chrome-versies beschikbaar. U kunt echter oudere versies van Chromium downloaden, wat voldoende is om te testen. Volg de instructies bij Download Chromium.

Safari

Safari 12 heeft het vorige concept strikt geïmplementeerd en mislukt als de nieuwe None waarde in cookies wordt weergegeven. Dit moet worden vermeden via de browser-sniffing-code die wordt weergegeven in oudere browsers ondersteunen. Zorg ervoor dat u Safari 12 en 13 en op WebKit gebaseerde aanmeldingen in os-stijl test met behulp van Microsoft Authentication Library (MSAL), Active Directory Authentication Library (ADAL) of de bibliotheek die u gebruikt. Het probleem is afhankelijk van de onderliggende versie van het besturingssysteem. OSX Mojave 10.14 en iOS 12 zijn bekend dat er compatibiliteitsproblemen zijn met het nieuwe gedrag. Als u een upgrade uitvoert naar OSX Catalina 10.15 of iOS 13, wordt het probleem opgelost. Safari heeft momenteel geen opt-in-vlag voor het testen van het nieuwe specificatiegedrag.

Firefox

Firefox-ondersteuning voor de nieuwe standaard kan worden getest op versie 68 en hoger door u aan te vragen op de about:config pagina met de functievlag network.cookie.sameSite.laxByDefault. Er zijn geen compatibiliteitsproblemen gerapporteerd in oudere versies van Firefox.

Microsoft Edge

Hoewel Microsoft Edge de oude SameSite standaard ondersteunt, had het vanaf versie 44 geen compatibiliteitsproblemen met de nieuwe standaard.

Microsoft Edge Chromium

De functievlag is edge://flags/#same-site-by-default-cookies. Er zijn geen compatibiliteitsproblemen waargenomen bij het testen met Microsoft Edge Chromium 78.

Electron

Versies van Electron bevatten oudere versies van Chromium. De versie van Electron die door Microsoft Teams wordt gebruikt, is bijvoorbeeld Chromium 66, dat het oudere gedrag vertoont. Voer uw eigen compatibiliteitstests uit met de versie van Electron die uw product gebruikt. Zie Ondersteuning voor oudere browsers voor meer informatie.

Ondersteuning voor oudere browsers

De standaard van 2016 SameSite vereist dat onbekende waarden worden behandeld als SameSite=Strict waarden. Daarom kunnen oudere browsers die de oorspronkelijke standaard ondersteunen, breken wanneer ze een SameSite eigenschap met een waarde van None. Web-apps moeten browsersniffing implementeren als ze deze oude browsers willen ondersteunen. ASP.NET Core implementeert geen browser-sniffing voor u omdat User-Agent aanvraagheaderwaarden zeer instabiel zijn en wekelijks worden gewijzigd. In plaats daarvan kunt u met een uitbreidingspunt in het cookiebeleid -specifieke logica toevoegen User-Agent.

Voeg in Startup.cs de volgende code toe:

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
}
Schakelopties voor afmelden

Met de Microsoft.AspNetCore.SuppressSameSiteNone compatibiliteitsswitch kunt u zich tijdelijk afmelden voor het nieuwe ASP.NET Core-cookiegedrag. Voeg de volgende JSON toe aan een runtimeconfig.template.json-bestand in uw project:

{
  "configProperties": {
    "Microsoft.AspNetCore.SuppressSameSiteNone": "true"
  }
}
Andere versies

Gerelateerde SameSite patches worden binnenkort uitgebracht voor:

  • ASP.NET Core 2.1, 2.2 en 3.0
  • Microsoft.Owin 4.1
  • System.Web (voor .NET Framework 4.7.2 en hoger)

Categorie

ASP.NET

Betrokken API's

Implementatie

x86-hostpad in 64-bits Windows

MSBuild

Ontwerptijd-builds retourneren alleen pakketverwijzingen op het hoogste niveau

Vanaf .NET Core SDK 3.1.400 worden alleen pakketverwijzingen op het hoogste niveau geretourneerd door het RunResolvePackageDependencies doel.

Versie geïntroduceerd

.NET Core SDK 3.1.400

Wijzigingsbeschrijving

In eerdere versies van de .NET Core SDK heeft het RunResolvePackageDependencies doel de volgende MSBuild-items gemaakt die informatie bevatten uit het NuGet-assetsbestand:

  • PackageDefinitions
  • PackageDependencies
  • TargetDefinitions
  • FileDefinitions
  • FileDependencies

Deze gegevens worden door Visual Studio gebruikt om het knooppunt Afhankelijkheden in Solution Explorer te vullen. Het kan echter een grote hoeveelheid gegevens zijn en de gegevens zijn niet nodig, tenzij het knooppunt Afhankelijkheden wordt uitgevouwen.

Vanaf .NET Core SDK versie 3.1.400 worden de meeste van deze items niet standaard gegenereerd. Alleen items van het type Package worden geretourneerd. Als Visual Studio de items nodig heeft om het knooppunt Afhankelijkheden te vullen, worden de gegevens rechtstreeks uit het assetsbestand gelezen.

Reden voor wijziging

Deze wijziging is geïntroduceerd om de prestaties van oplossingsbelastingen in Visual Studio te verbeteren. Voorheen zouden alle pakketverwijzingen worden geladen, wat betrekking had op het laden van veel verwijzingen die de meeste gebruikers nooit zouden bekijken.

Als u MSBuild-logica hebt die afhankelijk is van deze items die worden gemaakt, stelt u de EmitLegacyAssetsFileItems eigenschap true in op in uw projectbestand. Met deze instelling wordt het vorige gedrag ingeschakeld waarbij alle items worden gemaakt.

Categorie

MSBuild

Betrokken API's

N.v.t.

SDK

Hulpprogrammamanifesten in hoofdmap

Windows Forms

Verwijderde besturingselementen

Vanaf .NET Core 3.1 zijn sommige Besturingselementen voor Windows Forms niet meer beschikbaar.

Wijzigingsbeschrijving

Vanaf .NET Core 3.1 zijn verschillende Besturingselementen voor Windows Forms niet meer beschikbaar. Vervangende besturingselementen met een beter ontwerp en ondersteuning zijn geïntroduceerd in .NET Framework 2.0. De afgeschafte besturingselementen zijn eerder verwijderd uit designer-werksets, maar waren nog steeds beschikbaar om te worden gebruikt.

De volgende typen zijn niet meer beschikbaar:

Versie geïntroduceerd

3.1

Elk verwijderd besturingselement heeft een aanbevolen vervangingsbeheer. Raadpleeg de volgende tabel:

Besturingselement verwijderd (API) Aanbevolen vervanging Gekoppelde API's die worden verwijderd
ContextMenu ContextmenuStrip
Datagrid Datagridview DataGridCell, DataGridRow, DataGridTableCollection, DataGridColumnCollection, DataGridTableStyle, DataGridColumnStyle, DataGridLineStyle, DataGridParentRowsLabel, DataGridParentRowsLabelStyle, DataGridBoolColumn, DataGridTextBox, GridColumnStylesCollection, GridTableStylesCollection, HitTestType
Hoofdmenu MenuStrip
Menu ToolStripDropDown, Menu ToolStripDropDown MenuItemCollection
Menuitem ToolStripMenuItem
Werkbalk Werkbalk ToolBarAppearance
Knopknop ToolStripButton ToolBarButtonClickEventArgs, ToolBarButtonClickEventHandler, ToolBarButtonStyle, ToolBarTextAlign

Categorie

Windows Forms

Betrokken API's

De gebeurtenis CellFormatting wordt niet gegenereerd als knopinfo wordt weergegeven

A DataGridView toont nu de tekst en foutknopinfo van een cel wanneer u de muisaanwijzer aanwijst en wanneer deze is geselecteerd via het toetsenbord. Als er knopinfo wordt weergegeven, wordt de DataGridView.CellFormatting gebeurtenis niet gegenereerd.

Wijzigingsbeschrijving

Voorafgaand aan .NET Core 3.1, waarop DataGridView de ShowCellToolTips eigenschap is ingesteld om knopinfo weer te true geven voor de tekst en fouten van een cel toen de cel werd aangeroepen door een muis. Knopinfo is niet weergegeven wanneer een cel is geselecteerd via het toetsenbord (bijvoorbeeld met de Tab-toets, sneltoetsen of pijlnavigatie). Als de gebruiker een cel heeft bewerkt en terwijl de DataGridView bewerkingsmodus nog in de bewerkingsmodus stond, heeft u de muisaanwijzer boven een cel geplaatst waarvoor de ToolTipText eigenschap niet is ingesteld, een CellFormatting gebeurtenis gegenereerd om de tekst van de cel op te maken voor weergave in de cel.

Als u wilt voldoen aan de toegankelijkheidsstandaarden, begint u in .NET Core 3.1, een DataGridView eigenschap die is ShowCellToolTips ingesteld om knopinfo weer te true geven voor de tekst en fouten van een cel, niet alleen wanneer de cel wordt aangezet, maar ook wanneer deze is geselecteerd via het toetsenbord. Als gevolg van deze wijziging wordt de CellFormatting gebeurtenis niet gegenereerd wanneer cellen die niet over de ToolTipText eigenschappenset beschikken, worden aangezet terwijl de DataGridView bewerkingsmodus is ingeschakeld. De gebeurtenis wordt niet gegenereerd omdat de inhoud van de zwevende cel wordt weergegeven als knopinfo in plaats van in de cel te worden weergegeven.

Versie geïntroduceerd

3.1

Herstructureer alle code die afhankelijk is van de CellFormatting gebeurtenis terwijl deze zich in de DataGridView bewerkingsmodus bevindt.

Categorie

Windows Forms

Betrokken API's

None

Zie ook