Baca dalam bahasa Inggris

Bagikan melalui


Memutus perubahan di .NET Core 3.1

Jika Anda bermigrasi ke .NET Core atau ASP.NET Core versi 3.1, perubahan melanggar yang tercantum dalam artikel ini dapat memengaruhi aplikasi Anda.

Inti ASP.NET

HTTP: Perubahan SameSite Browser memengaruhi autentikasi

Beberapa browser, seperti Chrome dan Firefox, membuat perubahan mencolok pada SameSite implementasi mereka untuk cookie. Perubahan berdampak pada skenario autentikasi jarak jauh, seperti OpenID Koneksi dan WS-Federation, yang harus memilih keluar dengan mengirim SameSite=None. Namun, SameSite=None istirahat di iOS 12 dan beberapa versi browser lain yang lebih lama. Aplikasi ini perlu meng-sniff versi ini dan menghilangkan SameSite.

Untuk diskusi tentang masalah ini, lihat dotnet/aspnetcore#14996.

Versi yang diperkenalkan

3.1 Pratinjau 1

Perilaku yang lama

SameSite adalah ekstensi standar draf 2016 untuk cookie HTTP. Ini dimaksudkan untuk mengurangi Pemalsuan Permintaan Lintas Situs (CSRF). Ini awalnya dirancang sebagai fitur yang akan dipilih server dengan menambahkan parameter baru. ASP.NET Core 2.0 menambahkan dukungan awal untuk SameSite.

Perilaku yang baru

Google mengusulkan standar draf baru yang tidak kompatibel dengan versi lama. Standar mengubah mode default menjadi Lax dan menambahkan entri None baru untuk memilih keluar. Lax cukup untuk sebagian besar cookie aplikasi; namun, ini merusak skenario lintas situs seperti OpenID Koneksi dan login WS-Federation. Sebagian besar login OAuth tidak terpengaruh karena perbedaan bagaimana permintaan mengalir. Parameter baru None menyebabkan masalah kompatibilitas dengan klien yang menerapkan standar draf sebelumnya (misalnya, iOS 12). Chrome 80 akan menyertakan perubahan. Lihat Pembaruan SameSite untuk garis waktu peluncuran produk Chrome.

ASP.NET Core 3.1 telah diperbarui untuk mengimplementasikan perilaku baru SameSite . Pembaruan mendefinisikan ulang perilaku untuk memancarkan SameSiteMode.None SameSite=None dan menambahkan nilai SameSiteMode.Unspecified baru untuk menghilangkan SameSite atribut. Semua API cookie sekarang default ke Unspecified, meskipun beberapa komponen yang menggunakan cookie menetapkan nilai lebih spesifik untuk skenarionya seperti korelasi OpenID Koneksi dan cookie nonce.

Untuk perubahan terbaru lainnya di area ini, lihat HTTP: Beberapa cookie SameSite default diubah menjadi Tidak Ada. Dalam ASP.NET Core 3.0, sebagian besar default diubah dari SameSiteMode.Lax ke SameSiteMode.None (tetapi masih menggunakan standar sebelumnya).

Alasan untuk berubah

Browser dan perubahan spesifikasi seperti yang diuraikan dalam teks sebelumnya.

Aplikasi yang berinteraksi dengan situs jarak jauh, seperti melalui login pihak ketiga, perlu:

  • Uji skenario tersebut di beberapa browser.
  • Terapkan mitigasi sniffing browser kebijakan cookie yang dibahas di Mendukung browser lama.

Untuk petunjuk pengujian dan sniffing browser, lihat bagian berikut.

Menentukan apakah Anda terpengaruh

Uji aplikasi web Anda menggunakan versi klien yang dapat memilih perilaku baru. Chrome, Firefox, dan Microsoft Edge Chromium semuanya memiliki bendera fitur keikutsertaan baru yang dapat digunakan untuk pengujian. Verifikasi bahwa aplikasi Anda kompatibel dengan versi klien yang lebih lama setelah Anda menerapkan patch, terutama Safari. Untuk informasi selengkapnya, lihat Mendukung browser yang lebih lama.

Chrome

Chrome 78 dan yang lebih baru menghasilkan hasil pengujian yang menyesatkan. Versi tersebut memiliki mitigasi sementara dan memungkinkan cookie yang berusia kurang dari dua menit. Dengan bendera pengujian yang sesuai diaktifkan, Chrome 76 dan 77 menghasilkan hasil yang lebih akurat. Untuk menguji perilaku baru, alihkan chrome://flags/#same-site-by-default-cookies ke diaktifkan. Chrome 75 dan yang lebih lama dilaporkan gagal dengan pengaturan baru None . Untuk informasi selengkapnya, lihat Mendukung browser yang lebih lama.

