Aspnetcore: 2.2 Diskusi peta jalan

Dibuat pada 25 Jun 2018  ·  117Komentar  ·  Sumber: dotnet/aspnetcore

Diskusi untuk pengumuman Roadmap 2.2: https://github.com/aspnet/Announcements/issues/307

Komentar yang paling membantu

Roadmap terlihat bagus, terutama health check dan HTTP 2.0. Namun, dengan cara yang paling baik , saya tidak setuju dengan kebutuhan untuk membangun server otorisasi Microsoft pihak pertama yang sederhana. IdentityServer4 mengisi celah ini dengan baik dan waktu yang dihabiskan untuk mengimplementasikan kembali versi yang lebih sederhana bisa lebih baik dihabiskan di tempat lain. Saya mengerti tujuannya adalah untuk memberikan solusi sederhana tetapi auth sulit dan IdentityServer menyediakan API yang sesederhana yang didapat. Jika ada ide untuk abstraksi yang lebih sederhana, itu dapat dibangun di atas IdentityServer sehingga orang dapat menggunakan abstraksi sederhana tetapi memiliki kekuatan jika mereka membutuhkannya.

Memperbarui

Dalam standup Komunitas ASP.NET, disebutkan bahwa tim Inti ASP.NET sedang berbicara dengan tim Server Identitas tentang opsi, termasuk membangun sesuatu di atas Server Identitas. Saya pikir itulah yang kita semua inginkan, bagus!

Semua 117 komentar

Bagaimana dengan Peta Jalan EF Core 2.2?

Bagaimana dengan Peta Jalan EF Core 2.2?

https://github.com/aspnet/Announcements/issues/308

Roadmap terlihat bagus, terutama health check dan HTTP 2.0. Namun, dengan cara yang paling baik , saya tidak setuju dengan kebutuhan untuk membangun server otorisasi Microsoft pihak pertama yang sederhana. IdentityServer4 mengisi celah ini dengan baik dan waktu yang dihabiskan untuk mengimplementasikan kembali versi yang lebih sederhana bisa lebih baik dihabiskan di tempat lain. Saya mengerti tujuannya adalah untuk memberikan solusi sederhana tetapi auth sulit dan IdentityServer menyediakan API yang sesederhana yang didapat. Jika ada ide untuk abstraksi yang lebih sederhana, itu dapat dibangun di atas IdentityServer sehingga orang dapat menggunakan abstraksi sederhana tetapi memiliki kekuatan jika mereka membutuhkannya.

Memperbarui

Dalam standup Komunitas ASP.NET, disebutkan bahwa tim Inti ASP.NET sedang berbicara dengan tim Server Identitas tentang opsi, termasuk membangun sesuatu di atas Server Identitas. Saya pikir itulah yang kita semua inginkan, bagus!

Apa rencana saat ini di sekitar ASP.NET Core WebHooks ?

Mengenai petugas operator, apakah ini mungkin di middleware? 😱
C# public async Task Invoke(HttpContext context, [FromRoute] SomeModel someModel)
[Dari Permintaan]?

Server Auth Sederhana tetapi juga ingat apa yang terjadi dengan Server Auth sederhana Katana

Saya ingin menggemakan kekhawatiran @RehanSaeed dan ingin meminta beberapa klarifikasi tentang kasus penggunaan apa yang seharusnya diisi oleh server baru ini. Jika ini terutama agar API web memiliki cara untuk mendapatkan token pembawa mereka yang valid dalam autentikasi aplikasi yang ada, maka itu akan baik-baik saja. Tetapi segala sesuatu di atas itu mungkin lebih baik diserahkan kepada solusi yang sudah ada yang telah menawarkan banyak pilihan dengan kompleksitas dan fleksibilitas yang berbeda dengan produk seperti IdentityServer, OpenIddict, dan AspNet.Security.OpenIdConnect.Server.

Bagaimana dengan hosting dalam proses IIS ?

Bisakah Anda menguraikan lebih lanjut tentang bagian TypeScript dari "Pembuatan klien API (C# & TypeScript)"?

Ini benar-benar akan menjadi sesuatu yang saya nantikan. Saat ini saya menggunakan NSwag untuk membuat Layanan API Klien Angular saya secara otomatis. Tetapi ada begitu banyak kombinasi berbeda yang mungkin untuk konfigurasi klien yang menurut saya ini bisa menjadi masalah untuk menyenangkan semua orang.

Di luar kepala saya, beberapa hal yang harus dipertimbangkan (dan jika mungkin harus dapat dikonfigurasi):

  • Hanya klien TypeScript dengan fetch atau Layanan Angular dengan HttpClient?
  • Jika Angular, versi mana yang Anda dukung (juga penting untuk RxJS)?
  • penanganan nol/tidak terdefinisi
  • penanganan enum
  • Tanggal JS atau momentjs untuk tipe tanggal?
  • Penanganan pengecualian, Penanganan kesalahan validasi
  • Bagaimana cara memperpanjang kode yang dihasilkan di klien?
  • Kemungkinan untuk mempengaruhi pembuatan nama (misalnya menjatuhkan bagian DTO dari xxxDTO untuk kelas klien yang dihasilkan atau sudah pada definisi OpenAPI)

Jika memungkinkan untuk memilih fitur, peningkatan/perbaikan untuk middlware yang ada ini akan ada di daftar keinginan saya:

Saya juga memilih untuk melewatkan produk Server Otorisasi. Keamanan rumit dan ada dorongan besar untuk pindah ke layanan cloud untuk menghapus pemeliharaan, dan siapa pun yang menginginkan kontrol lebih dapat menggunakan IdentityServer4 yang dibuat dengan baik, diuji, didokumentasikan, dan didukung. Penyiapan sederhana membutuhkan waktu 5 menit dan mereka memiliki banyak sampel pemula, video, dan tutorial.

Saya gagal melihat bagaimana Anda dapat membuat keamanan berfungsi sebagai "konfigurasi nol" lebih dari yang mereka bisa. Sepertinya ini hanya akan menambah kebingungan (dalam penamaan dan penggunaan), sementara menjadi hal lain untuk mendukung dan memelihara selama bertahun-tahun, mengambil upaya dari fitur lain terus menerus. Tolong pikirkan kembali ini.

Saya juga ingin tahu mengapa hosting dalam proses IIS tidak ada dalam peta jalan 2.2 ini. Ini adalah fitur utama dan merupakan faktor utama dalam strategi rilis kami dan jadwal sini di Stack Overflow dan itu sudah dihapus menit terakhir sebelum rilis 2.1, menjanjikan 2,2 jangka waktu gantinya . Tolong beri tahu saya ini hanya kelalaian dan bukan perubahan rencana lain.

Sunting: @DamianEdwards menjawab di Twitter bahwa ini memang sebuah kekhilafan (artinya direncanakan untuk 2.2). Fiuh!

Saya akan menggemakan komentar lain. Jika Anda akan berinvestasi dalam Otorisasi/Kebijakan, khususnya membuatnya lebih sederhana, saya pribadi lebih suka melihat kemitraan dengan orang-orang seperti OpenIddict dan IdentityServer pada dokumen dan investasi dalam perancah. Mau tak mau saya merasa bahwa pekerjaan apa pun, betapapun sederhananya, hanya akan berakhir dengan menduplikasi upaya pihak ketiga yang hebat dan menimbulkan biaya pemeliharaan yang tidak perlu pada tim aspnet.

Ini mungkin tampilan yang tidak populer, tetapi saya ingin melihat Server Microsoft Auth, yang dibangun di mata publik, dengan masukan dan dukungan kami.

Yang saat ini - Id4, OpenIddict - jelas merupakan proyek OSS yang sangat baik, dan saya tidak dapat menahan perasaan bahwa proyek dengan dukungan MS di belakangnya bisa menjadi hal yang buruk ...?

Ada batasan pada seberapa banyak dukungan yang tersedia dari sekelompok kecil orang, dan ini adalah produk yang sangat penting.

Saya pikir sangat disayangkan bahwa Kode Etik MS OSS tidak menyertakan baris yang mengatakan "Jangan mempromosikan fitur yang menduplikasi sesuatu yang dapat dibawa dengan permintaan Nuget dan yang dengan santai akan menghancurkan bisnis dua orang yang berkontribusi pada ekosistem kita".

Sinis dalam diriku bertanya-tanya apakah, untuk beberapa orang dalam, memberikan Brock dan Dominick hidung berdarah adalah fitur dari saran ini daripada bug. Apakah ini yang terjadi pada usaha kecil yang pernah memiliki keberanian untuk mengkritik apa pun yang dilakukan tim ASP?

Saya juga bertanya-tanya tentang menduplikasi fungsionalitas auth selain membangun sesuatu di atas, seperti UI dan dokumentasi.

Selain itu, pustaka JSON-LD 1.1 yang teruji dengan baik akan menjadi tambahan yang bagus dan spesifik untuk peta jalan. :)

Mengulangi apa yang dikatakan orang lain - Saya lebih suka melihat pekerjaan otorisasi dibawa dari sesuatu seperti IdentityServer4 daripada diimplementasikan sendiri. Jika ada kesenjangan maka pasti menjembatani mereka melalui kontribusi, sampel, dan menyempurnakan poin integrasi akan menjadi cara yang lebih baik. Mungkin juga memperhatikan penawaran cloud Anda di ruang ini (B2C) yang dalam keadaan mengerikan.

Di luar itu sementara Anda menyatakan tujuannya bukan untuk mereplikasi fungsionalitas dalam penawaran open source yang ada dan untuk menjaga semuanya tetap sederhana, ini agak setara dengan perangkap penulisan ulang klasik: "solusi ini terlalu rumit, dan agak berantakan, mari kita tulis ulang! ". Ini naif dan dalam waktu n versi saya akan memberi Anda uang setelah menangani banyak kasus tepi yang dibutuhkan oleh solusi dunia nyata dan sesuatu seperti IdentityServer sudah berurusan dengan.

