Istotne zmiany w programie .NET Core 3.1

  • Artykuł

Jeśli przeprowadzasz migrację do wersji 3.1 platformy .NET Core lub ASP.NET Core, zmiany powodujące niezgodność wymienione w tym artykule mogą mieć wpływ na twoją aplikację.

ASP.NET Core

HTTP: Zmiany w przeglądarce SameSite wpływają na uwierzytelnianie

Niektóre przeglądarki, takie jak Chrome i Firefox, dokonały zmian powodujących SameSite niezgodność w implementacji plików cookie. Zmiany wpływają na scenariusze uwierzytelniania zdalnego, takie jak OpenID Połączenie i WS-Federation, które muszą zrezygnować z wysyłania SameSite=Nonepolecenia . Jednak SameSite=None przerwy w systemie iOS 12 i niektórych starszych wersjach innych przeglądarek. Aplikacja musi wąchać te wersje i pominąć SameSite.

Aby omówić ten problem, zobacz dotnet/aspnetcore#14996.

Wprowadzona wersja

3.1 (wersja zapoznawcza 1)

Stare zachowanie

SameSite to standardowe rozszerzenie 2016 do plików cookie HTTP. Ma to na celu złagodzenie problemu fałszerzowania żądań między witrynami (CSRF). Pierwotnie została ona zaprojektowana jako funkcja, z którą serwery będą korzystać, dodając nowe parametry. ASP.NET Core 2.0 dodano początkową obsługę programu SameSite.

Nowe zachowanie

Google zaproponował nowy projekt standardu, który nie jest zgodny z poprzednimi wersjami. Standard zmienia tryb domyślny na Lax i dodaje nowy wpisNone, aby zrezygnować. Lax Wystarczy dla większości plików cookie aplikacji, jednak przerywa scenariusze obejmujące wiele witryn, takie jak identyfikator OpenID Połączenie i logowanie do federacji WS. Większość logowań OAuth nie ma wpływu na różnice w sposobie przepływu żądań. Nowy None parametr powoduje problemy ze zgodnością z klientami, którzy zaimplementowali poprzednią wersję roboczą standardu (na przykład iOS 12). Chrome 80 będzie zawierać zmiany. Zobacz SameSite Aktualizacje osi czasu uruchamiania produktu Chrome.

ASP.NET Core 3.1 został zaktualizowany w celu zaimplementowania nowego SameSite zachowania. Aktualizacja ponownie definiuje zachowanie SameSiteMode.None w celu emitowania SameSite=None i dodaje nową wartość SameSiteMode.Unspecified , aby pominąć SameSite atrybut. Wszystkie interfejsy API plików cookie mają teraz wartość domyślną Unspecified, choć niektóre składniki korzystające z plików cookie ustawiają wartości bardziej szczegółowe dla ich scenariuszy, takich jak identyfikator OpenID Połączenie korelacji i plików cookie innych niż.

Aby zapoznać się z innymi ostatnimi zmianami w tym obszarze, zobacz HTTP: Niektóre ustawienia domyślne pliku cookie SameSite zostały zmienione na Brak. W ASP.NET Core 3.0 większość ustawień domyślnych została zmieniona z SameSiteMode.Lax na SameSiteMode.None (ale nadal korzysta z poprzedniego standardu).

Przyczyna wprowadzenia zmiany

Przeglądarka i specyfikacja zmieniają się zgodnie z opisem w poprzednim tekście.

Aplikacje, które współdziałają z witrynami zdalnymi, takimi jak logowanie innych firm, muszą:

  • Przetestuj te scenariusze w wielu przeglądarkach.
  • Zastosuj środki zaradcze dotyczące wąchania przeglądarki zasad plików cookie omówione w temacie Obsługa starszych przeglądarek.

Aby uzyskać instrukcje dotyczące testowania i wąchania przeglądarki, zobacz następującą sekcję.

Ustal, czy występuje problem

Przetestuj aplikację internetową przy użyciu wersji klienta, która może zdecydować się na nowe zachowanie. Chrome, Firefox i Microsoft Edge Chromium mają nowe flagi funkcji, które mogą być używane do testowania. Sprawdź, czy aplikacja jest zgodna ze starszymi wersjami klienta po zastosowaniu poprawek, zwłaszcza w przeglądarce Safari. Aby uzyskać więcej informacji, zobacz Obsługa starszych przeglądarek.

Chrome

Chrome 78 i nowsze dają mylące wyniki testów. Wersje te mają tymczasowe środki zaradcze i umożliwiają używanie plików cookie mniej niż dwie minuty. Po włączeniu odpowiednich flag testowych chrome 76 i 77 dają dokładniejsze wyniki. Aby przetestować nowe zachowanie, przełącz chrome://flags/#same-site-by-default-cookies się w celu włączenia. Przeglądarka Chrome 75 i starsze są zgłaszane, aby zakończyć się niepowodzeniem z nowym None ustawieniem. Aby uzyskać więcej informacji, zobacz Obsługa starszych przeglądarek.