Google tidak membuat versi Chrome yang lebih lama tersedia. Namun, Anda dapat mengunduh versi Chromium yang lebih lama, yang cukup untuk pengujian. Ikuti petunjuk di Unduh Chromium.

Safari

Safari 12 secara ketat menerapkan draf sebelumnya dan gagal jika melihat nilai baru None dalam cookie. Ini harus dihindari melalui kode sniffing browser yang ditampilkan di Mendukung browser lama. Pastikan Anda menguji Safari 12 dan 13 serta login gaya OS berbasis WebKit menggunakan Microsoft Authentication Library (MSAL), Active Directory Authentication Library (ADAL), atau pustaka mana pun yang Anda gunakan. Masalahnya tergantung pada versi OS yang mendasar. OSX Mojave 10.14 dan iOS 12 diketahui memiliki masalah kompatibilitas dengan perilaku baru. Meningkatkan ke OSX Catalina 10.15 atau iOS 13 memperbaiki masalah. Safari saat ini tidak memiliki bendera keikutsertaan untuk menguji perilaku spesifikasi baru.

Firefox

Dukungan Firefox untuk standar baru dapat diuji pada versi 68 dan yang lebih baru dengan ikut serta di about:config halaman dengan bendera network.cookie.sameSite.laxByDefaultfitur . Tidak ada masalah kompatibilitas yang dilaporkan pada versi Firefox yang lebih lama.

Microsoft Edge

Meskipun Microsoft Edge mendukung standar lama SameSite , pada versi 44, Microsoft Edge tidak memiliki masalah kompatibilitas dengan standar baru.

Microsoft Edge Chromium

Bendera fiturnya adalah edge://flags/#same-site-by-default-cookies. Tidak ada masalah kompatibilitas yang diamati saat pengujian dengan Microsoft Edge Chromium 78.

Electron

Versi Electron mencakup versi Chromium yang lebih lama. Misalnya, versi Electron yang digunakan oleh Microsoft Teams adalah Chromium 66, yang menunjukkan perilaku yang lebih lama. Lakukan pengujian kompatibilitas Anda sendiri dengan versi Electron yang digunakan produk Anda. Untuk informasi selengkapnya, lihat Mendukung browser yang lebih lama.

Mendukung browser yang lebih lama

Standar 2016 SameSite mengamanatkan bahwa nilai yang tidak diketahui diperlakukan sebagai SameSite=Strict nilai. Akibatnya, setiap browser lama yang mendukung standar asli dapat rusak ketika mereka melihat SameSite properti dengan nilai None. Aplikasi web harus menerapkan sniffing browser jika ingin mendukung browser lama ini. ASP.NET Core tidak menerapkan sniffing browser untuk Anda karena User-Agent nilai header permintaan sangat tidak stabil dan berubah setiap minggu. Sebagai gantinya, titik ekstensi dalam kebijakan cookie memungkinkan Anda untuk menambahkan User-Agentlogika -spesifik.

Di Startup.cs, tambahkan kode berikut:

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
}
Sakelar penolakan

Sakelar Microsoft.AspNetCore.SuppressSameSiteNone kompatibilitas memungkinkan Anda untuk memilih keluar sementara dari perilaku cookie ASP.NET Core baru. Tambahkan JSON berikut ke file runtimeconfig.template.json di proyek Anda:

{
  "configProperties": {
    "Microsoft.AspNetCore.SuppressSameSiteNone": "true"
  }
}
Versi Lain

Patch SameSite terkait akan datang untuk:

  • ASP.NET Core 2.1, 2.2, dan 3.0
  • Microsoft.Owin 4.1
  • System.Web (untuk .NET Framework 4.7.2 dan yang lebih baru)

Kategori

ASP.NET

API yang Terpengaruh


Penyebaran

Jalur host x86 pada Windows 64-bit

MSBuild

Build waktu desain hanya mengembalikan referensi paket tingkat atas

Mulai dari .NET Core SDK 3.1.400, hanya referensi paket tingkat atas yang dikembalikan oleh RunResolvePackageDependencies target.

Versi yang diperkenalkan

.NET Core SDK 3.1.400

Deskripsi perubahan