Secara lebih luas, dengan akuisisi GitHub, ada banyak diskusi baru-baru ini seputar sikap Microsoft terhadap open source. Sangat bagus bahwa Microsoft melakukan begitu banyak pekerjaan di tempat terbuka tetapi bagian dari menjadi warga negara sumber terbuka yang baik adalah memanfaatkan sumber terbuka yang ada saat itu ada.

Ini sangat penting bagi pemegang platform seperti Anda sendiri - pemegang platform menduplikasi fungsionalitas dalam kontribusi _discourages_ penawaran open source yang ada sambil terlibat dengan kontribusi _mendorong_ penawaran tersebut.

Saya juga tidak dapat melihat titik upaya yang dikeluarkan untuk otorisasi, tetapi ingin melihat _management_ ASP.NET Core Identity ditingkatkan. Damian Edwards cukup jelas di live.asp.net bahwa kita tidak boleh menggulung keamanan kita sendiri tetapi - kecuali jika saya melewatkannya - ASP.NET Core Identity tidak berisi alat manajemen pengguna apa pun dan jadi kami harus menggulirkannya milik kita sendiri. Ini menurut saya agak menakutkan karena saya bukan ahli keamanan dan saya sangat takut meninggalkan lubang keamanan yang saya buat sendiri.

Bagaimana dengan memindahkan Pemformat konten dari level MVC ke abstraksi AspNetCore.Http di 2.2?

Mungkin PM yang bertanggung jawab dapat menulis deskripsi yang lebih rinci tentang Identity Server Lite ini untuk memperjelas kekurangan apa yang ada dalam solusi open source pihak ketiga yang ingin diatasi oleh tim ASP.NET. Karena saat ini, Anda sedang berbicara tentang menciptakan kembali roda tetapi mungkin menghapus beberapa jari-jari, dan itu tidak masuk akal. Seperti yang dikatakan orang lain, memperbaiki AAD B2C dan menyediakan integrasi kelas satu dengan itu akan sangat bagus, dan masuk akal secara bisnis untuk MS.

Juga, pernahkah Anda mempertimbangkan betapa sulitnya untuk mendapatkan produk server Auth yang baru dan baru melewati @blowdart?

Adakah rencana untuk memiliki dukungan API RESTful bawaan seperti yang dimiliki Django?
Karena itu adalah sesuatu yang cenderung ditulis oleh semua pengembang setiap saat!

Saya baru-baru ini membangun sesuatu yang dapat ditulis sebagai pengontrol API RESTful Generik:

https://github.com/0xRumple/dorm-portal/blob/master/DormPortal.Web/Controllers/StudentsController.cs

Juga setuju dengan "Saya gagal melihat bagaimana Anda dapat membuat keamanan berfungsi sebagai" konfigurasi nol "lebih dari yang mereka bisa" dan "Anda sedang berbicara tentang menciptakan kembali roda tetapi mungkin menghapus beberapa jari-jari", server identitas adalah produk yang luar biasa, sangat sederhana untuk memulai dan menyediakan ekstensibilitas untuk skenario yang lebih rumit, tidak yakin mengapa kami memerlukan versi "yang disederhanakan".

Dalam skala yang jauh lebih kecil, mengapa kita membutuhkan implementasi health check lagi. Sudah ada beberapa solusi open source misalnya

Apa perbedaan fitur dengan ini dan apa yang disediakan di 2.2?

@0xRumple Perbaikan pada ApiController akan membantu membuat ini tidak terlalu bertele-tele secara umum. Tapi tidak, Anda mungkin tidak akan melihat sesuatu yang hanya memberi Anda CRUD API untuk entitas Anda secara default. Hal seperti itu harus membuat terlalu banyak asumsi tentang DAL dan otorisasi Anda.

Jika Anda mengikuti pola tertentu dalam aplikasi Anda, tidak ada yang salah dengan membuat tipe dasar atau konvensi Anda sendiri di 2.2 yang akan menggeneralisasi pekerjaan untuk Anda.

@kieronlanning

Yang saat ini - Id4, OpenIddict - jelas merupakan proyek OSS yang sangat baik, dan saya tidak dapat menahan perasaan bahwa proyek dengan dukungan MS di belakangnya bisa menjadi hal yang buruk ...? Ada batasan pada seberapa banyak dukungan yang tersedia dari sekelompok kecil orang, dan ini adalah produk yang sangat penting.

Karena Anda bertanya tentang apakah itu bisa menjadi hal yang buruk:

Tim ASP.NET juga relatif kecil, melayani jutaan pengembang dengan kapasitas terbatas, sehingga setiap proyek baru akan menyita waktu dan tenaga dari hal-hal lain. Artinya, kita semua harus menunggu lebih lama untuk mendapatkan fitur baru yang mungkin akan memberikan nilai lebih.

Jauh lebih buruk adalah bahwa hal itu merugikan ekosistem pihak ke-3 dan menghambat produk baru karena Microsoft merilis paket "resmi", yang banyak perusahaan terjebak memilih hanya karena itu dari Microsoft meskipun secara teknis (dan dalam hal ini seharusnya) kurang mampu. ASP.NET sudah mengintegrasikan Json.NET, Polly, AutoMapper, dan banyak perpustakaan lain sehingga sepertinya salah langkah untuk membangun kembali produk keamanan yang kompleks (yang akan membutuhkan 80% dari kode dasar yang sama) ketika opsi hebat sudah ada, dan dengan begitu banyak hal yang lebih menarik di peta jalan untuk dikerjakan.

@mencolek
Anda benar, menulis kelas dasar aplikasi saya adalah ide yang bagus.

Sebenarnya saya percaya itu tidak dalam tanggung jawab kerangka kerja:

CRUD resources (repository responsibility)

Manipulating data (sieve responsibility)
    Paging
    Filtering
    Searching
    Sorting
    Shaping

Tetapi ada banyak hal yang menurut saya AspNetCore dapat dilakukan dengan lebih baik (dengan memiliki paket AspNetCore.RestFramework):

  1. HATEOAS (api yang dapat ditemukan sendiri)
  2. Jenis Media (mengatur jenis media khusus)
  3. Pembuatan versi (perbarui versi tipe media)
  4. Metadata data yang dimainpulasi (pagination menjadi header X-Pagination, filter metadata... dll).
  5. Pembatasan tarif & pelambatan.

Saya tahu ada banyak perpustakaan di luar sana, saya menemukan beberapa di sini: https://github.com/thangchung/awesome-dotnet-core... Tapi, perpustakaan pihak ketiga bukanlah pilihan yang baik untuk aplikasi perusahaan!

Hal yang sama berlaku untuk saringan, jika ada paket RESMI untuk pagination, penyaringan ... dll, pengembang tidak akan cenderung menulis perpustakaan kereta atau tidak terawat, saya menggunakan saringan ini di aplikasi saya yang saya sebutkan di atas: https:// github.com/Biarity/Sieve , tetapi perpustakaan ini dapat tidak dikelola setiap saat penulis sibuk.

Saya pikir AspNetCore cukup matang untuk mulai memikirkan solusi out-of-the-box seperti di Django, dengan cara ini kita dapat memiliki kemewahan kinerja asp dan kelincahan Django .

Namun, perpustakaan pihak ketiga bukanlah pilihan yang baik untuk aplikasi perusahaan!

^ Inilah mengapa kita tidak dapat memiliki hal-hal yang baik

Namun, perpustakaan pihak ketiga bukanlah pilihan yang baik untuk aplikasi perusahaan!

Ya, itulah pola pikir yang perlu diubah di sini. ASP.NET Core dan .NET Core adalah open source dan ekosistem mereka _is_ merangkul komunitas open source dan harus terus melakukannya. Tidak hanya dengan solusi open source yang merupakan bagian dari .NET Foundation, tetapi solusi apa pun sebenarnya.

tapi perpustakaan ini bisa tidak terawat setiap saat penulis sibuk

Dan dengan cara yang sama, sebuah paket “resmi” dapat menjadi tidak terawat setiap saat perusahaan mengalihkan kepentingannya. Ini telah terjadi dengan hal-hal khusus Microsoft sebelumnya, termasuk beberapa paket sumber terbuka yang mereka terbitkan, tetapi sangat alami bagi perusahaan mana pun.

Jika Anda memutuskan untuk mengambil ketergantungan pada perpustakaan yang lain, itu adalah tanggung jawab Anda bahwa Anda dapat hidup dengan itu. Terlepas dari siapa penulisnya. Hal yang menyenangkan tentang open source adalah bahwa meskipun penulis akhirnya tidak merespons, Anda sepenuhnya berhak untuk mengubahnya sendiri.

Saya sangat menentang mengharapkan solusi resmi Microsoft untuk semua yang mungkin dapat Anda temukan. Bukan hanya karena tidak pernah ada solusi satu-untuk-semua, yang membuat hal ini sangat sulit dan pada saat yang sama mungkin tidak terkendali, tetapi terutama juga karena hal ini menghilangkan sumber daya dari bagian-bagian kerangka kerja yang benar-benar membutuhkan perhatian. Dan pada saat yang sama itu menyakiti ide open source benar-benar sangat buruk .

Jika Anda sedang membangun aplikasi perusahaan dan masih berjuang dengan sindrom NIH ini (atau "tidak ditemukan di <perusahaan besar>"), Anda harus benar-benar bangun karena ini tahun 2018 dan Anda mungkin harus merangkul open source sekarang.

Anda benar Microsoft dapat berhenti memelihara paket apa pun, tetapi setidaknya mereka memiliki LTS tertentu: https://www.microsoft.com/net/support/policy

Misalnya support .NET Core 1.1 berakhir pada 27 Juni 2019... dengan cara ini saya bisa yakin jika saya menggunakan versi ini saya tidak akan lumpuh di tengah.

Saya pernah menggunakan tag-helper pagination pihak ke-3, dan itu tidak menyenangkan, penulis pada dasarnya mengatakan kepada saya bahwa dia tidak akan memperbaikinya untuk .NET Core 1.1, dan saya harus memperbarui proyek, itu adalah sistem universitas, menjadi 2.0 (dan dia berhak melakukannya karena dia menulis paket itu secara GRATIS).