Firma Google nie udostępnia starszych wersji przeglądarki Chrome. Można jednak pobrać starsze wersje chromium, które wystarczy do testowania. Postępuj zgodnie z instrukcjami w temacie Pobierz chromium.

Safari

Przeglądarka Safari 12 ściśle zaimplementowała poprzednią wersję roboczą i kończy się niepowodzeniem, jeśli widzi nową None wartość w plikach cookie. Należy unikać tego za pośrednictwem kodu wąchania przeglądarki wyświetlanego w sekcji Obsługa starszych przeglądarek. Upewnij się, że testujesz przeglądarkę Safari 12 i 13, a także identyfikatory logowania w stylu systemu operacyjnego WebKit przy użyciu biblioteki Microsoft Authentication Library (MSAL), biblioteki uwierzytelniania usługi Active Directory (ADAL) lub dowolnej używanej biblioteki. Problem jest zależny od bazowej wersji systemu operacyjnego. OSX Mojave 10.14 i iOS 12 są znane ze zgodności z nowym zachowaniem. Uaktualnienie do systemu OSX Catalina 10.15 lub iOS 13 rozwiązuje problem. Przeglądarka Safari nie ma obecnie flagi zgody na testowanie nowego zachowania specyfikacji.

Firefox

Obsługa przeglądarki Firefox dla nowego standardu można przetestować w wersji 68 lub nowszej, decydując się na about:config stronę z flagą network.cookie.sameSite.laxByDefaultfunkcji . Nie zgłoszono żadnych problemów ze zgodnością w starszych wersjach przeglądarki Firefox.

Microsoft Edge

Przeglądarka Microsoft Edge obsługuje stary SameSite standard, ponieważ wersja 44 nie ma żadnych problemów ze zgodnością z nowym standardem.

Microsoft Edge Chromium

Flaga funkcji to edge://flags/#same-site-by-default-cookies. Podczas testowania w przeglądarce Microsoft Edge Chromium 78 nie zaobserwowano żadnych problemów ze zgodnością.

Electron

Wersje Electron obejmują starsze wersje Chromium. Na przykład wersja elektronu używana przez usługę Microsoft Teams to Chromium 66, która wykazuje starsze zachowanie. Wykonaj własne testy zgodności z wersją narzędzia Electron używanej przez produkt. Aby uzyskać więcej informacji, zobacz Obsługa starszych przeglądarek.

Obsługa starszych przeglądarek

Standard z 2016 SameSite r. nakazuje traktowanie nieznanych wartości jako SameSite=Strict wartości. W związku z tym wszystkie starsze przeglądarki, które obsługują oryginalny standard, mogą spowodować przerwanie w przypadku wyświetlenia SameSite właściwości o wartości None. Aplikacje internetowe muszą implementować wąchanie przeglądarki, jeśli zamierzają obsługiwać te stare przeglądarki. ASP.NET Core nie implementuje wąchania przeglądarki, ponieważ User-Agent wartości nagłówków żądań są wysoce niestabilne i zmieniają się co tydzień. Zamiast tego punkt rozszerzenia w zasadach plików cookie umożliwia dodanie User-Agent-konkretnej logiki.

W Startup.cs dodaj następujący kod:

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
}
Przełączniki rezygnacji

Przełącznik Microsoft.AspNetCore.SuppressSameSiteNone zgodności umożliwia tymczasowe rezygnację z nowego zachowania plików cookie ASP.NET Core. Dodaj następujący kod JSON do pliku runtimeconfig.template.json w projekcie:

{
  "configProperties": {
    "Microsoft.AspNetCore.SuppressSameSiteNone": "true"
  }
}
Inne wersje

Powiązane SameSite poprawki są nadchodzące dla:

  • ASP.NET Core 2.1, 2.2 i 3.0
  • Microsoft.Owin 4.1
  • System.Web (w przypadku programu .NET Framework 4.7.2 lub nowszego)

Kategoria

ASP.NET

Dotyczy interfejsów API

Wdrożenie

Ścieżka hosta x86 w 64-bitowym systemie Windows

MSBuild

Kompilacje w czasie projektowania zwracają tylko odwołania do pakietów najwyższego poziomu

Począwszy od zestawu .NET Core SDK 3.1.400, są zwracane tylko odwołania do pakietów najwyższego poziomu przez element docelowy RunResolvePackageDependencies .

Wprowadzona wersja

Zestaw .NET Core SDK 3.1.400

Opis zmiany