Dalam versi .NET Core SDK sebelumnya, RunResolvePackageDependencies target membuat item MSBuild berikut yang berisi informasi dari file aset NuGet:

  • PackageDefinitions
  • PackageDependencies
  • TargetDefinitions
  • FileDefinitions
  • FileDependencies

Data ini digunakan oleh Visual Studio untuk mengisi simpul Dependensi di Penjelajah Solusi. Namun, itu bisa menjadi sejumlah besar data, dan data tidak diperlukan kecuali simpul Dependensi diperluas.

Mulai dari .NET Core SDK versi 3.1.400, sebagian besar item ini tidak dihasilkan secara default. Hanya item jenis Package yang dikembalikan. Jika Visual Studio memerlukan item untuk mengisi simpul Dependensi, visual Studio akan membaca informasi langsung dari file aset.

Alasan untuk berubah

Perubahan ini diperkenalkan untuk meningkatkan performa beban solusi di dalam Visual Studio. Sebelumnya, semua referensi paket akan dimuat, yang melibatkan pemuatan banyak referensi yang tidak akan pernah dilihat sebagian besar pengguna.

Tindakan yang direkomendasikan

Jika Anda memiliki logika MSBuild yang bergantung pada item ini yang dibuat, atur properti ke EmitLegacyAssetsFileItems true dalam file proyek Anda. Pengaturan ini memungkinkan perilaku sebelumnya di mana semua item dibuat.

Kategori

MSBuild

API yang Terpengaruh

T/A


SDK

Manifes alat di folder akar

Formulir Windows

Kontrol yang dihapus

Mulai dari .NET Core 3.1, beberapa kontrol Formulir Windows tidak lagi tersedia.

Deskripsi perubahan

Dimulai dengan .NET Core 3.1, berbagai kontrol Formulir Windows tidak lagi tersedia. Kontrol penggantian yang memiliki desain dan dukungan yang lebih baik diperkenalkan dalam .NET Framework 2.0. Kontrol yang tidak digunakan lagi sebelumnya dihapus dari kotak alat perancang tetapi masih tersedia untuk digunakan.

Jenis berikut ini tidak lagi tersedia:

Versi yang diperkenalkan

3.1

Tindakan yang direkomendasikan

Setiap kontrol yang dihapus memiliki kontrol penggantian yang direkomendasikan. Lihat tabel berikut:

Kontrol yang dihapus (API) Penggantian yang direkomendasikan API terkait yang dihapus
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

Kategori

Formulir Windows

API yang Terpengaruh


Peristiwa CellFormatting tidak dimunculkan jika tipsalat ditampilkan

Sekarang DataGridView memperlihatkan teks sel dan tipsalat kesalahan saat diarahkan kursor ke mouse dan saat dipilih melalui keyboard. Jika tipsalat ditampilkan, DataGridView.CellFormatting peristiwa tidak dinaikkan.

Deskripsi perubahan

Sebelum .NET Core 3.1, DataGridView properti yang diatur ShowCellToolTips untuk true memperlihatkan tipsalat untuk teks dan kesalahan sel saat sel diarahkan oleh mouse. Tipsalat tidak ditampilkan saat sel dipilih melalui keyboard (misalnya, dengan menggunakan tombol Tab, tombol pintasan, atau navigasi panah). Jika pengguna mengedit sel, lalu, saat DataGridView masih dalam mode edit, arahkan mouse ke atas sel yang tidak memiliki ToolTipText kumpulan properti, CellFormatting peristiwa dinaikkan untuk memformat teks sel untuk ditampilkan dalam sel.

Untuk memenuhi standar aksesibilitas, mulai dari .NET Core 3.1, DataGridView yang memiliki ShowCellToolTips properti yang diatur untuk true menampilkan tipsalat untuk teks dan kesalahan sel tidak hanya saat sel diarahkan, tetapi juga saat dipilih melalui keyboard. Sebagai konsekuensi dari perubahan ini, CellFormatting peristiwa tidak dimunculkan ketika sel yang tidak memiliki ToolTipText kumpulan properti diarahkan ke saat DataGridView berada dalam mode edit. Peristiwa tidak dinaikkan karena konten sel yang diarahkan ditampilkan sebagai tipsalat alih-alih ditampilkan dalam sel.

Versi yang diperkenalkan

3.1

Tindakan yang direkomendasikan

Refaktor kode apa pun yang bergantung pada CellFormatting peristiwa saat DataGridView berada dalam mode edit.

Kategori

Formulir Windows

API yang Terpengaruh

Tidak


Lihat juga