Inilah masalahnya, di perusahaan, ini tidak berhasil... Anda tidak dapat meyakinkan seluruh tim bahwa Anda harus pindah ke 2.0 saat aplikasi sedang berjalan hanya karena pagination-tag-helper tidak' tidak bekerja!
Jadi Anda cukup menggunakan mulai meretas sumber seperti yang saya lakukan dengan menggunakan dekorator: https://github.com/cloudscribe/cloudscribe.Web.Pagination/issues/37

Dan ya, siapa bilang saya bukan penggemar berat open-source :confused: ?

@0xRumple bukankah ide open source untuk berkontribusi dan berkolaborasi?

Jika tag-helper pagination pihak ke-3 itu tidak ada, Anda harus menulisnya sendiri dan tetap mempertahankannya, "di perusahaan".

Inilah masalahnya, di perusahaan, ini tidak berhasil... Anda tidak dapat meyakinkan seluruh tim bahwa Anda harus pindah ke 2.0 saat aplikasi sedang berjalan hanya karena pagination-tag-helper tidak' tidak bekerja!

Daripada mencoba untuk "meyakinkan seluruh tim bahwa Anda harus pindah ke 2.0", kontribusikan pembaruan kembali dan bantu daripada mengandalkan orang lain untuk melakukan pekerjaan atau menunggu Microsoft untuk memberikan yang setara. Jika pemilik tidak mau menerima kontribusi Anda, lanjutkan dengan garpu untuk kebutuhan Anda.

Saya kira jenis pemikiran Anda (sama sekali tidak bermaksud menyinggung) adalah bagian besar mengapa ada diskusi seputar "server otorisasi Microsoft" vs server identitas. Bagaimana open source akan bekerja jika pengembang tidak mau berpartisipasi. Haruskah kita menunggu Microsoft menyediakan semua kode yang kita butuhkan?

Saya setuju dengan banyak orang di sini bahwa Microsoft harus berhati-hati agar tidak mematikan proyek sumber terbuka yang bagus di ekosistem dengan membuat pengganti mereka sendiri untuk semuanya.

Saya sebenarnya penulis perpustakaan taghelper pagination yang disebutkan oleh @0xRumple , masalahnya benar-benar dengan komponen daftar halaman bukan dengan taghelper yang sebenarnya memiliki nuget lama yang mendukung 1.x aspnet core. Daftar halaman benar-benar sesuatu yang merupakan bagian dari perpustakaan pager open source sebelumnya yang menginformasikan desain perpustakaan saya dan digunakan di halaman demo pada satu waktu tetapi pager taghelper tidak bergantung pada implementasi daftar halaman dan ada halaman lain daftar implementasi di luar sana yang bisa dia gunakan saat masih menggunakan pager taghelper. Sebenarnya saya telah menghapus daftar halaman sepenuhnya dari perpustakaan itu karena itu bahkan bukan bagian dari taghelper dan tidak pernah ada.

Ini benar-benar tidak berbeda untuk menggunakan paket nuget dari pengembang OSS dari Microsoft jika Anda terjebak pada aspnet core 1.1 maka Anda tidak bisa mendapatkan perbaikan dan peningkatan dari aspnet core 2.x kecuali Anda memperbarui ke kerangka kerja baru.

@joeaudette
Saya baru saja menyebutkan contoh itu untuk menggambarkan poin saya tentang solusi bawaan vs. pihak ketiga, saya masih berterima kasih atas pekerjaan Anda pada taghelper pagination itu ... universitas menggunakan paket pagination Anda dan mereka senang :heart:

@alhardy

Haruskah kita menunggu Microsoft menyediakan semua kode yang kita butuhkan?

Ini adalah masalah utama, kami berpikir bahwa ketika Microsoft membawa solusi resmi, mereka akan melawan solusi open-source lainnya atau mereka akan menulis setiap baris kode sendiri :smile:

Tentu saja tidak, kami dapat yang terbaik dari kedua dunia, solusi resmi dan berbasis komunitas jika Microsoft mengadopsi solusi yang tepat dan menciptakan solusi yang hilang, sehingga pengembang dapat fokus untuk berkontribusi pada solusi tersebut.

Komunitas django melakukannya dengan benar, mereka menyediakan/mengadopsi secara resmi solusi sederhana awal untuk masalah tertentu, misalnya kerangka RESTful, dan komunitas membangun di atasnya... lihat di sini pada tahap awal mereka membangun django-rest- kerangka kerja: https://www.djangoproject.com/weblog/2016/jun/22/django-rest-framework-funding/

Mereka memulai proyek awal, dan komunitas sedang meningkatkan/membangun di atas itu, ini adalah repo mereka: https://github.com/encode/Django-rest-framework... sekitar 800 kontributor!
Dan komunitas terdorong untuk membangun paket yang memecahkan masalah di atas paket itu seperti django-rest-auth atau django-rest-framework-jwt .

Setidaknya mereka menyediakan "solusi resmi" yang dibutuhkan sebagian besar pengembang, seperti django-admin-site atau django-debug-toolbar . Ini juga berasal dari filosofi Python "termasuk baterai", pada awalnya, saya pikir itu buruk karena berusaha untuk solusi penyebut yang paling tidak umum, dan saya kemudian menyadari angin yang dibawanya.

*PS: Dapper (oleh StackExchange) dan EFCore (oleh Microsoft) keduanya adalah ORM, tetapi keduanya bertujuan untuk memecahkan masalah yang sama dalam pendekatan yang berbeda. Dapper awalnya dibuat pada tahun 2011 sementara EFCore 2014... apakah EFCore mempengaruhi proyek open-source dengan buruk? tentu saja tidak, dan ini adalah solusi resmi!
Orang-orang sudah membangun di atas hal-hal luar biasa itu, seperti ini: https://github.com/crhairr/EntityFrameworkCore.MongoDb/

apakah EFCore sangat memengaruhi proyek sumber terbuka?

Uuuh, ada yang ingat NHibernate (yang fungsinya paling dekat dengan EF)? Tidak, mungkin tidak, karena sama saja mati setelah EF dirilis

@0xRumple

Tentu saja tidak, kami dapat yang terbaik dari kedua dunia, solusi resmi dan solusi berbasis komunitas jika Microsoft mengadopsi solusi yang tepat dan menciptakan solusi yang hilang,

Dalam hal ini, bukan karena itu menciptakan kembali solusi yang ada, tetapi dengan fungsionalitas yang lebih sedikit.

Entity Framework dan Dapper sangat berbeda. EF selalu dirancang untuk menjadi ORM berfitur lengkap, dan keduanya datang bertahun-tahun setelah Linq-To-SQL yang asli pada tahun 2007 .

Namun, saya juga tidak berpikir Anda salah dan sepertinya kita semua berbicara melewati satu sama lain. Utas sebagian besar adalah komentar tentang produk server auth saat Anda berbicara tentang pustaka terkait REST, yang tampaknya kecil dan cukup fokus untuk disertakan dalam kerangka kerja web. Saya setuju bahwa parameter search/paging/filter akan membantu untuk memiliki kode API Web bawaan.

Diskusi ini tidak mengakui kebenaran yang canggung bahwa di beberapa organisasi, pengembang harus memperhitungkan setiap paket open source yang diperkenalkan ke dalam solusi mereka. Dalam beberapa kasus, ini adalah pemindaian otomatis yang akan menghasilkan laporan "Risiko" yang sering kali perlu ditinjau oleh manajer risiko non-teknis. Alat-alat ini akan menandai apa pun yang tidak dipelihara secara aktif dan apa pun dengan apa pun yang tampak seperti lisensi copyleft.

Anda juga dapat membayangkan bahwa dalam organisasi-organisasi ini berkontribusi kembali ke open source dipandang sebagai pembicaraan gila.

Ya, Identity Server 4 luar biasa. Tetapi bagi manajer risiko non-teknis itu adalah sesuatu yang kami tidak memiliki jaminan, sesuatu yang didukung oleh segelintir orang dan bahkan lebih buruk lagi - sesuatu dengan kode sumber yang tersedia untuk dilihat semua orang. Orang ini salah arah tetapi rata-rata pengembang di lapangan tidak akan memenangkan pertarungan ini.

"Identity Server Lite" seperti yang tepat dikatakan oleh @markrendle , terutama yang ditulis oleh staf Microsoft dapat menjadi perbedaan dalam diizinkan untuk menggunakan .NET Core sama sekali atau tidak, terutama jika ada arsitek perusahaan dalam organisasi yang bersikeras bahwa beberapa $$ $$$ Sampah perusahaan dari HP atau IBM digunakan sebagai pengganti autentikasi.

@edandersen

Tetapi bagi manajer risiko non-teknis itu adalah sesuatu yang kami tidak memiliki jaminan, sesuatu yang didukung oleh segelintir orang dan bahkan lebih buruk lagi - sesuatu dengan kode sumber yang tersedia untuk dilihat semua orang.

Saya cukup yakin orang-orang IdentityServer akan memberikan beberapa dukungan jika Anda membayar mereka untuk itu - sama seperti Anda akan membayar Microsoft. OSS tidak sama dengan gratis.

Apa yang membuat Anda berpikir tim ASP.NET Core di Microsoft bukan "segelintir orang"? Spoiler... mereka berjumlah 20-30 orang. Hanya pasangan yang akan mengerjakan produk seperti itu.

Saya sangat ingin tahu mengapa "kode sumber yang tersedia untuk dilihat semua orang" adalah hal yang buruk? Dan apa yang membuat Anda berpikir produk di Microsoft ini tidak akan open source? Ini default baru.

@khellang "kode sumber yang tersedia untuk dilihat semua orang" menjadi jelas ini adalah hal yang baik! Tetapi Anda akan terkejut dengan argumen yang harus dimiliki beberapa pengembang di tempat kerja. Sayangnya, poin "Microsoft menulisnya" adalah satu-satunya argumen yang dapat diterima kadang-kadang. Catatan Saya bermain advokat setan untuk perusahaan disfungsional hipotetis tapi khas.

Dan tentu saja pengembang yang sama dapat menganjurkan bahwa majikan mereka membayar untuk dukungan untuk Identity Server, tetapi proses pengadaan mungkin akan merampas keinginan mereka untuk hidup.