W poprzednich wersjach zestawu .NET Core SDK RunResolvePackageDependencies obiekt docelowy utworzył następujące elementy MSBuild zawierające informacje z pliku zasobów NuGet:

  • PackageDefinitions
  • PackageDependencies
  • TargetDefinitions
  • FileDefinitions
  • FileDependencies

Te dane są używane przez program Visual Studio do wypełniania węzła Zależności w Eksplorator rozwiązań. Jednak może to być duża ilość danych, a dane nie są potrzebne, chyba że węzeł Zależności zostanie rozszerzony.

Począwszy od zestawu .NET Core SDK w wersji 3.1.400, większość z tych elementów nie jest domyślnie generowana. Zwracane są tylko elementy typu Package . Jeśli program Visual Studio potrzebuje elementów do wypełnienia węzła Zależności, odczytuje informacje bezpośrednio z pliku zasobów.

Przyczyna wprowadzenia zmiany

Ta zmiana została wprowadzona w celu zwiększenia wydajności ładowania rozwiązań w programie Visual Studio. Wcześniej wszystkie odwołania do pakietu zostały załadowane, co wiązało się z ładowaniem wielu odwołań, których większość użytkowników nigdy nie wyświetla.

Jeśli masz logikę MSBuild, która zależy od tworzonych elementów, ustaw EmitLegacyAssetsFileItems właściwość na true wartość w pliku projektu. To ustawienie umożliwia poprzednie zachowanie, w którym są tworzone wszystkie elementy.

Kategoria

MSBuild

Dotyczy interfejsów API

Nie dotyczy

SDK

Manifesty narzędzi w folderze głównym

Windows Forms

Usunięte kontrolki

Począwszy od platformy .NET Core 3.1, niektóre kontrolki windows Forms nie są już dostępne.

Opis zmiany

Począwszy od platformy .NET Core 3.1, różne kontrolki windows Forms nie są już dostępne. Kontrolki zastępcze, które mają lepszy projekt i obsługę, zostały wprowadzone w programie .NET Framework 2.0. Przestarzałe kontrolki zostały wcześniej usunięte z przybornika projektanta, ale nadal były dostępne do użycia.

Następujące typy nie są już dostępne:

Wprowadzona wersja

3.1

Każda usunięta kontrolka ma zalecaną kontrolkę zastępczą. Zapoznaj się z następującą tabelą:

Usunięto kontrolkę (API) Zalecane zastąpienie Skojarzone interfejsy API, które są usuwane
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

Kategoria

Windows Forms

Dotyczy interfejsów API

Zdarzenie formatowania komórek nie jest zgłaszane, jeśli jest wyświetlana etykietka narzędzia

Element DataGridView zawiera teraz tekst komórki i etykietki narzędzi błędów po umieszczeniu wskaźnika myszy i wybraniu za pomocą klawiatury. Jeśli zostanie wyświetlona etykietka narzędzia, DataGridView.CellFormatting zdarzenie nie zostanie zgłoszone.

Opis zmiany

Przed platformą .NET Core 3.1 właściwość, DataGridView która miała ShowCellToolTips ustawioną właściwość, wyświetlała true etykietkę narzędzia dla tekstu komórki i błędy, gdy komórka została zatrzymana myszą. Etykietki narzędzi nie były wyświetlane, gdy komórka została wybrana za pomocą klawiatury (na przykład za pomocą klawisza Tab, klawiszy skrótów lub nawigacji strzałką). Jeśli użytkownik edytował komórkę, a następnie, gdy DataGridView był nadal w trybie edycji, zatrzymał wskaźnik myszy na komórce, która nie ma ToolTipText zestawu właściwości, CellFormatting zdarzenie zostało zgłoszone w celu sformatowania tekstu komórki do wyświetlenia w komórce.

Aby spełnić standardy ułatwień dostępu, począwszy od platformy .NET Core 3.1, właściwość, która ma ShowCellToolTips ustawioną właściwość , wyświetla true etykietki narzędzi dla tekstu komórki i błędy nie tylko wtedy, DataGridView gdy komórka zostanie zatrzymana, ale także po jej wybraniu za pomocą klawiatury. W wyniku tej zmiany zdarzenie nie jest wywoływane, CellFormatting gdy komórki, które nie mają ToolTipText zestawu właściwości, są najechane, gdy DataGridView obiekt jest w trybie edycji. Zdarzenie nie jest wywoływane, ponieważ zawartość zatrzymanej komórki jest wyświetlana jako etykietka narzędzia, a nie wyświetlana w komórce.

Wprowadzona wersja

3.1

Refaktoryzuj dowolny kod, który zależy od CellFormatting zdarzenia, gdy DataGridView element jest w trybie edycji.

Kategoria

Windows Forms

Dotyczy interfejsów API

Brak

Zobacz też