Nah, jika kita mulai menggunakan argumen manajer non-teknologi ini, segalanya akan mulai menjadi gila. IMHO, orang yang bukan teknologi, tidak boleh mendikte apa yang harus digunakan atau tidak. Jika mereka ingin mengatakan, setidaknya mereka harus tahu apa yang mereka bicarakan, dan mengatakan bahwa paket yang dikenal baik seperti IdentityServer kurang berkualitas daripada paket MS, bagi saya, itu jelas salah. Saya akan lari dari perusahaan seperti itu!

Tapi intinya di sini adalah bahwa hampir semua orang setuju bahwa menghabiskan waktu untuk sesuatu yang sudah ada, itu solid dan BANYAK orang yang menggunakannya agak aneh. Saya bertanya-tanya apa alasan sebenarnya di balik ini.. Saya tidak berpikir itu hanya seperti: Oh, mari kita membangun milik kita sendiri, hanya karena kita bisa. Apakah pelanggan benar-benar meminta ini yang mungkin tidak kita sadari?

Secara pribadi, saya tidak melihat pesaing lain di ruang OAuth-Server sebagai masalah, tetapi hal yang baik.

Ini dapat membantu mendorong pengembangan di area ini, atau hanya berfungsi sebagai solusi cepat dan kotor untuk orang-orang yang tidak membutuhkan lebih dari itu - solusi cepat dan kotor.

Jika Anda menginginkan atau membutuhkan lebih banyak dari server OAuth, maka tidak ada yang menghentikan salah satu dari kami untuk menggunakan solusi yang ada. Atau, jika Anda ingin template sekali klik melakukan OAuth dasar _dan tidak lebih_, maka ini sepertinya tujuan yang layak, setidaknya bagi saya.

Saya pikir utas ini telah berubah menjadi tit-for-tat tentang apa itu OSS, apa yang baik dilakukan MS dan apa yang tidak baik di MS, daripada berfokus pada apa yang ada di peta jalan untuk .NET Core 2.2, itulah yang sebenarnya penting di sini.

@khellang
"NHibernate sudah mati", kata siapa? Saya melihat proyek itu masih hidup, dan bahkan memiliki momentum yang lebih baik daripada Dapper
https://github.com/nhibernate/nhibernate-core/graphs/contributor
https://github.com/StackExchange/Dapper/graphs/contributor

Ah, saya tidak menyebutkan IdentityServer sampai sekarang untuk tetap pada poin saya memiliki kerangka RESTful dalam paket aspcore resmi ... inilah pemikiran saya tentang IdentityServer, ini sangat solid dan hebat, TAPI ini adalah proyek 2 orang, lihat metriknya:
https://github.com/IdentityServer/IdentityServer4/graphs/contributor

Sekitar 85% dari pekerjaan dilakukan oleh 2 orang dan tidak apa-apa untuk proyek terkait keamanan, tetapi di perusahaan banyak perusahaan berpikir tentang pemeliharaan proyek tersebut di masa depan. Baru-baru ini sebuah perusahaan memberi tahu saya bahwa mereka ingin saya menggunakan React alih-alih Vus.Js dalam proyek mereka hanya karena mereka mengatakan "vue.js cukup mirip dengan Evan You"... dan saya pikir mereka benar. Dan inilah yang ingin saya katakan sejak awal diskusi tentang memiliki paket RESTful di dalam paket resmi, perusahaan besar mana pun tidak akan menerima Anda menggunakan paket "potensial" yang tidak dipelihara pada proyek mereka.

Hal yang sama berlaku untuk manipulasi / penyaringan data (paging, membentuk, menyortir ... dll) karena hampir setiap proyek berisi persyaratan itu, dan ya seperti yang dikatakan @manigandham , mereka terstandarisasi dan langsung.

@manigandham
Persis itulah yang menurut saya benar... mengadaptasi dan mendukung solusi secara resmi , baik secara finansial atau berkontribusi melalui github atau setidaknya menyebutkannya dalam dokumen atau kursus mereka (saya telah melihat Hanselman menyebutkan SwashBuckle dalam salah satu kursusnya di Microsoft Virtual Akademi yang benar-benar hebat, dan akan lebih baik untuk melihat lebih banyak adaptasi untuk proyek semacam itu!).

@kieronlanning
Anda benar, kita sudah terlalu jauh dari topik utama... tetapi seperti yang saya sebutkan sebelumnya, asp core baru saja menjadi sangat matang (berperforma dan dapat diandalkan), dan saya pikir inilah saatnya untuk memulai dengan yang tidak biasa. -solusi kotak .

Saya pikir mendiskon sebuah proyek karena memiliki dua kontributor utama sangat konyol. IS4 terpelihara dengan sangat baik dan kedua orang itu menghabiskan banyak waktu menjawab pertanyaan dan membantu orang. Ini juga secara luas dianggap sebagai salah satu solusi FOSS terbaik untuk server OAuth2 di pasar.

"NHibernate sudah mati", kata siapa? Saya melihat proyek itu masih hidup, dan bahkan memiliki momentum yang lebih baik daripada Dapper

@0xRumple Saya berkata "sebaiknya mati" Anda tampaknya memiliki beberapa metrik yang sangat aneh tentang kesehatan dan penggunaan proyek OSS. Apakah adil untuk membandingkan jumlah komitmen pada proyek dari tahun 2003 dengan yang telah berjalan sejak 2011? Mereka juga _sangat_ binatang yang berbeda (seperti yang disebutkan sebelumnya di utas); Dapper telah "lengkap" (bukan berarti tidak terawat, ditinggalkan, dll.) untuk beberapa waktu, sementara NHibernate (dan set fiturnya) tertinggal.
Saya tahu proyek ini masih berjalan, tetapi saya tidak ingat kapan terakhir kali, dalam 7 tahun terakhir saya berkonsultasi di ruang .NET, di mana saya menemukan NHibernate di alam liar (di mana itu tidak dalam proses sedang bermigrasi ke Entity Framework). Setiap orang yang telah mengikuti ruang ini beberapa tahun terakhir tahu betul bahwa NHibernate telah tertinggal dan kehilangan pangsa pasar ke Entity Framework. Lihat saja nomor unduhan NuGet saja: Entity Framework memiliki 45.8M vs. NHibernate dengan 3.4M.

Bagaimanapun, intinya bukan Entity Framework vs NHibernate. Itu hanya _one_ contoh. Kami telah melakukan diskusi ini berulang-ulang; baru-baru ini ketika Microsoft meluncurkan implementasi wadah IoC ringan mereka sendiri di ASP.NET Core atau ketika Microsoft sedang mempertimbangkan untuk meluncurkan objek mapper mereka sendiri. Setiap kali Microsoft memasuki ruang di komunitas OSS, itu menyedot banyak (kebanyakan?) udara keluar dari ruangan. Cukup sering untuk proyek yang lebih kecil yang digerakkan oleh komunitas untuk mati lemas seiring waktu. Saya, dan sebagian besar masyarakat, mengetahuinya dengan baik; tidak mungkin untuk bersaing dengan Microsoft di dunia (.NET) milik Microsoft sendiri. Saya sepenuhnya mengerti bahwa mereka memiliki pelanggan yang membayar yang harus mereka puaskan, jadi saya tidak mengharapkan umpan balik ini mengubah pikiran mereka :senyum:

Fitur luar biasa :)

Di mana saya bisa mendapatkan informasi lebih lanjut untuk fitur Health check?

Tingkatkan manajemen sertifikat yang ditandatangani sendiri

Saat mengembangkan aplikasi web yang memanggil API web terkait, ada saatnya berguna untuk mengujinya dengan pengguna internal melalui jaringan lokal. Anda mungkin telah lulus semua unit, tes fungsional dan integrasi, tetapi tidak ada yang benar-benar merusak sesuatu seperti manusia.

Dengan semangat untuk memisahkan masalah, aplikasi web saya memanggil beberapa API web. Dalam contoh pertama saya mengembangkan API web ini menggunakan https://localhost :. Setelah API web siap (cukup), saya kemudian mempublikasikannya ke IIS di mesin lokal saya. Setiap situs memiliki nama host yang sesuai yang telah saya siapkan di server DNS internal saya. Pada titik ini saya menggunakan Barry Dorrans' - @blowdart - https://Gist.github.com/blowdart/1cb907b68ed56bcf8498c16faff4221c untuk membuat sertifikat server. Asalkan saya mengimpor sertifikat ke semua toko yang tepat, semuanya berfungsi di mesin saya tanpa alarm.

Ini berubah ketika orang lain di jaringan mengakses aplikasi web (panggilan API semuanya ada di dalam kotak pengembangan saya). Peringatan mengerikan diterima oleh pengguna. Saya memberi tahu mereka untuk mengabaikan peringatan ini dan, jika memungkinkan dan cukup lugas, mengimpor sertifikat. Karena sertifikat yang ditandatangani sendiri ini memiliki nama penerbit dan nama umum yang sama, setiap aplikasi web baru memicu halaman peringatan

Mau tak mau saya berpikir bahwa meminta pengguna di organisasi seseorang untuk membuka halaman peringatan adalah ide yang buruk.

Sebagai non-spesialis keamanan, ada beberapa hal yang ingin saya lihat:

  • kemampuan untuk memiliki sertifikat root lokal untuk semua sertifikat pengembangan yang saya buat dan kemudian diberi tahu cara resmi untuk mengimpornya ke perangkat PC, Mac, Android, iPad, dan iPhone, sehingga halaman yang mengkhawatirkan ini tidak lagi muncul

  • metode yang lebih mudah untuk menghasilkan sertifikat untuk API yang dapat digunakan dengan IIS dan Kestrel yang mengisi semua penyimpanan sertifikat yang benar dengan benar

@CrispinH Sejujurnya mendukung root CA akan, baik, kekhawatiran memutar root CA. Jika Anda berada pada titik itu, maka inilah saatnya untuk mempertimbangkan menjalankan root CA sendiri dan mengelolanya. Dukungan yang ditandatangani sendiri, baik meskipun alat global atau skrip saya hanya untuk itu, pengembangan. Setelah Anda mulai membiarkan orang melampirkannya, Anda berada di luar cakupan fitur itu. Jika Anda berada di sebuah organisasi dan ingin orang mengakses layanan, maka organisasi tersebut perlu mengetahui strategi sertifikat mereka, menjalankan CA internal melalui Windows atau OpenSSL dan mendorong root keluar melalui kebijakan AD atau cara lain.

@blowdart Salah satu alasan saya mengembik adalah bahwa saya telah menghabiskan beberapa hari mencoba memutar CA root dan gagal melakukannya dengan benar meskipun kurangnya kompetensi di bidang ini. Saya bahkan mencoba mencari cara untuk mengubah Intisari Anda untuk menerima CA Root lokal.
Semua dokumentasi yang saya temukan terlalu umum - yang saya inginkan hanyalah proses untuk membuat sertifikat (idealnya berdasarkan Root CA) semata-mata untuk melindungi API dan aplikasi web dengan sertifikat server. Mungkin hanya dokumentasi kasus khusus yang diperlukan.

@CrispinH Window Server hadir dengan Otoritas Sertifikat yang dapat Anda atur, jika Anda ingin sepenuhnya.

Sertifikat pada umumnya bukan merupakan topik yang mudah dan Anda akan harus belajar cukup sedikit untuk melakukannya dengan benar.

Untuk tujuan pengembang, sertifikat yang ditandatangani sendiri benar-benar baik dan mudah digunakan. Segala sesuatu di luar itu, termasuk menyiapkan dan mengelola CA, tidak lagi untuk tujuan pengembangan dan pasti di luar jangkauan dan terlalu rumit untuk kerangka aplikasi web.

@CrispinH Seperti yang dikatakan @poke , sulit untuk memperbaikinya. Setelah Anda memiliki mesin yang mempercayai root CA maka sertifikat apa pun yang dikeluarkan akan dipercaya, Dan devs menjalankan kode yang tidak dipercaya pada kotak dev mereka, itulah paket nuget. Jadi pertimbangkan sesuatu yang mencuri CA root Anda. Dalam kehidupan nyata, Root CA cenderung tetap offline, mereka menandatangani sertifikat kedua, yang dibatasi dalam apa yang dapat dilakukannya, Sertifikat Server dan Klien biasanya, dan kemudian sertifikat dikeluarkan oleh itu, oleh contrust banyak CA dev dibatasi, jadi kompromi berarti kemampuan untuk mengeluarkan sertifikat penandatanganan kode tepercaya. Tanpa bermaksud menghina CA secara mengerikan bukanlah sesuatu yang harus dijalankan oleh seorang dev, sebaiknya diserahkan kepada mereka yang memahami konsekuensinya, dan konsekuensinya bisa mengerikan. Lalu ada rotasi sertifikat, pencabutan, OCSP dan banyak lagi yang perlu dipertimbangkan. Saya harus memiliki CA uji untuk middleware auth sertifikat saya, dan itu ada di VM yang dimatikan. Saya menjadi sangat gugup ketika saya menyalakannya untuk mendapatkan lebih banyak sertifikat tes.

Jika Anda benar-benar ingin turun ke root ini (pun intended) maka https://infiniteloop.io/powershell-self-signed-certificate-via-self-signed-root-ca/ mungkin membantu Anda memulai di PowerShell, tetapi itu tidak memberi Anda dukungan CRL atau OCSP atau pencabutan. https://Gist.github.com/Soarez/9688998 tampaknya mencakup OpenSSL. Dan jika Anda membutuhkan CRL maka ada CA yang terpasang di windows, pengaturan ini didokumentasikan di sini https://leastprivilege.com/2008/08/14/how-to-build-a-developmenttestdemo-ca/

_Perhatikan bahwa saya belum pernah menggunakan salah satu tautan di atas (walaupun saya mempercayai penulis yang terakhir), dan ini sama sekali bukan jenis rekomendasi MSFT resmi. Rekomendasi resmi dari tim keamanan ASP.NET adalah membiarkan seseorang yang memahami infrastruktur dan risiko menyiapkan CA perusahaan untuk Anda. Bicaralah dengan departemen TI Anda_

@blowdart Tidak, saya benar-benar _tidak_ ingin turun ke 'root' itu. Senang mengetahui alasannya sekarang.

Sepertinya pengujian humanoid saya harus dilakukan di internet publik pada host uji menggunakan sertifikat Let's Encrypt, tetapi dengan dinding otentikasi untuk menghindari pengintaian.

Tergantung pada apa yang Anda butuhkan dan anggaran Anda, beberapa perusahaan seperti DigiCert menawarkan layanan PKI terkelola. Itu bisa menggunakan root pribadi atau publik mereka. Saya tidak tahu biayanya.

Dan jika itu hanya HTTPS, ingat Anda mendapatkan sertifikat untuk setiap subdomain azurewebsites.net.

Mempertimbangkan implementasi OpenID baru, alih-alih implementasi lain untuk mempelajari, merangkul, dan terlibat dengan upaya komunitas IdentityServer4 dan berkontribusi untuk membuat versi IdentityServer "Lite" yang berpendirian yang dapat disertakan dari nuget dan penyiapan dengan upaya minimal.

Anda semua bereaksi berlebihan.
Tim ASP.NET sudah berpikir seperti Anda semua. @DamianEdwards membicarakannya di Komunitas Standup terbaru.

Inilah bagian yang paling relevan (tetapi saya mendorong Anda untuk mendengarkan semuanya):

"Kami sebenarnya sedang berbicara dengan orang-orang IdentityServer tentang itu sekarang."
https://youtu.be/Tzh2EXwgEk8?t=25m15s

Sangat menarik untuk melihat betapa bergairahnya diskusi seputar proyek "server otorisasi MSFT" :smile:

Kebetulan, Vittorio Bertocci menghubungi saya tepat 2 tahun yang lalu untuk mengobrol tentang proyek ini karena mereka mempertimbangkan untuk menggunakan OpenIddict (server OIDC yang saya kembangkan dan pelihara) sebagai basis untuk proyek ini.
Tahun lalu, saya diberitahu bahwa mereka lebih suka menggunakan implementasi mereka sendiri daripada memanfaatkan OSS pihak ketiga karena dianggap "terlalu strategis" dari perspektif bisnis (yang merupakan sesuatu yang dapat saya pahami).

Saya senang melihat mereka berubah pikiran dan akhirnya mempertimbangkan untuk menggunakan solusi OSS yang ada seperti IdentityServer4 daripada membuat hal lain dari awal: ini adalah sinyal yang sangat bagus yang dikirim ke komunitas .NET :clap:

Ini sedikit keluar dari utas, tetapi @CrispinH , sepertinya Anda mencari sedikit https://stackoverflow.com/questions/51123289/how-to-generate-a-response-to-a-csr- in-net-core-ie-to-write-a-csr-signing-se. .NET Core 2.0 menyertakan fasilitas lain untuk membuat dan bekerja dengan sertifikat juga. Lihat komentar tentang menjalankan CA juga. Perkakas perpustakaan hampir ada dan tergantung organisasi Anda, Anda mungkin dapat menggunakan sertifikat dalam beberapa cara yang terkontrol di beberapa server tanpa mengatur banyak intrastruktur. Pada token itu, membaca (dikodekan DER) permintaan penandatanganan sertifikat (CSR) di luar kotak akan menjadi tambahan yang bagus -- bersama dengan perpustakaan JSON-LD. Dan lebih banyak kripto secara umum. :)

Saya ingin melihat beberapa middleware seperti dukungan untuk LetsEncrypt - bekerja dengan Layanan Aplikasi di Windows, Linux, dan Docker di Azure.

@kieronlanning Saya setuju, selain pengkodean DER sehubungan dengan penandatanganan CSR yang disebutkan sebelumnya (walaupun menambahkan dukungan tanpa Certes , tetapi dibutuhkan ketergantungan pada BouncyCastle . Alangkah baiknya jika seseorang membantu untuk menjadi .NET Standard 2.0 saja. Salah satu alasan bagi saya adalah BouncyCastle tidak bekerja dengan baik dengan Orleans TaskScheduler . :)

Tentang penyebutan crypto, meskipun tidak sepenuhnya merupakan masalah ASP.NET Core, MS tampaknya sangat mendorong blockchain, tetapi .NET kurang memiliki kemampuan crypto. _Di permukaan_ banyak hal ini berkaitan dengan inti ASP.NET juga (seperti, misalnya, berbagai implementasi penjelajah blockchain, seperti https://etherscan.io/) dan akan menyenangkan jika ada lebih banyak dukungan untuk perpustakaan seperti Inferno dan hanya lebih banyak kemampuan yang dimasukkan ke dalam platform. Satu masalah yang luar biasa adalah di https://github.com/sdrapkin/SecurityDriven.Inferno/issues/10#issuecomment -395778931 (meminjamkan beberapa mata di sini jika seseorang memiliki daging untuk membantu).

Ini dari @kieronlanning akan menjadi permintaan fitur nomor satu saya:

"Saya ingin melihat beberapa middleware seperti dukungan untuk LetsEncrypt."

Inilah masalah terbuka: https://github.com/aspnet/Home/issues/1190. Silakan pergi dan upvote itu.

Apakah paket pesan dianggap tersedia di inti asp.net untuk semua kerangka kerja dan tidak hanya di SignalR ? Karena framming Http2 adalah biner, apakah Anda mempertimbangkan messagepack untuk itu?

server otorisasi dirilis pada preview3?

Itu sudah ada. Https://IdentityServer.io

@paling tidak istimewa
Saya suka dan menggunakan IdentityServer
Tapi saya sangat ingin tahu untuk melihat implementasi Microsoft dan dan memahami mengapa (microsoft) tidak memasukkan server identitas ke dalam inti Anda

@danroth27 - dapatkah Anda membagikan yang terbaru?

Microsoft menggunakan IdentityServer.

Jadi bagaimana ini bekerja? Microsoft menggunakan kode IDS4 secara langsung? Microsoft memangkas fitur IDS4? Apa model di sini? Apa yang harus menjadi harapan kita? Apakah ada kemungkinan jalur migrasi di antara mereka?

Microsoft akan menggunakan paket nuget standar kami dan menggunakan API konfigurasi kami untuk memberi Anda beberapa pengaturan default untuk bermain bagus dengan template dan ASP.NET Identity. Itu saja.

Anda dapat mencapai hal yang sama persis hari ini.

Ini mungkin saya, tetapi saya terkejut membaca bahwa celah server otorisasi Microsoft diisi oleh IdentityServer4. Sesuai pemahaman saya, perhatian utama IdentityServer adalah otentikasi, bukan otorisasi.

Bagi saya IdentityServer baik-baik saja sebagai server otentikasi, tetapi tidak berfungsi sebagai server otorisasi. Saya berasumsi bahwa itulah alasan PolicyServer dibuat.

@leastprivilege Akankah IdentityServer diperpanjang dengan sesuatu seperti PolicyServer?

@Ruard Jadi ini membingungkan (dan Dominick mungkin akan merasa ngeri atau memilih penjelasan saya).

OAuth adalah otentikasi, tetapi memiliki otorisasi sebagai langkah pertama, dan kemudian mengeluarkan hibah berdasarkan cakupan dll. Jadi, dalam pembungkusan kami, Identity Server akan melakukan login, memvalidasinya, memvalidasi cakupan yang diperlukan (yang dalam kasus awal akan selalu berhasil karena kami menggunakan cakupan default), lalu berikan token kembali ke pemanggil, yang kemudian dikirim ke API yang akan memvalidasinya, dan kemudian, secara opsional, Anda dapat melangkah lebih jauh dengan aturan otorisasi dalam API. OIDC membuat OIDC bingung lebih jauh dengan menjadi cara untuk memperoleh informasi identitas pengguna, termasuk otorisasi bahwa aplikasi diizinkan untuk memilikinya ...

Jadi, pada dasarnya, Identity Server akan memberi kami identitas, mengizinkan aplikasi untuk memilikinya, dan kemudian Anda dapat menggunakan bagian otorisasi ASP.NET untuk mengontrol akses lebih lanjut.

@MichelZ akan ada cerita dewasa. Kami akan mengonfigurasi untuk skenario sederhana, dan begitu Anda keluar dari skenario tersebut, Anda dapat menjelajahi kekuatan penuh dari model konfigurasi IdentityServer.

@blowdart Kami sudah menggunakan IdentityServer (dan terkesan dengan kemampuannya!), Namun mendapatkan manfaat dari kebijakan "dukungan jangka panjang" Microsoft juga merupakan nilai tambah yang besar bagi kami. Jadi sinergi apa pun yang dapat Anda berikan di sini sangat disambut.
Kami menyukai kedua produk, ASP.NET Core dan IdentityServer (4) dengan cara yang sama. Ini jelas merupakan langkah ke arah yang benar IMHO.
Namun, kami juga menyadari bahwa semua protokol ini tidak sepenuhnya "langsung". Mereka bukan ilmu roket yang Anda pahami, tapi tetap saja, mereka juga tidak lurus ke depan.

Saya berharap seseorang akan menciptakan protokol yang BENAR - SEMUA implementasi warisan dan fokus pada masa depan.

Jika Anda sudah menggunakannya, maka penggunaan Anda tidak akan benar-benar berubah, Anda sudah berhasil :)

Kami membidik File New > Web API dengan Individual Authentication, lalu menambahkan API lain, dan semuanya berbasis konvensi. Itu tidak akan berfungsi untuk aplikasi yang sudah ada, karena konvensinya akan baru. Saya tidak berencana untuk mengganti konfigurasi Anda dengan milik kami :)

Saya berharap seseorang akan menciptakan protokol yang BENAR-BENAR sederhana, meninggalkan SEMUA implementasi warisan dan fokus pada masa depan.

Ini masalahnya -- aplikasi menjadi lebih rumit, tidak kurang. Untuk mengamankannya, keamanannya juga rumit. Saya selalu menolak ketika saya mendengar orang mengatakan bahwa IdentityServer itu rumit -- sebenarnya tidak. Persyaratan keamanan aplikasi Anda yang rumit. Seringkali orang tidak memiliki perspektif untuk mengenalinya.

Ya, itu berfungsi - dan itu bekerja dengan baik - tetapi tetap saja, jaminan tambahan yang (mungkin) berikan kepada Anda, ketika Microsoft secara resmi "mendukung" dan akhirnya "mendukung" suatu teknologi adalah emas murni.... !
Anda telah diangkat ke tingkat yang sama sekali baru!

@brockallen Ya, aplikasi mungkin banyak memperumit banyak hal. Namun, protokol OIDC tidak dapat disangkal mewarisi beberapa hal dari OAuth 2.0 yang sebaiknya dihilangkan. Beberapa anggota tim Anda (saya pikir itu @leastprivilege) mengatakan bahwa jika OIDC akan dikembangkan dari bawah ke atas, mungkin akan terlihat cukup berbeda dari apa yang kita miliki sekarang.

Saya tidak mengatakan apa yang kita miliki sekarang adalah "buruk", saya sangat menghargai apa yang kita miliki, dan itu benar-benar berfungsi untuk tujuan kita, dan saya harap semua orang yang terlibat dalam penciptaannya bangga dengan pekerjaan yang mereka lakukan!

@Tim;
Untuk pratinjau 3, dapatkah Anda memberikan beberapa dokumen detail tentang "Server Otorisasi" dan bagaimana fungsinya jika digunakan dengan API Web dan JS sisi klien, seperti Vue?
Kami perlu membuat keputusan dan pratinjau di Server Otorisasi ini adalah pratinjau penting dan dokumen detail apa pun akan memberi kami info tentang keputusan kami.

Terima kasih!

Seperti yang dibahas sebelumnya

https://identityserver.io

Perhatikan juga API data terbuka AS ada di JSON-LD: https://project-open-data.cio.gov/v1.1/schema/ . Ini tampaknya menjadi tren yang berkembang pesat, jadi perpustakaan JSON-LD .NET dengan sumber daya yang baik digunakan dengan ASP.NET akan menyenangkan. :)

@veikkoeeva Begitu juga (setidaknya sebagian dari) NuGet API. Mereka menggunakan json-ld.net , tidak perlu perpustakaan lain.

@khellang Dan ada perpustakaan lain juga, perpustakaan khusus ini dapat menggunakan pengelola (https://github.com/linked-data-dotnet/json-ld.net/issues/26). Saya menyadari itu open source dan secara teori saya bisa masuk untuk berkontribusi, tetapi untuk saat ini setidaknya saya terlalu kurus untuk membantu dengan ini. Sebaliknya, mungkin, saya ingin memberi perhatian pada ini bahwa banyak kumpulan data tampaknya bergerak ke arah format semantik dan tidak jelas bagaimana bekerja secara efisien dengan menggunakan .NET.

IMHO, tambahkan IdentityServer4 ke inti ASP.Net Core adalah ide yang buruk.
Tolong jangan jadikan .NetCore sebagai kerangka kerja monolitik.
.NetCore ada di sana dan IdentityServer4 ada di sana, orang membuat arsitektur berdasarkan kebutuhan otentikasi dan otorisasi sendiri.

@mikeandersun Rencananya hanya untuk memiliki konfigurasi default yang mudah yang dapat Anda tambahkan ke proyek Anda untuk membuatnya bekerja di luar kotak.

Anda masih tidak dapat menggunakannya, dan itu tidak akan mempengaruhi Anda. Anda masih dapat menggunakan IdSrv dan mengkonfigurasinya sendiri sepenuhnya. Anda masih dapat memilih komponen apa yang akan disertakan dalam proyek Anda. Semua ini tidak membuat ASP.NET Core menjadi monolitik.

ASP.NET Core != .NET Core btw.

Akankah 2.2 menjadi rilis LTS? (Menanyakan apakah itu sudah diumumkan, bukan meminta Anda membuat pengumuman baru.)

@yzorg tidak yang belum diumumkan. Penentuan itu sering dilakukan setelah rilis berdasarkan kualitas/stabilitas.

@blowdart , akankah templat ini menyediakan server identitas dengan klien MVC aplikasi Web alih-alih API?

@ Ponant Tidak. Ini ditujukan hanya untuk API. Kami akan mengevaluasinya kembali di timeline 3.x.

Menarik... Pertanyaan ini muncul dalam rapat kemarin. Jika kita membangun proyek "MVC" penuh tanpa menggunakan Web API, dapatkah kita menggunakan template ASP.Net 2.2 IS4 baru yang terintegrasi dalam 2.2?
Sepertinya bos besar (Barry) baru saja menjawab pertanyaan itu.

@blowdart allias bos besar: mengapa itu tidak dilakukan dalam satu kesempatan? Tampaknya sepele pada pandangan pertama untuk menggunakan klien mvc atau api web yang berbicara dengan server IS4 identitas inti asp.net.

@ Ponant Karena kami tidak memiliki sumber daya yang tak terbatas. Fitur apa yang Anda ingin kami hapus untuk membuat semua orang mengubah sebagian besar aliran MVC yang tidak akan memberikan fitur baru, cukup ubah cara kerja yang sudah ada? API terotentikasi individu telah menjadi celah antara kerangka kerja penuh dan ASP.NET Core. Fokus pekerjaan adalah mengisi celah itu. Identity Server sudah memiliki template yang berfungsi untuk MVC dengan Identity Server sebagai "inti".

@CrispinH @blowdart Saya setuju dengan Anda sepenuhnya, Administrasi Pengguna, Peran, Penyewaan, dan Grup Pengguna sangat dibutuhkan. Lihat ini - ada 7 tiket Uservoice yang semuanya mengeluh tentang ratusan pengembang dan perusahaan ini. Sayangnya banyak teknologi lain seperti portal Java blueRay JSR 182 atau 173 pekerjaan yang begitu indah di sini!

-> Begitu banyak permintaan untuk manajemen pengguna/grup/penyewa

image


--> LAGI di sini orang mengeluh ... itu terus, bahkan di twitter dan facebook.. inilah alasannya - mengapa platform lain seperti WP dan PHP lebih mudah!

image

Sementara @manigandham percaya server identitas sangat cocok, mereka mengenakan BANYAK untuk alat administrasi GUI dan tidak murah untuk banyak negara dan pengembang, itu juga bertentangan dengan pengembang TCO rendah. Berapa banyak orang yang benar-benar mampu membayar ini. Ini telah menjadi hambatan BESAR dan langkah mundur, fungsionalitas vanilla dasar dan GUI untuk mengelola Pengguna/peran/Peran-Pengguna_groups/Penyewa diperlukan , yang kemudian dapat ditingkatkan oleh pengembang

@papyr Mengapa Anda tidak memulai proyek sumber terbuka untuk ini? GUI lengkap untuk semuanya tidak perlu dibangun ke dalam kerangka kerja (templat). Dan melihat betapa sulitnya bagi tim untuk terus memperbarui template, misalnya dengan perubahan pada Bootstrap, saya tidak ingin mereka membuang lebih banyak upaya untuk itu. Tapi di sisi lain, saya benar-benar mengerti bahwa ini akan menjadi hal yang berguna untuk eksis, jadi mengapa Anda tidak menjadikan ini sebagai upaya komunitas?

@papyr @poke tidak perlu untuk proyek open source baru, ada proyek yang sudah ada yang sangat baik.

Jika Anda menginginkan sesuatu yang open source dari MS yang dirancang untuk bersaing dengan WordPress, lihat Orchard:
https://github.com/OrchardCMS/OrchardCore

Jika Anda menginginkan lebih banyak pendekatan perpustakaan daripada kerangka kerja, periksa cloudscribe, yang memiliki nuget untuk multi-tenancy dan pengguna dan peran dan manajemen klaim yang telah dibuat sebelumnya dengan integrasi identityserver4 opsional dan cms opsional (cloudscribe.Simple/content) sebagai nugget tambahan.
https://www.cloudscribe.com/docs/introduction
https://github.com/cloudscribe/cloudscribe
https://github.com/cloudscribe/cloudscribe.SimpleContent

Jika Anda menginginkan sesuatu yang open source dari MS yang dirancang untuk bersaing dengan WordPress, lihat Orchard:
https://github.com/OrchardCMS/OrchardCore

Saya mendukung rekomendasi ini.

Dan Orchard Core dirancang sangat modular. Misalnya, dimungkinkan untuk mengekstrak hanya modul multi-tenancy dan menggunakannya dalam proyek Anda sendiri . Itu juga sudah memiliki modul untuk mengelola pengguna & peran, dan saya yakin mereka akan menghargai kontribusi Anda untuk menjadikannya lebih baik.

Anda dapat menonton banyak demo berbagai fiturnya di saluran mereka .

@papyr Mengapa Anda tidak memulai proyek sumber terbuka untuk ini?

https://github.com/IdentityManager/IdentityManager2

Hal UI ini bisa rumit, meskipun membantu untuk mendapatkan hal-hal dasar dengan cepat. Sepertinya baru-baru ini saya menemukan kasus membangun UI bukanlah tugas terbesar, tetapi mencari cara untuk memenuhi "kebutuhan proses" seperti pra-persetujuan beberapa email (yang melakukan sesuatu yang spesifik untuk aplikasi), memanggil API yang memanggil API , beberapa di antaranya mungkin berarti bergabung dalam database atau menelepon ke tempat lain, dll., lalu menambahkannya ke token dan logika UI.

Jadi memiliki tutorial yang bagus seperti https://mcguirev10.com/2018/01/28/login-identity-management-best-practices.html atau yang ada di https://mcguirev10.com/page2/ terasa lebih penting daripada UI ( terutama jika seseorang tidak dapat atau tidak ingin menggunakan EF). Kemudian mungkin mencari UI untuk teknologi pilihan seseorang (Aurelia/Angular/Razor/React/Vue dll.) dan bagaimana mereka menerapkan beberapa penanganan data.

Tentang penamaan proyek dan nama, selain @scottbrady91 , saya merasa sangat mendidik untuk memeriksa @LindaLawton , https://github.com/abergs/fido2-net-lib ( @abergs , @aseigler), @TomCJones , @ mackie1001 (Gitter) dll. untuk memberikan penjelasan tambahan dan kode untuk diintip saat melangkah sedikit di luar kebutuhan dasar. Saya lupa menambahkan beberapa nama dan proyek. :)

Mengapa .net core tidak dapat memiliki halaman web pisau cukur yang normal? Ketika saya melakukan laporan kompleks, saya suka melakukan semuanya dari satu halaman pisau cukur (c#). Atau setidaknya kemampuan untuk menggunakan hanya tampilan di kali saja tanpa model atau pengontrol.

Dengan kata lain kemampuan dasar untuk terhubung ke sql dalam melihat dan menerima permintaan GET dan POST, tentu saja dibersihkan, saat ini saya menggunakan kelas yang disebut Striptag.cs.

Mengapa .net core tidak dapat memiliki halaman web pisau cukur yang normal?

Anda dapat menggunakan halaman Razor untuk ini https://docs.microsoft.com/en-us/aspnet/core/razor-pages/?view=aspnetcore-2.1&tabs=visual-studio

Memiliki kelas model halaman belakang adalah opsional; Anda hanya dapat memiliki satu halaman

benaadams terima kasih atas jawabannya, bagaimana saya menggunakan permintaan GET dan POST langsung di halaman pisau cukur, dan membuat koneksi dasar ke server sql. Sambungan untuk kueri biasa, bukan entitas ado, atau LINQ, atau ORM. Saya selalu lebih suka pertanyaan normal.

Suka:

var msql = "SELECT * FROM customerss WHERE lastname LIKE <strong i="7">@0</strong> ORDER BY lastname OFFSET " + thisoffset + " ROWS FETCH NEXT 5 ROWS ONLY";

Saya tahu string koneksi ada dalam file json sekarang, tetapi tidak tahu cara menggunakannya dalam tampilan. Beberapa hal tidak didokumentasikan secara mendalam.

Yah, itu memiliki kurva belajar. Jika Anda ingin mengambil data _sebelum_ memuat tampilan, Anda melakukannya dalam tindakan yang sesuai. Jadi, untuk halaman HomeController.ViewReports dan Views/Home/ViewReports.cshtml Anda menulis:

public class HomeController
{
  public ActionResult ViewReports()
  {
    // fetch data from the SQL using...something...
    return View(data);
  }
}

Jika Anda ingin mengambil data _setelah_ pemuatan halaman, Anda biasanya menggunakan permintaan AJAX ke beberapa titik akhir GET/POST murni yang mengembalikan data berformat JSON.

Masih dapat melakukannya di halaman tanpa pengontrol atau tindakan apa pun; sesuatu seperti

<strong i="6">@page</strong>
<strong i="7">@using</strong> System.Data.SqlClient
<strong i="8">@using</strong> Microsoft.AspNetCore.Http
<strong i="9">@using</strong> Microsoft.Extensions.Configuration
<strong i="10">@inject</strong> IConfiguration Configuration

@{
    var lastname = Request.Query["lastname"];
    if (!string.IsNullOrEmpty(lastname))
    {
        var offset = 0;
        var count = 5;
        if (Request.Method == HttpMethods.Post)
        {
            int.TryParse(Request.Form["offset"], out offset);
            int.TryParse(Request.Form["count"], out count);
            count = Math.Min(count, 50);
        }

        var connectionString = Configuration.GetConnectionString("MyConnectionString");
        using (var conn = new SqlConnection(connectionString))
        {
            using (var cmd = new SqlCommand(@"
            SELECT * FROM customers
            WHERE lastname LIKE <strong i="11">@lastname</strong>
            ORDER BY lastname
                OFFSET (@offset) ROWS
                FETCH NEXT (@count) ROWS ONLY"))
            {
                cmd.Parameters.AddWithValue("@lastname", lastname);
                cmd.Parameters.AddWithValue("@offset", offset);
                cmd.Parameters.AddWithValue("@count", count);

                await conn.OpenAsync();
                using (var reader = await cmd.ExecuteReaderAsync())
                {
                    while (await reader.ReadAsync())
                    {
                        <div>@reader["lastname"]</div>
                    }
                }
            }
        }
    }
    else
    {
        <div>Nothing chosen</div>
    }
}

Saya telah menggunakan mvc asp.net dan formulir web dan halaman pisau cukur lama, jadi saya bukan orang baru dalam hal ini. Saya telah menghabiskan 3 jam dan masih tidak bisa membuat halaman pisau cukur tes sederhana berfungsi, saya punya:

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <title></title>
</head>
<body>
    <form id="petform" method="post" action="pets/razdb3">
        <input type="text" name="psearch" id="psearch" />
        <input type="submit" />
    </form>

</body>
</html>

Hanya halaman html dan memuat.

Model

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.RazorPages;

namespace petnewtry.Pages.pets
{
    public class razdb3Model : PageModel
    {
        public string myvar { get; set; }

        public void OnGet()
        {

        }

        public void OnPost()
        {
            myvar = Request.Form["psearch"];
        }
    }
}

Melihat:

<strong i="13">@page</strong>
<strong i="14">@model</strong> petnewtry.Pages.pets.razdb3Model
@{
    Layout = null;
}

<!DOCTYPE html>

<html>
<head>
    <meta name="viewport" content="width=device-width" />
    <title>razdb3</title>
</head>
<body>
    <div>@Model.myvar</div>
    <div>hello</div>
</body>
</html>

3 jam dan yang saya dapatkan hanyalah halaman kosong. Saya mencoba pernyataan pengembalian, dll

Jika saya mengetikkan http://localhost :51307/pets/razdb3 saya mendapatkan divisi kedua "halo", tapi
@Model.myvar saya tidak mendapatkan apa-apa.

Saya baru mengenal .net core, dan tidak akan pernah membayangkan akan atau bisa sangat sulit untuk menampilkan halaman pisau cukur.

Di komunitas VS 2017

@Model.myvar saya tidak mendapatkan apa-apa.

Anda menetapkan nilai myvar pada permintaan posting ( OnPost ) dengan dari nilai formulir psearch ; jadi Anda harus membuat permintaan POST dengan nilai itu untuk mengaturnya?

Dalam permintaan GET ( OnGet ) yang Anda dapatkan dari hanya menavigasi ke url dari browser; alih-alih postback formulir tidak disetel ke apa pun.

Coba atur ke nilai default sehingga muncul saat Anda tidak menyetelnya untuk mengonfirmasi model mengalir melalui:

public string myvar { get; set; } = "Not Set";

Berubah menjadi

public string myvar { get; set; } = "Not Set";

Dan masih halaman kosong. Apakah @Model.myvar benar?

bahkan berubah menjadi

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.RazorPages;

namespace petnewtry.Pages.pets
{
    public class razdb3Model : PageModel
    {
        [BindProperty]
        public string psearch { get; set; }

        public void OnGet()
        {

        }

        public void OnPost(string psearch)
        {
            psearch = Request.Form["psearch"];
        }
    }
}
<strong i="12">@page</strong>
<strong i="13">@model</strong> petnewtry.Pages.pets.razdb3Model
@{
    Layout = null;
}

<!DOCTYPE html>

<html>
<head>
    <meta name="viewport" content="width=device-width" />
    <title>razdb3</title>
</head>
<body>
    <div>@Model.psearch</div >
        <div>hello</div>
</body>
</html>

Itu dibangun dengan baik tanpa kesalahan, tetapi halaman kosong tidak peduli apa yang saya coba.

Komentar/pemikiran yang sopan: rasanya diskusi tentang "halaman pisau cukur yang normal" ini mulai sedikit menyimpang dari topik sehubungan dengan topik utas ini.

😊😊

Maaf, saya sadar saya seharusnya menggunakan forum. Terima kasih @benaadams kode Anda membuat saya berada di jalur yang benar dan saya menemukan ini:

https://www.c-sharpcorner.com/article/razor-page-web-application-with-asp-net-core-using-ado-net/

Ini adalah bagaimana saya biasanya melakukan hal-hal, menggunakan kata kunci "baru", seperti

EmployeeDataAccessLayer objemployee = new EmployeeDataAccessLayer();

Sangat meyakinkan melihat Anda masih bisa menggunakan kelas khusus di .net core.

Anda harus mengakui, .net core memiliki kurva belajar yang lebih curam daripada beberapa kerangka kerja asp.net sebelumnya. Terima kasih banyak.

Catatan rilis berbicara tentang fitur "Server Otorisasi" yang diharapkan sebagai tambahan dalam beberapa bulan mendatang. Apakah ada informasi lebih lanjut yang tersedia tentang fitur ini? Saya mencoba memutuskan apakah kita harus menunggu. Atau membangun solusi kita sendiri.

Catatan rilis berbicara tentang fitur "Server Otorisasi" yang diharapkan sebagai tambahan dalam beberapa bulan mendatang. Apakah ada informasi lebih lanjut yang tersedia tentang fitur ini? Saya mencoba memutuskan apakah kita harus menunggu. Atau membangun solusi kita sendiri.

Saya pikir rencana saat ini adalah menggunakan https://github.com/IdentityServer/IdentityServer4 dengan cara "pra-paket".

Mengikuti catatan dari tim IS4 dan tim keamanan MS, sepertinya MS hanya mencoba melakukan pengemasan cepat & kotor dari IS4 dan menyebutnya hari ini. Tetapi sepertinya seseorang yang lebih bijaksana, memutuskan untuk menahan diri dan melakukannya dengan cara yang benar, karena keamanan dapat menciptakan efek riak jika tidak dilakukan dengan benar.

Saya berharap integrasi penuh antara IS4 dan ASP dibuat untuk mendukung KEDUA API Web dan MVC.

Saat ini dan otentikasi/otorisasi kekuatan industri diperlukan sebagai minimum. Open Source (OSS) baik-baik saja untuk banyak hal, tetapi ada keraguan serius dalam beberapa produk keamanan OSS yang tidak dapat diterima di situs web perusahaan mana pun. 85% proyek menggunakan pustaka usang yang berisiko keamanan tidak dapat diterima. Misalnya, 45% server web menggunakan Apache (https://www.cvedetails.com/vendor/45/Apache.html) yang memiliki kerentanan jauh lebih banyak daripada IIS (https://www.cvedetails.com/product/3436/ Microsoft-IIS.html?vendor_id=26). Produk seperti Identity Server mungkin baik-baik saja tetapi tweak pengembang dapat membuat mereka benar-benar tidak aman. Kami membutuhkan solusi bawaan Net Core yang selalu aman...

Saat ini dan otentikasi/otorisasi kekuatan industri diperlukan sebagai minimum. Open Source (OSS) baik-baik saja untuk banyak hal, tetapi ada keraguan serius dalam beberapa produk keamanan OSS yang tidak dapat diterima di situs web perusahaan mana pun. 85% proyek menggunakan pustaka usang yang berisiko keamanan tidak dapat diterima. Misalnya, 45% server web menggunakan Apache (https://www.cvedetails.com/vendor/45/Apache.html) yang memiliki kerentanan jauh lebih banyak daripada IIS (https://www.cvedetails.com/product/3436/ Microsoft-IIS.html?vendor_id=26). Produk seperti Identity Server mungkin baik-baik saja tetapi tweak pengembang dapat membuat mereka benar-benar tidak aman. Kami membutuhkan solusi bawaan Net Core yang selalu aman...

Poin Anda benar sekali. Namun dalam beberapa video, staf MS mengatakan, bahwa mereka tidak akan menemukan kembali roda [keamanan] dan menggunakan sistem [IS4] pihak ketiga. Jadi saya berharap ini akan menjadi situasi menang/menang bagi kita semua.

Saat ini dan otentikasi/otorisasi kekuatan industri diperlukan sebagai minimum. Open Source (OSS) baik-baik saja untuk banyak hal, tetapi ada keraguan serius dalam beberapa produk keamanan OSS yang tidak dapat diterima di situs web perusahaan mana pun. 85% proyek menggunakan pustaka usang yang berisiko keamanan tidak dapat diterima. Misalnya, 45% server web menggunakan Apache (https://www.cvedetails.com/vendor/45/Apache.html) yang memiliki kerentanan jauh lebih banyak daripada IIS (https://www.cvedetails.com/product/3436/ Microsoft-IIS.html?vendor_id=26). Produk seperti Identity Server mungkin baik-baik saja tetapi tweak pengembang dapat membuat mereka benar-benar tidak aman. Kami membutuhkan solusi bawaan Net Core yang selalu aman...

Tidak ada yang "selalu aman", terutama bukan sesuatu dari Microsoft ;)
Itu selalu di tangan pengguna hal-hal ini untuk membuatnya dan tetap aman.

IdentityServer akan disertakan dalam pos pengiriman template baru 2.2. Fokus awal adalah kontrol akses API - tetapi ada rencana untuk memperluasnya di masa mendatang.

ASP.NET Core akan dikirimkan dengan API konfigurasi yang disederhanakan yang hanya mencakup skenario template - tetapi akan sangat mudah untuk memulai. Anda dapat kapan saja bertransisi ke sistem konfigurasi asli IS yang memberi Anda skenario lanjutan.

IdentityServer akan disertakan dalam pos pengiriman template baru 2.2. Fokus awal adalah kontrol akses API - tetapi ada rencana untuk memperluasnya di masa mendatang.

ASP.NET Core akan dikirimkan dengan API konfigurasi yang disederhanakan yang hanya mencakup skenario template - tetapi akan sangat mudah untuk memulai. Anda dapat kapan saja bertransisi ke sistem konfigurasi asli IS yang memberi Anda skenario lanjutan.

Terima kasih atas informasinya, Dominick;
Saya rasa "Batu loncatan" ini akan membantu banyak orang untuk memulai dan kemudian beralih ke IS penuh. Langkah yang bagus.

IdentityServer akan disertakan dalam pos pengiriman template baru 2.2. Fokus awal adalah kontrol akses API - tetapi ada rencana untuk memperluasnya di masa mendatang.

ASP.NET Core akan dikirimkan dengan API konfigurasi yang disederhanakan yang hanya mencakup skenario template - tetapi akan sangat mudah untuk memulai. Anda dapat kapan saja bertransisi ke sistem konfigurasi asli IS yang memberi Anda skenario lanjutan.

Senang mendengarnya! Terima kasih.

Saya kira kontrol akses API ini akan didasarkan pada cakupan OAuth?
Tidak ada dukungan langsung untuk izin pengguna yang lebih mudah berubah seperti yang dijelaskan di policyserver.io?

IdentityServer akan disertakan dalam pos pengiriman template baru 2.2. Fokus awal adalah kontrol akses API - tetapi ada rencana untuk memperluasnya di masa mendatang.
ASP.NET Core akan dikirimkan dengan API konfigurasi yang disederhanakan yang hanya mencakup skenario template - tetapi akan sangat mudah untuk memulai. Anda dapat kapan saja bertransisi ke sistem konfigurasi asli IS yang memberi Anda skenario lanjutan.

Senang mendengarnya! Terima kasih.

Saya kira kontrol akses API ini akan didasarkan pada cakupan OAuth?
Tidak ada dukungan langsung untuk izin pengguna yang lebih mudah berubah seperti yang dijelaskan di policyserver.io?

PolicyServer adalah solusi komersial

Saya kira kontrol akses API ini akan didasarkan pada cakupan OAuth?
Tidak ada dukungan langsung untuk izin pengguna yang lebih mudah berubah seperti yang dijelaskan di policyserver.io?

"Hanya" IdentityServer. ASP.NET Core memiliki API bawaan untuk otorisasi pengguna - dan jika PolicyServer (produk) terlihat menarik bagi Anda, beri tahu saya.

Menutup masalah ini karena ASP.NET Core 2.2 telah dikirimkan.

seharusnya ini tidak diperbarui ke ASP 3.0

Adakah pembaruan tentang kapan perangkat tambahan Server Otorisasi akan dikirimkan?

Apakah halaman ini membantu?
0 / 5 - 0 peringkat