ماذا عن خارطة طريق إي أف كور 2.2؟

ماذا عن خارطة طريق إي أف كور 2.2؟

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

تبدو خارطة الطريق جيدة ، ولا سيما الفحوصات الصحية و HTTP 2.0. ومع ذلك ، وبأفضل طريقة ممكنة ، لا أتفق مع الحاجة إلى إنشاء خادم ترخيص بسيط من Microsoft للطرف الأول. يملأ IdentityServer4 هذه الفجوة بشكل جيد ويمكن قضاء الوقت المستغرق في إعادة تنفيذ نسخة أبسط منه بشكل أفضل في مكان آخر. أفهم أن الهدف هو توفير حل بسيط ولكن المصادقة صعبة وتوفر IdentityServer واجهة برمجة تطبيقات بسيطة بقدر ما تحصل عليها. إذا كانت هناك أفكار لتجريد أبسط ، فيمكن بناؤها فوق IdentityServer حتى يتمكن الأشخاص من استخدام التجريد البسيط ولكن لديهم القوة إذا احتاجوا إليها.

تحديث

في قائمة مجتمع ASP.NET ، تم ذكر أن فريق ASP.NET Core يتحدث إلى فريق Identity Server حول الخيارات ، بما في ذلك بناء شيء ما فوق Identity Server. أعتقد أن هذا ما نريده جميعًا ، أحسنت!

ما الخطط الحالية حول ASP.NET Core WebHooks ؟

فيما يتعلق بالمرسل ، هل سيكون هذا ممكنًا في البرامج الوسيطة إذن؟ 😱
C# public async Task Invoke(HttpContext context, [FromRoute] SomeModel someModel)
^{[FromQuery]؟}

خادم مصادقة بسيط ولكن تذكر أيضًا ما حدث مع خادم Auth البسيط لـ Katana

أريد أن أردد مخاوف @ RehanSaeed وأود أن أطلب بعض التوضيحات حول حالات الاستخدام الدقيقة التي من المفترض أن يملأها هذا الخادم الجديد. إذا كان هذا في الأساس ، لذا فإن واجهات برمجة تطبيقات الويب لديها طريقة للحصول على رمز حاملها صالح ضمن المصادقة الحالية للتطبيق ، فسيكون ذلك جيدًا. ولكن من الأفضل ترك كل شيء علاوة على ذلك للحلول الحالية التي تقدم بالفعل العديد من الخيارات المختلفة التعقيد والمرونة مع منتجات مثل IdentityServer و OpenIdict و AspNet.Security.OpenIdConnect.Server.

ماذا عن استضافة IIS قيد المعالجة ؟

هل يمكنك توضيح المزيد حول جزء TypeScript من "إنشاء عميل API (C # & TypeScript)"؟

سيكون هذا حقًا شيئًا أتطلع إليه. أستخدم حاليًا NSwag لإنشاء خدمات Angular Client API تلقائيًا. ولكن هناك العديد من التركيبات المختلفة الممكنة لتكوينات العميل والتي أعتقد أن هذا قد يكون مشكلة لإرضاء الجميع.

بعيدًا عن الجزء العلوي من رأسي ، هناك بعض الأشياء التي يجب مراعاتها (ويجب أن تكون قابلة للتكوين إن أمكن):

• مجرد عميل TypeScript مع جلب أو خدمة Angular مع HttpClient؟
• إذا كان Angular ، فما الإصدارات التي تدعمها (مهمة أيضًا لـ RxJS)؟
• لاغية / معالجة غير محددة
• التعامل مع التعداد
• JS date or momentjs لأنواع التاريخ؟
• معالجة الاستثناءات ، ومعالجة أخطاء التحقق من الصحة
• كيف يتم تمديد الكود الذي تم إنشاؤه في العميل؟
• إمكانية التأثير على إنشاء الاسم (على سبيل المثال ، إسقاط جزء DTO من xxxDTO لفئات العميل التي تم إنشاؤها أو بالفعل في تعريف OpenAPI)

إذا كان من الممكن التصويت على الميزات ، فستكون هذه التحسينات / الإصلاحات للبرامج الوسيطة الحالية في قائمة أمنياتي:

• يتيح دعم التشفير https://github.com/aspnet/Home/issues/1190.
• البرمجيات الوسيطة Response Cache ليست قابلة للاستخدام بشكل أساسي كما هي اليوم. يجب أن تؤدي إضافة مخزن ذاكرة التخزين المؤقت لاستجابة Redis وقابلية التوسع لعمليات المستخدم للاستجابات المخزنة مؤقتًا إلى حل https://github.com/aspnet/Home/issues/2606.
• دعم تقديم الملفات المشفرة مسبقًا بـ GZIP و BR .
• أضف موفر ضغط Brotli بالإضافة إلى إصلاح العديد من المشكلات مع البرامج الوسيطة لضغط الاستجابة.

أنا أيضًا أصوت لتخطي منتج Authorization Server. الأمان معقد وكان هناك دفعة كبيرة للانتقال إلى الخدمات السحابية لإزالة الصيانة ، وأي شخص يريد المزيد من التحكم يمكنه بالفعل استخدام IdentityServer4 الذي تم تصميمه جيدًا واختباره وتوثيقه ودعمه. يستغرق الإعداد البسيط 5 دقائق ولديهم الكثير من نماذج البداية ومقاطع الفيديو والبرامج التعليمية.

أخفق في معرفة كيف يمكنك جعل الأمان يعمل كـ "تكوين صفري" أكثر مما يستطيعون. يبدو أن هذا سيضيف المزيد من الالتباس (في التسمية والاستخدام) ، بينما يصبح شيئًا آخر يجب دعمه وصيانته لسنوات ، مما يقلل الجهد من الميزات الأخرى باستمرار. يرجى إعادة التفكير في هذا.

أشعر بالفضول أيضًا بسبب عدم وجود استضافة IIS قيد المعالجة على خريطة الطريق 2.2 هذه. هذه هي ميزة كبرى ويعتبر عاملا رئيسيا في استراتيجية إطلاق سراحنا والجداول الزمنية هنا في تجاوز المكدس و أنه تمت إزالة بالفعل اللحظة الأخيرة قبل إصدار 2.1، واعدا زمني 2.2 بدلا من ذلك . من فضلك قل لي أن هذا مجرد سهو وليس تغيير آخر في الخطة.

تحرير: رد DamianEdwards على Twitter أن هذا كان بالفعل سهوًا (بمعنى أنه مخطط له 2.2). تفو!

سأردد تعليقات أخرى. إذا كنت ستستثمر في التخويل / السياسة ، على وجه التحديد لتبسيط الأمر ، فأنا شخصياً أفضل أن أرى شراكة مع أمثال OpenIdict و IdentityServer في المستندات والاستثمارات في السقالات. لا يسعني إلا أن أشعر أن أي عمل ، مهما كان بسيطًا ، سينتهي به الأمر إلى تكرار جهود الجهات الخارجية الرائعة وتكبد تكاليف صيانة غير ضرورية على فريق aspnet.

ربما تكون وجهة نظر لا تحظى بشعبية ، لكني أرغب في رؤية Microsoft Auth Server ، الذي تم إنشاؤه في نظر الجمهور ، بمدخلاتنا ودعمنا.

من الواضح أن المشروعات الحالية - Id4 و OpenIdict - هي مشروعات OSS ممتازة ، ولا يسعني الشعور بأن أحدًا يدعم MS وراءه يمكن أن يكون شيئًا سيئًا ...؟

هناك حد لمقدار الدعم المتاح من مجموعة صغيرة من الأشخاص ، وهذه منتجات مهمة للغاية بعد كل شيء.

أعتقد أنه من المؤسف أن مدونة قواعد سلوك MS OSS لا تتضمن سطرًا يقول "لا تروج للميزات التي تكرر شيئًا يمكن تقديمه مع طلب Nuget والتي ستسحق عرضًا نشاطًا تجاريًا يتكون من شخصين يساهم في نظامنا البيئي ".

لا يستطيع الساخر بداخلي أن يتساءل عما إذا كان إعطاء بروك ودومينيك أنفًا دمويًا ، بالنسبة لبعض المطلعين ، هو سمة من سمات هذا الاقتراح وليس خطأ. هل هذا ما يحدث للشركات الصغيرة التي لديها الجرأة في انتقاد أي شيء يفعله فريق ASP؟

أتساءل أيضًا عن تكرار وظيفة المصادقة بخلاف إنشاء شيء في الأعلى ، مثل واجهات المستخدم والوثائق.

بالإضافة إلى ذلك ، ستكون مكتبة JSON-LD 1.1 التي تم اختبارها جيدًا إضافة جيدة ومحددة إلى خريطة الطريق. :)

بتكرار ما قاله الآخرون - أفضل أن أرى عمل التفويض يتم إحضاره من شيء مثل IdentityServer4 بدلاً من تنفيذه من جديد بأنفسكم. إذا كانت هناك فجوات ، فمن المؤكد أن سد تلك الثغرات من خلال المساهمات والعينات وتحسين نقاط التكامل سيكون طريقة أفضل للذهاب. ربما عليك أيضًا الانتباه إلى عرضك السحابي في هذا الفضاء (B2C) الذي هو في حالة مروعة.

أبعد من ذلك ، بينما تقول إن الهدف ليس تكرار الوظائف في العروض الحالية مفتوحة المصدر ولإبقاء الأمور بسيطة ، فإن هذا يعادل إلى حد ما مصيدة إعادة الكتابة الكلاسيكية: "هذا الحل معقد للغاية وفوضوي بعض الشيء ، دعنا نعيد كتابته! ". إنه أمر ساذج وفي إصدارات n ، سأضع المال عليك بعد أن تعاملت مع العديد من الحالات المتطورة التي تتطلبها حلول العالم الحقيقي والتي يتعامل معها شيء مثل IdentityServer بالفعل.

على نطاق أوسع ، مع الاستحواذ على GitHub ، كان هناك الكثير من النقاش مؤخرًا حول موقف Microsoft تجاه المصدر المفتوح. إنه لأمر رائع أن تقوم Microsoft بالكثير من العمل في العلن ولكن جزءًا من كونها مواطنًا جيدًا مفتوح المصدر هو الاستفادة من المصادر المفتوحة الموجودة عند وجودها.

هذا مهم بشكل خاص لأصحاب النظام الأساسي مثل أنفسكم - صاحب منصة ينسخ الوظائف في العروض الحالية مفتوحة المصدر _ لا يشجع_ المساهمات أثناء الانخراط في هذه العروض _ يشجع_ المساهمات.

أنا أيضًا لا أستطيع رؤية نقطة الجهد المبذول على التخويل ، لكني أرغب في رؤية _management_ لـ ASP.NET Core Identity محسّنة. كان داميان إدواردز واضحًا تمامًا في موقع live.asp.net أنه لا ينبغي لنا أن نقوم بتدوير الأمان الخاص بنا ، ولكن - ما لم أفقده - لا يحتوي ASP.NET Core Identity على أي أدوات لإدارة المستخدم ولذا يتعين علينا تشغيل منطقتنا. أجد هذا مرعبًا بعض الشيء لأنني لست خبيرًا أمنيًا وأخشى بشدة من ترك ثغرة أمنية من صنع نفسي.

ماذا عن نقل منسقي المحتوى من مستوى MVC إلى AspNetCore.Http التجريدات في 2.2؟

ربما يستطيع مدير المشروع المسؤول كتابة وصف أكثر تفصيلاً لخادم Identity Server Lite هذا لتوضيح أوجه القصور في حلول المصدر المفتوح الحالية لجهة خارجية والتي يبحث فريق ASP.NET عن معالجتها. لأنه كما هو الحال ، فأنت تتحدث عن إعادة اختراع عجلة ولكن ربما تزيل بعض الأسلاك ، وهذا لا معنى له. كما قال شخص آخر ، فإن إصلاح AAD B2C وتوفير تكامل من الدرجة الأولى مع ذلك سيكون أمرًا رائعًا ، وسيكون مفيدًا للأعمال بالنسبة لـ MS.

أيضًا ، هل فكرت في مدى صعوبة الحصول على منتج خادم Auth جديد من الأرض بعدblowdart؟

هل هناك أي خطط للحصول على دعم RESTful API مدمج مثل الذي يمتلكه django؟
لأنه شيء يميل جميع المطورين إلى كتابته في كل مرة!

لقد أنشأت مؤخرًا شيئًا يمكن كتابته كوحدة تحكم عامة RESTful API:

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

أتفق أيضًا مع "أخفق في معرفة كيف يمكنك جعل الأمان يعمل كـ" تكوين صفري "أكثر مما يستطيعون" و "أنت تتحدث عن إعادة اختراع عجلة ولكن ربما إزالة بعض المتحدثين" ، خادم الهوية هو منتج رائع ، جدًا بسيطة لتبدأ بها وتوفر إمكانية التوسع لسيناريوهات أكثر تعقيدًا ، ولست متأكدًا من سبب حاجتنا إلى إصدار "مبسط".

على نطاق أصغر بكثير ، لماذا نحتاج إلى تطبيق آخر لفحص صحي. يوجد بالفعل العديد من الحلول مفتوحة المصدر على سبيل المثال

• https://github.com/Xabaril/BeatPulse ، يتضمن مجموعة من الشيكات المكتوبة مسبقًا وحتى يأتي مع واجهة مستخدم
• https://www.app-metrics.io/web-monitoring/aspnet-core/health/

ما هو الفرق بين هذه الميزات وما الذي يتم توفيره في 2.2؟

@ 0xRumple يجب أن تساعد التحسينات التي تم إدخالها على ApiController في تقليل الإسهاب بشكل عام. لكن لا ، ربما لن ترى شيئًا يمنحك فقط واجهة برمجة تطبيقات CRUD لكياناتك افتراضيًا. مثل هذا الشيء يجب أن يقدم الكثير من الافتراضات حول DAL والتفويض الخاص بك.

إذا اتبعت أنماطًا معينة في تطبيقك ، فلا حرج في إنشاء أنواع أساسية أو اصطلاحات في 2.2 ستعمم العمل من أجلك.

تضمين التغريدة

من الواضح أن المشروعات الحالية - Id4 و OpenIdict - هي مشروعات OSS ممتازة ، ولا يسعني الشعور بأن أحدًا يدعم MS وراءه يمكن أن يكون شيئًا سيئًا ...؟ هناك حد لمقدار الدعم المتاح من مجموعة صغيرة من الأشخاص ، وهذه منتجات مهمة للغاية بعد كل شيء.

بما أنك سألت عما إذا كان يمكن أن يكون شيئًا سيئًا:

فريق ASP.NET صغير نسبيًا أيضًا ، حيث يخدم ملايين المطورين بقدرات محدودة ، لذا فإن أي مشروع جديد سيأخذ الوقت والجهد من الأشياء الأخرى. هذا يعني أنه يتعين علينا جميعًا الانتظار لفترة أطول للحصول على أي ميزات جديدة تمامًا من شأنها أن تقدم قيمة أكبر على الأرجح.

والأسوأ من ذلك أنه يضر بالنظام البيئي للجهات الخارجية ولا يشجع على المنتجات الجديدة بسبب إصدار Microsoft حزمة "رسمية" ، والتي تتعثر العديد من الشركات في اختيارها لمجرد أنها من Microsoft حتى لو كانت من الناحية الفنية (وفي هذه الحالة من المفترض أن تكون) أقل قادر. يقوم ASP.NET بالفعل بدمج Json.NET و Polly و AutoMapper والعديد من المكتبات الأخرى ، لذا يبدو أنه من الخطأ إعادة بناء مثل هذا المنتج الأمني ​​المعقد (الذي سيحتاج إلى 80٪ من نفس الكود الأساسي) عندما تكون الخيارات الرائعة موجودة بالفعل ، ومع الكثير من الأشياء المثيرة للاهتمام في خارطة الطريق للعمل عليها.

@نكز
أنت على حق ، كتابة الفئات الأساسية لتطبيقاتي فكرة جيدة.

في الواقع أعتقد أن هؤلاء ليسوا ضمن مسؤوليات إطار العمل:

CRUD resources (repository responsibility)

Manipulating data (sieve responsibility)
    Paging
    Filtering
    Searching
    Sorting
    Shaping

ولكن هناك العديد من الأشياء التي اعتقدت أن AspNetCore كان يمكن أن يؤديها بشكل أفضل (من خلال امتلاك حزمة AspNetCore.RestFramework):

1. HATEOAS (واجهة برمجة تطبيقات ذاتية الاكتشاف)
2. أنواع الوسائط (إعداد أنواع وسائط مخصصة)
3. تعيين الإصدار (تحديث إصدار نوع الوسائط)
4. البيانات الوصفية الرئيسية للبيانات (ترقيم الصفحات في رأس X-Pagination ، بيانات تعريف المرشح ... إلخ).
5. تحديد المعدل والاختناق.

أعلم أن هناك الكثير من المكتبات ، ووجدت بعضها هنا: https: //github.com/thangchung/awesome-dotnet-core ... لكن مكتبات الطرف الثالث ليست حقًا خيارًا جيدًا لتطبيقات المؤسسة!

ينطبق الأمر نفسه على المنخل ، إذا كانت هناك حزمة رسمية لترقيم الصفحات ، والتصفية ... إلخ ، فلن يميل المطورون إلى كتابة مكتبات عربات التي تجرها الدواب أو التي لا تتم صيانتها ، لقد استخدمت هذا الغربال في تطبيقي الذي ذكرته أعلاه: https: // github.com/Biarity/Sieve ، ولكن يمكن أن تظل هذه المكتبة بدون صيانة في أي ثانية ينشغل فيها المؤلف.

أعتقد أن AspNetCore ناضجة بما يكفي لبدء التفكير في الحلول الجاهزة كما هو الحال في django ، وبهذه الطريقة يمكننا الحصول على رفاهية أداء ASP وخفة الحركة في django .

لكن مكتبات الطرف الثالث ليست حقًا خيارًا جيدًا لتطبيقات المؤسسة!

^ لهذا السبب لا يمكننا الحصول على أشياء لطيفة 😞

لكن مكتبات الطرف الثالث ليست حقًا خيارًا جيدًا لتطبيقات المؤسسة!

نعم ، هذا هو بالضبط التفكير الذي يجب تغييره هنا. يعد كل من ASP.NET Core و .NET Core مفتوحين المصدر ونظامهما البيئي _ هو _ يحتضن مجتمع المصادر المفتوحة ويجب أن يستمر في القيام بذلك. ليس فقط مع الحلول مفتوحة المصدر التي تعد جزءًا من .NET Foundation ، ولكن مع أي حلول حقًا.

لكن هذه المكتبة يمكن أن تذهب دون صيانة في أي ثانية ينشغل فيها المؤلف

وبنفس الطريقة ، يمكن أن تصبح الحزمة "الرسمية" غير مصونة في أي لحظة تغير فيها الشركة اهتمامها. لقد حدث هذا مع Microsoft أشياء محددة من قبل ، بما في ذلك حزم مفتوحة المصدر المتعددة التي نشروها ، ولكنه أمر طبيعي حقًا لأي شركة.

إذا قررت أن تأخذ الاعتماد على مكتبة منها آخر، ومن مسؤوليتكم أن تتمكن من العيش مع ذلك. بغض النظر عمن هو مؤلف ذلك. الشيء الجميل في المصدر المفتوح هو أنه حتى لو انتهى الأمر بالمؤلف لا يستجيب ، يحق لك تغييره بنفسك.

أنا أعارض بشدة توقع حلول Microsoft الرسمية لكل شيء قد تتمكن من طرحه. ليس فقط لأنه لا يوجد حل واحد يناسب الجميع ، مما يجعل هذا الأمر صعبًا للغاية وفي نفس الوقت من المحتمل أن يخرج عن السيطرة ، ولكن أيضًا بشكل خاص لأن هذا يأخذ الموارد من أجزاء من إطار العمل التي تحتاج حقًا إلى الاهتمام. وفي الوقت نفسه ، فإن فكرة المصدر المفتوح سيئة حقًا .

إذا كنت تبني تطبيقات مؤسسية وما زلت تعاني من متلازمة المعاهد الوطنية للصحة هذه (أو "لم يتم اختراعها في <شركة كبيرة>") ، يجب أن تستيقظ حقًا لأنه 2018 ومن المحتمل أن تتبنى المصدر المفتوح الآن.

أنت محق في أن Microsoft يمكنها التوقف عن صيانة أي حزمة ولكن على الأقل لديها LTS معين: https://www.microsoft.com/net/support/policy

على سبيل المثال ، ينتهي دعم .NET Core 1.1 في 27 يونيو 2019 ... وبهذه الطريقة يمكنني التأكد من أنني إذا كنت أستخدم هذا الإصدار لن أصاب بالشلل في المنتصف.

لقد استخدمت مرةً مساعد علامة ترقيم الصفحات لجهة خارجية ، ولم يكن الأمر ممتعًا ، أخبرني المؤلف أنه لن يصلحها لـ .NET Core 1.1 ، ويجب أن أقوم بتحديث المشروع ، لقد كان نظامًا جامعيًا ، 2.0 ( وله كل الحق في القيام بذلك لأنه كتب تلك الحزمة مجانًا).

هذه هي المشكلة ، في المؤسسة ، هذا لا يعمل ... لا يمكنك إقناع الفريق بأكمله بأنه يجب عليك الانتقال إلى الإصدار 2.0 أثناء تشغيل التطبيق لمجرد أن مساعد ترقيم الصفحات لا يعمل ر العمل!
لذا فأنت تستخدم فقط البدء في اختراق المصدر كما فعلت باستخدام مصمم الديكور: https://github.com/cloudscribe/cloudscribe.Web.Pagination/issues/37

ونعم ، من قال أنني لست من أشد المعجبين بالمصدر المفتوح: مرتبك:؟

@ 0xRumple ليست فكرة المصدر المفتوح للمساهمة والتعاون؟

إذا لم يكن مساعد علامة ترقيم الصفحات للجهة الخارجية موجودًا ، فسيتعين عليك كتابته بنفسك والمحافظة عليه على أي حال ، "في المؤسسة".

هذه هي المشكلة ، في المؤسسة ، هذا لا يعمل ... لا يمكنك إقناع الفريق بأكمله بأنه يجب عليك الانتقال إلى الإصدار 2.0 أثناء تشغيل التطبيق لمجرد أن مساعد ترقيم الصفحات لا يعمل ر العمل!

بدلاً من محاولة "إقناع الفريق بأكمله بأنه يجب عليك الانتقال إلى الإصدار 2.0" ، قم بالمساهمة في التحديث مرة أخرى وساعد بدلاً من الاعتماد على شخص آخر للقيام بالعمل أو انتظر حتى تقدم Microsoft ما يعادله. إذا كان المالك لا يريد قبول مساهمتك ، فابدأ بشوكة لتلبية احتياجاتك.

أعتقد أن نوع تفكيرك (لا يقصد أي جريمة على الإطلاق) هو جزء كبير من سبب وجود نقاش حول "خادم ترخيص Microsoft" مقابل معرف الهوية. كيف سيعمل المصدر المفتوح إذا لم يرغب المطورون في المشاركة. هل يجب أن ننتظر Microsoft لتقديم كل التعليمات البرمجية التي نحتاجها؟

أتفق مع الكثيرين هنا على أن Microsoft يجب أن تكون حذرة من أنها لا تقتل مشاريع مفتوحة المصدر جيدة في النظام البيئي من خلال صنع بدائلها الخاصة لكل شيء.

أنا في الواقع مؤلف مكتبة ترقيم الصفحات taghelper التي ذكرها @ 0xRumple ، كانت مشكلته مع مكون قائمة paged ليس مع taghelper الذي يحتوي في الواقع على nuget أقدم يدعم 1.x aspnet core. كانت القائمة المقسمة إلى صفحات حقًا شيئًا كان جزءًا من مكتبة بيجر سابقة مفتوحة المصدر أبلغت عن تصميم مكتبتي وتم استخدامها في الصفحات التجريبية في وقت واحد ولكن مساعد علامة الصفحة لا يعتمد على تنفيذ القائمة المقسمة إلى صفحات وهناك أخرى مُقسمة إلى صفحات قائمة التطبيقات التي كان من الممكن أن يستخدمها أثناء استخدام أداة تاجير النداء. في الواقع ، قمت منذ ذلك الحين بإزالة القائمة المقسمة بالكامل من تلك المكتبة لأنها ليست جزءًا من taghelper ولم تكن كذلك.

لا يختلف استخدام حزم nuget من مطوري OSS عن Microsoft في أنه إذا كنت عالقًا في aspnet core 1.1 فلا يمكنك الحصول على إصلاحات وتحسينات من aspnet core 2.x ما لم تقم بالتحديث إلى إطار العمل الجديد.

تضمين التغريدة
لقد ذكرت للتو هذا المثال لتوضيح وجهة نظري حول الحلول المضمنة مقابل الحلول الخارجية ، ما زلت ممتنًا لعملك على مساعد علامة ترقيم الصفحات هذا ... تستخدم الجامعة حزمة ترقيم الصفحات الخاصة بك وهم سعداء: القلب:

تضمين التغريدة

هل يجب أن ننتظر Microsoft لتقديم كل التعليمات البرمجية التي نحتاجها؟

هذه هي المشكلة الرئيسية ، نعتقد أنه عندما تقدم Microsoft حلاً رسميًا ، فإنها ستحارب أي حل آخر مفتوح المصدر أو ستكتب كل سطر من التعليمات البرمجية بأنفسهم: ابتسم:

بالطبع لا ، يمكننا أفضل ما في العالمين ، الحل الرسمي والحل القائم على المجتمع إذا تبنت Microsoft الحلول الصحيحة وابتكرت الحلول المفقودة ، بحيث يمكن للمطورين التركيز على المساهمة فيها.

لقد فهم مجتمع django الأمر بشكل صحيح ، فهم يقدمون / يتبنون رسميًا الحل الأولي البسيط لمشكلة معينة ، على سبيل المثال إطار عمل RESTful ، وبناء المجتمع فوق ذلك ... ألق نظرة هنا على المرحلة الأولى من بناء django-rest- إطار العمل: https://www.djangoproject.com/weblog/2016/jun/22/django-rest-framework-funding/

لقد بدأوا المشروع الأولي ، والمجتمع يتحسن / يبني علاوة على ذلك ، هذا هو الريبو الخاص بهم: https: //github.com/encode/django-rest-framework ... حوالي 800 مساهم!
والمجتمع مدفوع لبناء حزم تحل المشكلة أعلى تلك الحزمة مثل django-rest-auth أو django-rest-framework-jwt .

على الأقل يقدمون مثل هذه "الحلول الرسمية" التي يحتاجها معظم المطورين ، مثل django-admin-site أو django-debug-toolbar . يأتي هذا أيضًا من فلسفة Python لـ "البطاريات المضمنة" ، في البداية ، اعتقدت أنها سيئة لأنها تسعى جاهدة للوصول إلى حلول القاسم المشترك الأقل ، وأدركت لاحقًا النسيم الذي يجلبه.

* ملاحظة: Dapper (بواسطة StackExchange) و EFCore (بواسطة Microsoft) كلاهما ORMs ، لكنهما يهدفان إلى حل نفس المشكلة بطرق مختلفة. تم إنشاء Dapper في البداية في عام 2011 بينما EFCore 2014 ... هل أثر EFCore على المشاريع مفتوحة المصدر بشكل سيء؟ بالطبع لا ، وهو حل رسمي رغم ذلك!
يقوم الأشخاص بالفعل بالبناء فوق تلك الأشياء المدهشة ، مثل هذا: https://github.com/crhairr/EntityFrameworkCore.MongoDb/

هل أثرت EFCore بشكل سيء على المشاريع مفتوحة المصدر؟

أوه ، أي شخص يتذكر NHibernate (وهو الأقرب إلى EF في الوظيفة)؟ لا ، على الأرجح لا ، لأنها جيدة مثل الموت بعد إطلاق EF

@ 0xRumple

بالطبع لا ، يمكننا أفضل ما في العالمين ، الحل الرسمي والحل القائم على المجتمع إذا تبنت Microsoft الحلول الصحيحة وابتكرت الحلول المفقودة ،

في هذه الحالة ، ليس الأمر كذلك لأنه يعيد إنشاء حل موجود ، ولكن بوظائف أقل عن قصد.

Entity Framework و Dapper مختلفان تمامًا. تم تصميم EF دائمًا لتكون ORM كامل الميزات ، وكلاهما جاء بعد سنوات من Linq-To-SQL الأصلي

ومع ذلك ، لا أعتقد أنك مخطئ أيضًا ويبدو أننا نتحدث جميعًا عن بعضنا البعض. الخيط هو في الغالب تعليقات حول منتج خادم المصادقة بينما تتحدث عن المكتبات ذات الصلة بـ REST ، والتي تبدو صغيرة ومركزة بما يكفي لتضمينها في إطار عمل ويب. أوافق على أن المعلمات الموحدة search/paging/filter ستكون مفيدة في أن تكون مدمجة في كود Web API.

لا تعترف هذه المناقشة بالحقيقة المحرجة التي مفادها أنه في بعض المؤسسات ، يتعين على المطورين مراعاة كل حزمة مفتوحة المصدر يتم تقديمها في حلهم. في بعض الحالات ، يكون هذا فحصًا تلقائيًا ينتج عنه تقارير "مخاطر" والتي كثيرًا ما يحتاج مدير المخاطر غير الفني إلى مراجعتها. ستعمل هذه الأدوات على وضع علامة على أي شيء لم يتم صيانته بشكل نشط وأي شيء له أي شيء يشبه ترخيص الحقوق المتروكة.

يمكنك أيضًا أن تتخيل أنه في هذه المنظمات يُنظر إلى المساهمة في المصادر المفتوحة على أنها كلام مجنون.

نعم ، إن Identity Server 4 مذهل. لكن بالنسبة لمدير مخاطر غير تقني ، فهذا شيء ليس لدينا ضمان له ، شيء مدعوم من قبل مجموعة قليلة من الأشخاص ، بل والأسوأ من ذلك - شيء به كود المصدر متاح ليراه الجميع. هذا الشخص مضلل لكن المطور العادي على الأرض لن يفوز في هذه المعركة.

يمكن أن يكون "Identity Server Lite" كما تضعهmarkrendle بشكل مناسب ، والذي تم كتابته بشكل أساسي من قبل موظفي Microsoft ، هو الاختلاف في السماح باستخدام .NET Core على الإطلاق أو لا ، خاصةً إذا كان هناك مهندس معماري في المؤسسة يصر على أن بعض $$ يتم استخدام خردة المؤسسة من HP أو IBM بدلاً من ذلك للمصادقة.

تضمين التغريدة

لكن بالنسبة لمدير مخاطر غير تقني ، فهذا شيء ليس لدينا ضمان له ، شيء مدعوم من قبل مجموعة قليلة من الأشخاص ، بل والأسوأ من ذلك - شيء به كود المصدر متاح ليراه الجميع.

أنا متأكد من أن أفراد IdentityServer سيقدمون بعض الدعم إذا دفعت لهم مقابل ذلك - تمامًا مثلما تدفع لـ Microsoft. لا تعني OSS مجانية.

ما الذي يجعلك تعتقد أن فريق ASP.NET Core في Microsoft ليس "حفنة من الأشخاص"؟ سبويلر ... هم 20-30 شخص في المجموع. فقط زوجان سيعملان على منتج من هذا القبيل.

أنا فضولي حقًا لماذا "شفرة المصدر المتاحة ليراها الجميع" أمر سيء؟ وما الذي يجعلك تعتقد أن هذا المنتج في Microsoft لن يكون مفتوح المصدر؟ إنه الافتراضي الجديد.

khellang "شفرة المصدر المتاحة لتوضيح ذلك ، فهذا شيء جيد! لكنك ستندهش من الحجج التي يحتاجها بعض المطورين في العمل. ولسوء الحظ فإن نقطة "مايكروسوفت كتبتها" هي الحجة الوحيدة المقبولة في بعض الأحيان. لاحظ أنني ألعب دور محامي الشيطان عن شركة افتراضية ولكنها نموذجية غير فعالة.

وبالطبع يمكن للمطورين أنفسهم أن يدافعوا عن أن صاحب العمل يدفع مقابل دعم Identity Server ، لكن عملية الشراء ستحرمهم على الأرجح من إرادة العيش.

حسنًا ، إذا بدأنا في استخدام حجج المديرين غير التقنيين ، فستبدأ الأمور في الجنون. IMHO ، الأشخاص غير التقنيين ، يجب ألا يمليوا ما يجب استخدامه أم لا. إذا كانوا يريدون أن يكون لهم قول مأثور ، فعلى الأقل يجب أن يعرفوا ما الذي يتحدثون عنه ، والقول إن حزمة معروفة جيدًا مثل IdentityServer أقل جودة من MS واحدة ، بالنسبة لي ، هذا خطأ واضح. أود أن أهرب من شركة كهذه!

لكن النقطة المهمة هنا هي أن الجميع يتفقون إلى حد كبير على أن قضاء الوقت في شيء موجود بالفعل ، إنه قوي وأن الكثير من الناس يستخدمونه أمر غريب بعض الشيء. أتساءل ما هو السبب الحقيقي وراء هذا .. لا أعتقد أنه كان مثل: أوه ، دعونا نبني شيئًا خاصًا بنا ، فقط لأننا نستطيع. هل يطلب العملاء فعلاً هذا الذي لسنا على علم به ربما؟

أنا شخصياً لا أرى مشكلة في وجود منافس آخر في مساحة خادم OAuth ، ولكنه أمر جيد.

قد يساعد في دفع عجلة التنمية في هذا المجال ، أو يكون مجرد حل سريع وقذر للأشخاص الذين لا يحتاجون إلى أكثر من ذلك - حل سريع وقذر.

إذا كنت تريد أو تحتاج إلى المزيد من خادم OAuth ، فلا يوجد ما يمنع أي شخص منا من استخدام الحلول الحالية. أو ، إذا كنت تريد نموذجًا يعمل بنقرة واحدة لتنفيذ بروتوكول OAuth الأساسي _ وليس أكثر من ذلك_ ، فإن هذا يبدو وكأنه هدف يستحق ، على الأقل بالنسبة لي.

أعتقد أن هذا الخيط قد تحول إلى مبدأ بالعين حول ماهية OSS ، وما هو MS الجيد في القيام به وما لا يجيده MS ، بدلاً من التركيز على ما هو موجود في خارطة الطريق لـ .NET Core 2.2 ، وهو ما حقًا الأمور هنا.

تضمين التغريدة
قال "NHibernate مات" ، من؟ أرى أن المشروع لا يزال على قيد الحياة ، ولديه قوة دفع أفضل من Dapper
https://github.com/nhibernate/nhibernate-core/graphs/contributors
https://github.com/StackExchange/Dapper/graphs/contributors

آه ، لم أذكر IdentityServer حتى الآن لأتمسك بوجهة نظري حول وجود إطار عمل RESTful ضمن pacakges الرسمية ... إليكم أفكاري حول IdentityServer ، إنها قوية ورائعة حقًا ، لكنها مشروع مكون من شخصين ، ألق نظرة على المقاييس:
https://github.com/IdentityServer/IdentityServer4/graphs/contributors

يتم تنفيذ حوالي 85 ٪ من العمل بواسطة شخصين ولا بأس في مشروع متعلق بالأمان ، ولكن في المؤسسة ، تفكر العديد من الشركات في إمكانية صيانة مثل هذه المشاريع في المستقبل. أخبرتني إحدى الشركات مؤخرًا أنها تريد مني استخدام React بدلاً من Vus.Js في مشروعها فقط لأنهم قالوا "vue.js هو إلى حد كبير Evan You" ... وأعتقد أنهم على حق. وهذا ما أحاول قوله منذ بداية النقاش حول الحصول على حزمة RESTful ضمن الحزم الرسمية ، لن تقبل أي شركة كبيرة استخدامك لحزمة "محتملة" غير محفوظة في مشاريعها.

ينطبق الأمر نفسه على معالجة البيانات / غربلتها (الترحيل والتشكيل والفرز ... إلخ) لأن كل مشروع تقريبًا يحتوي على تلك المتطلبات ، ونعم كما قال manigandham ، فهي موحدة ومباشرة.

تضمين التغريدة
هذا بالضبط ما أعتقد أنه صحيح ... تكييف الحلول رسميًا ، سواء ماليًا أو عبر جيثب أو على الأقل ذكرها في مستنداتهم أو دوراتهم (لقد رأيت بالفعل Hanselman يذكر SwashBuckle في إحدى دوراته في Microsoft Virtual أكاديمية رائعة حقًا ، وسيكون من الأفضل رؤية المزيد من التكيف مع مثل هذه المشاريع!).

تضمين التغريدة
أنت على حق ، لقد ذهبنا بعيدًا جدًا عن الموضوع الرئيسي ... ولكن كما ذكرت من قبل ، أصبحت asp core ناضجة جدًا (فعالة وموثوقة) ، وأعتقد أن الوقت قد حان للبدء بما هو خارج حلول بوكس .

أعتقد أن استبعاد مشروع لأنه يحتوي على مساهمين رئيسيين أمر سخيف للغاية. يتم صيانة IS4 بشكل جيد للغاية ويقضي هذان الشخصان الكثير من الوقت في الإجابة على الأسئلة ومساعدة الناس. كما يُنظر إليه على نطاق واسع على أنه أحد أفضل حلول البرمجيات الحرة والمفتوحة المصدر لخادم OAuth2 في السوق.

قال "NHibernate مات" ، من؟ أرى أن المشروع لا يزال على قيد الحياة ، ولديه قوة دفع أفضل من Dapper

@ 0xRumple لقد قلت "جيدة مثل الموتى" يبدو أن لديك بعض المقاييس الغريبة جدًا حول صحة واستخدام مشاريع OSS. هل من العدل مقارنة عدد الارتباطات في مشروع من عام 2003 مقابل التزام مستمر منذ عام 2011؟ هم أيضا _very_ وحوش مختلفة (كما ذكرنا سابقًا في الموضوع) ؛ لقد كان Dapper "كاملًا" (لا يعني ذلك أنه لم تتم صيانته أو تم التخلي عنه ، إلخ) لبعض الوقت ، بينما كان NHibernate (ومجموعة ميزاته) متخلفة عن الركب.
أعلم أن المشروع لا يزال يمر ، لكن لا أتذكر آخر مرة ، في آخر 7 سنوات لي ، كنت أستشير في .NET space ، حيث واجهت NHibernate في البرية (حيث لم يكن في طور يتم ترحيلها إلى Entity Framework). يعرف كل من كان يتابع هذه المساحة في العامين الماضيين جيدًا أن NHibernate كانت متخلفة عن الركب وتفقد حصتها في السوق لصالح Entity Framework. ما عليك سوى إلقاء نظرة على أرقام تنزيل NuGet وحدها: يحتوي Entity Framework على 45.8 مليونًا مقابل NHibernate مع 3.4 ميجا.

على أي حال ، فإن النقطة ليست Entity Framework مقابل NHibernate. كان مجرد مثال _one_. لقد أجرينا هذا النقاش مرارًا وتكرارًا ؛ في الآونة الأخيرة عندما قامت Microsoft بتدوير تطبيق حاوية IoC خفيف الوزن الخاص بها في ASP.NET Core أو عندما كانت Microsoft تفكر في طرح مخطط الكائنات الخاص بها. في أي وقت تدخل فيه Microsoft مساحة في مجتمع OSS ، فإنها تمتص الكثير (معظم؟) من الهواء خارج الغرفة. في كثير من الأحيان يكفي أن تختنق المشاريع الصغيرة التي يقودها المجتمع بمرور الوقت. أنا ومعظم أفراد المجتمع يعرفون ذلك جيدًا ؛ من المستحيل التنافس مع Microsoft في عالم Microsoft (.NET) الخاص. أفهم تمامًا أن لديهم عملاء يدفعون لهم يحتاجون إلى إرضائهم ، لذلك لا أتوقع أن تغير هذه التعليقات رأيهم: ابتسم:

ميزات رائعة :)

أين يمكنني الحصول على مزيد من المعلومات لميزة الفحص الصحي؟

تحسين إدارة الشهادات الموقعة ذاتيًا

عند تطوير تطبيقات الويب التي تستدعي واجهات برمجة تطبيقات الويب المرتبطة ، تأتي نقطة عندما يكون من المفيد اختبارها مع المستخدمين الداخليين عبر الشبكة المحلية. ربما تكون قد اجتزت جميع اختبارات الوحدة والوظيفية والاندماج ، ولكن لا يوجد شيء يشبه الإنسان تمامًا لكسر الأشياء.

انطلاقًا من مخاوف الفصل ، تستدعي تطبيقات الويب العديد من واجهات برمجة تطبيقات الويب. في المثال الأول ، أقوم بتطوير واجهات برمجة تطبيقات الويب هذه باستخدام https: // localhost :. بمجرد أن تصبح واجهة برمجة تطبيقات الويب جاهزة (بشكل كافٍ) ، أقوم بعد ذلك بنشرها على IIS على جهازي المحلي. يحتوي كل موقع على اسم مضيف مناسب قمت بإعداده على خادم DNS الداخلي الخاص بي. في هذه المرحلة ، أستخدم Barry Dorrans -blowdart - https://gist.github.com/blowdart/1cb907b68ed56bcf8498c16faff4221c لإنشاء شهادة خادم. التزويدأستورد الشهادات في جميع المتاجر الصحيحة ، كل شيء يعمل على جهازي دون أي إنذارات.

يتغير هذا عندما يصل الأشخاص الآخرون على الشبكة إلى تطبيقات الويب (تكون جميع مكالمات واجهة برمجة التطبيقات داخل صندوق التطوير الخاص بي). تلقى المستخدم تحذيرات رهيبة. أطلب منهم تجاهل هذه التحذيرات ، وحيثما أمكن وبشكل مباشر بما فيه الكفاية ، قم باستيراد الشهادات. نظرًا لأن هذه الشهادات الموقعة ذاتيًا لها نفس اسم المُصدر والاسم الشائع ، يقوم كل تطبيق ويب جديد بتشغيل صفحة تحذير

لا يسعني إلا التفكير في أن مطالبة المستخدمين في مؤسسة واحدة بالمرور عبر صفحات التحذير فكرة سيئة.

بصفتي شخصًا غير متخصص في الأمان ، هناك بعض الأشياء التي أود رؤيتها:

• القدرة على الحصول على شهادة جذر محلية لجميع شهادات التطوير التي أقوم بإنشائها ومن ثم يتم إخباري بطريقة مصرح بها لاستيراد ذلك إلى أجهزة الكمبيوتر الشخصي وأجهزة Mac و Android و iPad و iPhone ، بحيث لا تحدث هذه الصفحات المزعجة

• طريقة أسهل لإنشاء شهادات لواجهات برمجة التطبيقات التي يمكن استخدامها مع IIS و Kestrel التي تملأ جميع مخازن الشهادات الصحيحة بشكل صحيح

CrispinH لنكون صادقين ، فإن دعم المرجع المصدق الجذري سيكون ، حسنًا ، مصدر قلق

blowdart كان أحد أسباب مرجع مصدق جذري وفشلت في تصحيحه على الرغم من الافتقار إلى الكفاءة في هذا المجال. حتى أنني حاولت معرفة كيفية تعديل جوهرك لقبول مرجع مصدق محلي.
كانت جميع الوثائق التي وجدتها عامة جدًا - كل ما أردته هو عملية إنشاء شهادات (تستند بشكل مثالي إلى المرجع المصدق الجذر) فقط لحماية واجهات برمجة التطبيقات وتطبيقات الويب بشهادة خادم. ربما كل ما نحتاج إليه هو التوثيق الخاص بحالة معينة.

يأتي CrispinH Window Server مع المرجع المصدق الذي يمكنك إعداده ، إذا كنت تريد المضي قدمًا بشكل كامل.

الشهادات بشكل عام ليست موضوعًا سهلاً وسيتعين عليك تعلم الكثير للقيام بذلك بشكل صحيح.

لأغراض التطوير ، تعد الشهادات الموقعة ذاتيًا جيدة تمامًا وسهلة الاستخدام. كل شيء يتجاوز ذلك ، بما في ذلك إنشاء CA وإدارته ، لم يعد لأغراض التطوير وبالتأكيد خارج النطاق ومعقد للغاية بالنسبة لإطار تطبيق الويب.

CrispinH كما قال poke أنه من الصعب

إذا كنت تريد حقًا الانتقال إلى هذا الجذر (يقصد التورية) ، فقد يبدأ https://infiniteloop.io/powershell-self-signed-certificate-via-self-signed-root-ca/ لكن هذا لا يمنحك CRL أو OCSP أو دعم الإبطال. يبدو أن https://gist.github.com/Soarez/9688998 يغطي OpenSSL. وإذا كنت بحاجة إلى CRLs ، فهناك CA مضمنًا في النوافذ ، وإعداد هذا موثق هنا https://leastprivilege.com/2008/08/14/how-to-build-a-developmenttestdemo-ca/

_ لاحظ أنني لم أستخدم أيًا من الروابط أعلاه (على الرغم من أنني أثق في مؤلف آخر رابط) ، ولا يعتبر هذا بأي حال من الأحوال أي نوع من توصيات MSFT الرسمية. التوصية الرسمية لفريق أمان ASP.NET هي السماح لشخص يفهم البنية التحتية والمخاطر بإعداد مرجع مصدق للشركة نيابة عنك. تحدث إلى قسم تكنولوجيا المعلومات لديك_

blowdart لا ، أنا حقًا لا أريد أن أذهب إلى هذا "الجذر". من الجيد معرفة السبب الآن.

يبدو أنه يجب إجراء اختبار الإنسان الخاص بي على الإنترنت العام على مضيف اختبار باستخدام شهادات Let's Encrypt ، ولكن مع وجود جدار مصادقة في مكانه لإبعاد أعين المتطفلين.

بناءً على ما تحتاجه وميزانيتك ، تقدم بعض الشركات مثل DigiCert خدمات PKI مُدارة. يمكن أن يستخدم جذر خاص أو عام. لا أعرف التكاليف.

وإذا كان HTTPS يتذكر فقط ، فستحصل على شهادة لكل مجال فرعي azurewebsites.net.

موازنة تطبيق OpenID الجديد ، بدلاً من تطبيق آخر للتعلم واحتضان والمشاركة مع جهود مجتمع IdentityServer4 والمساهمة في إنشاء إصدار "لايت" IdentityServer الذي يمكن تضمينه من nuget والإعداد بأقل جهد ممكن.

أنت تبالغ في رد فعلك.
يفكر فريق ASP.NET بالفعل مثلكم جميعًا. تحدثت DamianEdwards عن ذلك في أحدث قائمة مجتمعية.

هذا هو الجزء الأكثر صلة بالموضوع (لكنني أشجعك على الاستماع إلى كل ذلك):

"نحن في الواقع نتحدث إلى الناس IdentityServer حول ذلك الآن."
https://youtu.be/Tzh2EXwgEk8؟t=25m15s

من المثير للاهتمام حقًا معرفة مدى حماسة المناقشة حول مشروع "خادم ترخيص MSFT": ابتسامة:

بالمناسبة ، اتصل بي Vittorio Bertocci منذ عامين بالضبط للدردشة حول هذا المشروع حيث كانوا يفكرون في استخدام OpenIdict (خادم OIDC الذي أطوره وصيانته) كقاعدة لهذا المشروع.
في العام الماضي ، قيل لي إنهم يفضلون المضي في التنفيذ الخاص بهم بدلاً من الاستفادة من OSS لطرف ثالث حيث تم اعتباره "إستراتيجيًا للغاية" من منظور الأعمال (وهو شيء يمكنني فهمه).

يسعدني أن أرى أنهم غيروا رأيهم ويفكرون أخيرًا في استخدام حل OSS حالي مثل IdentityServer4 بدلاً من إنشاء شيء آخر من البداية: إنها إشارة جيدة جدًا تم إرسالها إلى مجتمع .NET: التصفيق:

هذا ينحرف قليلاً عن الخيط ، لكن https://stackoverflow.com/questions/51123289/how-to-generate-a-response-to-a-csr- in-net-core-ie-to-write-a-csr-signature-se. يتضمن .NET Core 2.0 مرافق أخرى لإنشاء الشهادات والعمل معها أيضًا. انظر التعليقات حول تشغيل CA أيضًا. تكاد تكون أدوات المكتبة موجودة ، واعتمادًا على مؤسستك ، قد تتمكن من استخدام الشهادات بطريقة خاضعة للرقابة في بعض الخوادم دون تعيين الكثير من البنية التحتية. على هذا الرمز ، ستكون قراءة طلبات توقيع الشهادة (المشفرة DER) خارج الصندوق إضافة رائعة - جنبًا إلى جنب مع مكتبة JSON-LD. والمزيد من العملات المشفرة بشكل عام. :)

أرغب في رؤية بعض البرامج الوسيطة مثل دعم LetsEncrypt - العمل مع خدمات التطبيقات في Windows و Linux و Docker في Azure.

kieronlanning أوافق ، بالإضافة إلى ترميز DER فيما يتعلق بتوقيع CSR المذكور سابقًا (على الرغم من أن إضافة الدعم بدون حالات الحافة لا يبدو بهذه الصعوبة). هناك عدد قليل من المكتبات لـ .NET (مدرجة أيضًا في صفحات Let's Encrypt) ، ولكن هناك أيضًا القليل من المتاعب. على سبيل المثال ، يبدو أن .NET الأكثر نشاطًا تم صيانته فيما يتعلق بـ Let's Encryptc واحد هو Certes ، ولكنه BouncyCastle . سيكون من اللطيف أن يساعدها شخص ما في أن تكون .NET Standard 2.0 فقط. أحد الأسباب بالنسبة لي هو أن BouncyCastle لا يعمل بشكل جيد مع Orleans TaskScheduler . :)

فيما يتعلق بذكر التشفير ، على الرغم من أنه ليس مشكلة ASP.NET Core بشكل صارم ، يبدو أن MS تضغط بشدة على blockchains ، لكن .NET يفتقر إلى القدرة على التشفير. _ على السطح _ يتعلق الكثير من هذا بنواة ASP.NET أيضًا (مثل ، على سبيل المثال ، تطبيقات مستكشف blockchain المختلفة ، مثل https://etherscan.io/) وسيكون من الجيد الحصول على المزيد من الدعم لـ مكتبات مثل Inferno والمزيد من القدرات المخبوزة في النظام الأساسي. توجد مشكلة معلقة واحدة على https://github.com/sdrapkin/SecurityDriven.Inferno/issues/10#issuecomment -395778931 (يمكنك إضفاء بعض العيون هنا إذا كان لدى شخص ما القطع للمساعدة).

سيكون هذا من kieronlanning طلب الميزة رقم واحد:

"أود أن أرى بعض البرامج الوسيطة مثل دعم LetsEncrypt."

ها هي المشكلة المفتوحة: https://github.com/aspnet/Home/issues/1190. يرجى الذهاب والتصويت عليه.

هل تعتبر حزمة messagepack متاحة على asp.net الأساسية لجميع الأطر وليس فقط على SignalR؟ نظرًا لأن تأطير Http2 ثنائي ، فهل تفكر في حزمة الرسائل لذلك؟

صدر خادم الإذن على Preview3؟

إنه موجود بالفعل. https://IdentityServer.io

تضمين التغريدة
أنا أحب واستخدام IdentityServer
لكنني أشعر بالفضول لرؤية تطبيق Microsoft وفهم سبب عدم دمج (Microsoft) لخادم الهوية في مركزك

@ danroth27 - هل يمكنك مشاركة آخر الأخبار؟

تستخدم Microsoft IdentityServer.

فكيف يعمل هذا؟ تستخدم Microsoft رمز IDS4 مباشرة؟ مايكروسوفت تقلل من ميزات IDS4؟ ما هو النموذج هنا؟ ماذا يجب أن تكون توقعاتنا؟ هل هناك مسار هجرة محتمل بينهما؟

ستستخدم Microsoft حزمة nuget القياسية الخاصة بنا وتستخدم واجهة برمجة تطبيقات التكوين الخاصة بنا لمنحك بعض الإعدادات الافتراضية للعب بشكل جيد مع القالب و ASP.NET Identity. هذا كل شئ.

يمكنك تحقيق نفس الشيء بالضبط اليوم بالفعل.

من المحتمل أن يكون هذا أنا ، لكنني مندهش عندما قرأت أن فجوة خادم تفويض Microsoft تم ملؤها بواسطة IdentityServer4. حسب فهمي ، فإن الشاغل الرئيسي لـ IdentityServer هو المصادقة ، وليس التفويض.

بالنسبة لي يعتبر IdentityServer بخير كخادم مصادقة ، لكنه لا يعمل كخادم تفويض. افترضت أن هذا هو سبب إنشاء PolicyServer.

leastprivilege هل سيتم توسيع IdentityServer بشيء مثل PolicyServer؟

Ruard لذا فإن الأمر محير (ومن المحتمل أن

OAuth عبارة عن مصادقة ، ولكنها تحتوي على إذن كخطوة أولى ، ثم تصدر منحة بناءً على النطاقات وما إلى ذلك ، لذا ، في غلافنا ، سيقوم Identity Server بإجراء تسجيل الدخول ، والتحقق من صحته ، والتحقق من صحة النطاقات المطلوبة (والتي في الحالة الأولية سوف تنجح دائمًا لأننا نستخدم النطاق الافتراضي) ، ثم مرر رمزًا مميزًا مرة أخرى إلى المتصل ، والذي يتم إرساله بعد ذلك إلى واجهة برمجة التطبيقات التي ستتحقق منه ، وبعد ذلك ، اختياريًا ، يمكنك المضي قدمًا في قواعد التفويض داخل واجهة برمجة التطبيقات. يوفر OIDC مزيدًا من الخلط بين OIDC من خلال كونه وسيلة للحصول على معلومات هوية المستخدم ، بما في ذلك التفويض بالسماح للتطبيق بالحصول عليها ...

لذلك ، بشكل أساسي ، سيعطينا Identity Server هوية ، مما يسمح للتطبيق بالحصول عليها ، وبعد ذلك يمكنك استخدام أجزاء تفويض ASP.NET لمزيد من التحكم في الوصول.

MichelZ ستكون هناك قصة يكبرون. سنقوم بتكوين السيناريوهات البسيطة ، وبمجرد الخروج من تلك السيناريوهات ، يمكنك استكشاف القوة الكاملة لنموذج تكوين IdentityServer.

blowdart نحن نستخدم IdentityServer بالفعل (ونحن
نحن نحب كلا المنتجين ، ASP.NET Core و IdentityServer (4) بنفس الطريقة. إنها بالتأكيد خطوة في الاتجاه الصحيح IMHO.
ومع ذلك ، فإننا ندرك أيضًا أن كل هذه البروتوكولات ليست "مباشرة إلى الأمام". إنهم ليسوا علم الصواريخ الذي تفهمه ، لكنهم لا يزالون غير مستقيمين أيضًا.

أتمنى أن يخترع شخص ما بروتوكولًا بسيطًا حقًا ، تاركًا وراءه جميع التطبيقات القديمة والتركيز على المستقبل.

إذا كنت تستخدمه بالفعل ، فلن يتغير استخدامك حقًا ، فأنت تعمل :)

نحن نهدف إلى File New> Web API مع المصادقة الفردية ، ثم إضافة واجهات برمجة تطبيقات أخرى ، وكل شيء يعتمد على الاتفاقية. لن يعمل هذا مع التطبيقات الحالية ، لأن الاتفاقيات ستكون جديدة. لا أخطط لاستبدال التهيئة الخاصة بك بتكويننا :)

أتمنى أن يخترع شخص ما بروتوكولًا بسيطًا حقًا ، تاركًا وراءه جميع التطبيقات القديمة والتركيز على المستقبل.

هذه هي المشكلة - التطبيقات تزداد تعقيدًا وليس أقل. لتأمينهم ، فإن الأمن معقد أيضًا. لطالما كنت أتراجع عندما أسمع الناس يقولون إن IdentityServer معقد - إنه ليس كذلك. إنها متطلبات أمان تطبيقك المعقدة. في كثير من الأحيان لا يملك الناس وجهة نظر لإدراك ذلك.

نعم ، إنها تعمل - وهي تعمل بشكل جيد - ولكن مع ذلك ، فإن هذا التأكيد الإضافي (قد) يمنحك ، عندما "تؤيد" Microsoft رسميًا و "تدعم" في النهاية تقنية ما هي ذهب خالص ....!
لقد تم رفعك إلى مستوى جديد تمامًا!

brockallen نعم ، ربما تعقد التطبيقات الأمور كثيرًا. ومع ذلك ، فإن بروتوكول OIDC ورث بلا شك بعض الأشياء من OAuth 2.0 التي كان من الأفضل التخلص منها. قال بعض أعضاء فريقك (أعتقد أنه كانeastprivilege) أنه إذا تم تطوير OIDC من الألف إلى الياء ، فمن المحتمل أن يبدو مختلفًا تمامًا عما لدينا الآن.

أنا لا أقول أن ما لدينا الآن هو "سيء" ، فأنا أقدر حقًا ما لدينا ، وهو فعال حقًا لأغراضنا ، وآمل أن يفخر كل من شارك في إنشائه بالعمل الذي قاموا به!

@فريق؛
للمعاينة 3 ، هل يمكنك تقديم بعض المستندات التفصيلية على "خادم التفويض" وكيف سيعمل باستخدام واجهة برمجة تطبيقات الويب وجانب العميل JS ، مثل Vue؟
نحتاج إلى اتخاذ قرار وهذه المعاينة على خادم التفويض هي معاينة حاسمة وأي مستندات تفصيلية ستعطينا معلومات عن قرارنا.

شكرا!

كما تمت مناقشته من قبل

https://identityserver.io

لاحظت للتو أيضًا أن واجهات برمجة تطبيقات البيانات المفتوحة في الولايات المتحدة موجودة في JSON-LD: https://project-open-data.cio.gov/v1.1/schema/. يبدو أن هذا اتجاه سريع النمو ، لذا سيكون من الجيد استخدام مكتبة JSON-LD .NET ذات الموارد الجيدة والمستخدمة مع ASP.NET. :)

veikkoeeva كذلك (على الأقل جزء من) واجهات برمجة تطبيقات NuGet. إنهم يستخدمون json-ld.net ، ولا حاجة إلى مكتبة أخرى.

khellang وهناك مكتبات أخرى أيضًا ، يمكن لهذه المكتبة الخاصة استخدام

IMHO ، إضافة IdentityServer4 إلى جوهر ASP.Net Core هي فكرة سيئة.
من فضلك لا تجعل .NetCore كإطار موحد.
.NetCore موجود و IdentityServer4 موجود هناك ، يصنع الناس البنية الأساسية بناءً على احتياجات المصادقة والتفويض الخاصة بهم.

mikeandersun الخطة هي فقط الحصول على تكوين افتراضي سهل يمكنك إضافته إلى مشروعك لجعله يعمل خارج الصندوق.

لا يزال بإمكانك عدم استخدامه ، ولن يؤثر عليك. لا يزال بإمكانك استخدام IdSrv وتهيئته بالكامل بنفسك. لا يزال بإمكانك اختيار المكونات المراد تضمينها في مشروعك. لا شيء من هذا يجعل ASP.NET Core متجانسة.

ASP.NET Core! = NET Core راجع للشغل.

هل سيكون الإصدار 2.2 إصدار LTS؟ (السؤال عما إذا كان قد تم الإعلان عنه بالفعل ، ولا يطلب منك إصدار إعلان جديد.)

yzorg لا لم يتم الإعلان عنه. غالبًا ما يتم هذا التحديد بعد الإصدار استنادًا إلى الجودة / الاستقرار.

blowdart ، هل سيوفر هذا النموذج خادم هوية مع عميل MVC لتطبيق ويب بدلاً من واجهة برمجة التطبيقات؟

@ Ponant No. إنه يستهدف واجهات برمجة التطبيقات فقط. سنعيد تقييم ذلك في المخطط الزمني 3.x.

شيق .. هذا السؤال طرح في اجتماع أمس. إذا قمنا ببناء مشروع "MVC" كامل بدون استخدام Web API ، فهل يمكننا استخدام قالب ASP.Net 2.2 IS4 الجديد المدمج في 2.2؟
يبدو أن الرئيس الكبير (باري) أجاب للتو على السؤال.

blowdart allias مدرب كبير: لماذا لم يتم ذلك في طلقة واحدة؟ يبدو تافهًا للوهلة الأولى استخدام عميل mvc أو واجهة برمجة تطبيقات ويب تتحدث إلى خادم IS4 للهوية الأساسية asp.net.

Ponant لأننا لا نملك موارد غير محدودة. ما هي الميزات التي كنت ترغب في إسقاطها من أجل وضع الجميع على تغيير جزء كبير من تدفق MVC والذي لن يعطي أي ميزات جديدة ، فقط قم بتغيير طريقة عمل واحدة موجودة؟ كانت واجهة برمجة التطبيقات (API) الفردية المصادق عليها فجوة بين إطار العمل الكامل و ASP.NET Core. كان تركيز العمل على سد هذه الفجوة. يحتوي Identity Server بالفعل على قوالب عمل لـ MVC مع Identity Server كـ "قلب".

blowdartCrispinH أنا أتفق معك كليا بحماس، إدارة المستخدم، أدوار، الإيجار وهناك حاجة ماسة المستخدم المجموعات. انظر إلى هذا - هناك 7 تذاكر Uservoice كلها تشتكي من هذا العدد الهائل من المطورين والشركات. للأسف العديد من التقنيات الأخرى مثل بوابة Java blueRay JSR 182 أو 173 مثل هذه الوظيفة الجميلة هنا!

-> العديد من الطلبات لإدارة المستخدمين / المجموعات / المستأجرين

-> مرة أخرى هنا يشتكي الناس ... الأمر مستمر ، حتى على Twitter و facebook .. وهذا هو السبب - لماذا تكون المنصات الأخرى مثل WP و PHP أسهل!

بينما يعتقد manigandham أن خادم الهوية مناسب تمامًا ، إلا أنهم يتقاضون رسومًا كبيرة التكلفة الإجمالية للملكية المنخفض. كم من الناس يمكنهم حقا تحمل هذا. لقد كانت عقبة ضخمة وخطوة إلى الوراء ، هناك حاجة إلى وظيفة الفانيليا الأساسية وواجهة المستخدم الرسومية لإدارة المستخدمين / الأدوار / الأدوار-مجموعات_المستخدمين / المستأجرين ، والتي يمكن بعد ذلك تحسينها بواسطة المطور

papyr لماذا لا تبدأ مشروعًا مفتوح المصدر لهذا الغرض؟ لا يلزم تضمين واجهة المستخدم الرسومية الكاملة لكل شيء في إطار العمل (القوالب). ومجرد رؤية مدى صعوبة قيام الفريق بالفعل بالحفاظ على تحديثات القوالب ، على سبيل المثال مع التغييرات في Bootstrap ، لا أريد حقًا أن يضيعوا المزيد من الجهد في ذلك. لكن على الجانب الآخر ، أدرك تمامًا أن هذا سيكون شيئًا مفيدًا في الوجود ، فلماذا لا تجعل هذا مجهودًا مجتمعيًا؟

papyrpoke لا حاجة لمشروع مفتوح المصدر جديد، وهناك مشاريع قائمة ممتازة.

إذا كنت تريد شيئًا مفتوح المصدر من MS مصمم للتنافس مع WordPress ، فابحث عن Orchard:
https://github.com/OrchardCMS/OrchardCore

إذا كنت تريد المزيد من نهج المكتبة بدلاً من إطار العمل ، فتحقق من cloudcribe ، التي تحتوي على أجزاء صغيرة للتأجير المتعدد والمستخدم وإدارة الدور والمطالبات مع تكامل اختياري لخادم الهوية 4 و cms اختياري (cloudcribe.Simple / content) شذرات إضافية.
https://www.cloudscribe.com/docs/introduction
https://github.com/cloudscribe/cloudscribe
https://github.com/cloudscribe/cloudscribe.SimpleContent

إذا كنت تريد شيئًا مفتوح المصدر من MS مصمم للتنافس مع WordPress ، فابحث عن Orchard:
https://github.com/OrchardCMS/OrchardCore

أنا أؤيد هذه التوصية.

وقد تم تصميم Orchard Core ليكون معياريًا للغاية. على سبيل المثال ، من الممكن استخراج الوحدة النمطية متعددة الإيجارات واستخدامها في مشاريعك الخاصة . يحتوي أيضًا بالفعل على وحدات لإدارة المستخدمين والأدوار ، وأنا متأكد من أنهم سيقدرون مساهمتك لجعلها أفضل.

يمكنك مشاهدة الكثير من العروض التوضيحية لمميزاتها المختلفة على قناتهم .

papyr لماذا لا تبدأ مشروعًا مفتوح المصدر لهذا الغرض؟

https://github.com/IdentityManager/IdentityManager2

يمكن أن يكون عنصر واجهة المستخدم هذا خادعًا ، وإن كان مفيدًا في الحصول على الأشياء الأساسية بسرعة. يبدو أنني صادفت مؤخرًا حالات بناء واجهة المستخدم ليست هي المهمة الأكبر ، ولكن اكتشاف كيفية ملء "احتياجات العملية" مثل الموافقة المسبقة على بعض رسائل البريد الإلكتروني (التي تفعل شيئًا خاصًا بالتطبيق) ، واستدعاء واجهات برمجة التطبيقات التي تستدعي واجهات برمجة التطبيقات ، قد يعني بعضها عمليات الانضمام في قاعدة البيانات أو المكالمات إلى مكان آخر وما إلى ذلك ، ثم إضافتها إلى الرموز المميزة ومنطق واجهة المستخدم.

لذا فإن الحصول على دروس تعليمية جيدة مثل https://mcguirev10.com/2018/01/28/login-identity-management-best-practices.html أو تلك الموجودة على https://mcguirev10.com/page2/ يبدو أكثر أهمية من واجهة المستخدم ( خاصة إذا كان المرء لا يستطيع أو لا يريد استخدام EF). ثم ربما ابحث عن واجهة المستخدم للتكنولوجيا المختارة (Aurelia / Angular / Razor / React / Vue وما إلى ذلك) وكيفية تنفيذ بعض معالجة البيانات.

فيما يتعلق بتسمية المشاريع والأسماء ، إلى جانب @ scottbrady91 ، وجدت أنه من المفيد جدًا التحقق من LindaLawton ، https://github.com/abergs/fido2-net-lib ( abergs ،aseigler)، TomCJones ، @ mackie1001 (Gitter) وما إلى ذلك لتقديم تفسيرات ورموز إضافية لإلقاء نظرة خاطفة عليها عند الخروج قليلاً من الحاجة الأساسية. لقد نسيت إضافة بعض الأسماء والمشاريع. :)

لماذا لايمكن. net الأساسية لديها صفحات ويب شفرة عادية؟ عندما أقوم بعمل تقارير معقدة ، أحب القيام بكل شيء من صفحة شفرة واحدة (c #). أو على الأقل القدرة على استخدام طريقة عرض فقط في بعض الأحيان فقط بدون نموذج أو وحدة تحكم.

بعبارة أخرى ، القدرة الأساسية على الاتصال بـ sql في العرض وتلقي طلب GET و POST ، معقم بالطبع ، أستخدم حاليًا فئة تسمى Striptag.cs.

لماذا لايمكن. net الأساسية لديها صفحات ويب شفرة عادية؟

يمكنك استخدام صفحات Razor لهذا https://docs.microsoft.com/en-us/aspnet/core/razor-pages/؟view=aspnetcore-2.1&tabs=visual-studio

يعد وجود فئة نموذج صفحة دعم أمرًا اختياريًا ؛ يمكنك فقط الحصول على صفحة واحدة

شكرا benaadams للإجابة ، كيف يمكنني استخدام طلب GET و POST مباشرة في صفحة ماكينة الحلاقة ، وإجراء اتصال أساسي بخادم SQL. الاتصال للاستعلامات العادية ، وليس الكيانات الإعلانية ، أو linq ، أو ORM. أنا دائما أفضل الاستفسارات العادية.

يحب:

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

أعلم أن سلسلة الاتصال موجودة في ملف json الآن ، لكن لا أعرف كيفية استخدامها في العرض. لم يتم توثيق بعض الأشياء بعمق.

حسنًا ، لديها منحنى تعليمي. إذا كنت ترغب في جلب البيانات _bقبل_ تحميل الملف الشخصي ، يمكنك القيام بذلك في الإجراء المقابل. لذلك ، بالنسبة إلى HomeController.ViewReports action و Views/Home/ViewReports.cshtml تكتب الصفحة:

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

إذا كنت ترغب في جلب البيانات _ بعد_ تحميل الصفحة ، فإنك عادةً ما تستخدم طلبات AJAX لبعض نقاط نهاية GET / POST الخالصة التي تعرض بيانات بتنسيق JSON.

لا يزال بإمكانك القيام بذلك على صفحة بدون أي تحكم أو إجراء ؛ شيء مثل

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

لقد استخدمت mvc asp.net و webforms وصفحات شفرات قديمة ، لذا فأنا لست جديدًا على هذا. لقد أمضيت 3 ساعات وما زلت لا أستطيع الحصول على صفحة اختبار بسيطة لماكينة الحلاقة للعمل ، ولدي:

<!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>

مجرد صفحة HTML ويتم تحميلها.

نموذج

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"];
        }
    }
}

رأي:

<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 ساعات وكل ما أحصل عليه هو صفحة فارغة. حاولت بيان العودة ، وما إلى ذلك

إذا كتبت للتو http: // localhost : 51307 / pets / razdb3 ، فسأحصل على الأقسام الثانية "مرحبًا" ، ولكن
@ Model.myvar لم أحصل على شيء.

أنا جديد على .net core ، ولم أكن لأتخيل أبدًا أنه سيكون أو قد يكون من الصعب جدًا عرض صفحة ماكينة حلاقة.

في مجتمع VS 2017

@ Model.myvar لم أحصل على شيء.

قمت بتعيين قيمة myvar عند طلب النشر ( OnPost ) من قيمة النموذج psearch ؛ لذلك قد تحتاج إلى تقديم طلب POST بهذه القيمة لتعيينه؟

في طلب GET ( OnGet ) الذي تحصل عليه من مجرد الانتقال إلى عنوان url من المتصفح ؛ بدلاً من إعادة النشر للنموذج ، لا يتم تعيينه على أي شيء.

حاول تعيينها على قيمة افتراضية بحيث تظهر عندما لا تقوم بتعيينها لتأكيد أن النموذج يتدفق من خلاله:

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

تغير إلى

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

وما زالت صفحة فارغة. @ Model.myvar صحيح؟

حتى تغيرت إلى

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>

إنه يبني جيدًا بدون خطأ ، ولكن صفحة فارغة بغض النظر عن ما أحاول.

التعليقات / الأفكار المهذبة: يبدو أن هذه المناقشة حول "صفحات الشفرات العادية" بدأت في الخروج قليلاً من الموضوع فيما يتعلق بموضوع هذا الموضوع.

😊 😊

آسف ، أدرك أنه كان يجب علي استخدام المنتدى. شكرًا لك benaadams ، لقد

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

هذه هي الطريقة التي كنت أفعل بها الأشياء عادةً على أي حال ، باستخدام الكلمة الرئيسية "الجديدة" ، مثل

EmployeeDataAccessLayer objemployee = new EmployeeDataAccessLayer();

كان من المطمئن أن ترى أنه لا يزال بإمكانك استخدام الفئات المخصصة في .net core.

عليك أن تعترف بأن .net core له منحنى تعليمي أكثر حدة من بعض أطر عمل asp.net السابقة. شكرا جزيلا.

تتحدث ملاحظات الإصدار عن ميزة "Authorization Server" التي من المتوقع أن تكون وظيفة إضافية في الأشهر القادمة. هل يتوفر المزيد من المعلومات حول هذه الميزة؟ أحاول أن أقرر ما إذا كان علينا انتظار ذلك. أو نبني حلنا الخاص.

تتحدث ملاحظات الإصدار عن ميزة "Authorization Server" التي من المتوقع أن تكون وظيفة إضافية في الأشهر القادمة. هل يتوفر المزيد من المعلومات حول هذه الميزة؟ أحاول أن أقرر ما إذا كان علينا انتظار ذلك. أو نبني حلنا الخاص.

أعتقد أن الخطة الحالية هي استخدام https://github.com/IdentityServer/IdentityServer4 بطريقة "معبأة مسبقًا".

بعد الملاحظات من فريق IS4 وفريق الأمن MS ، بدا أن MS كانت تحاول ببساطة عمل تغليف سريع وقذر لـ IS4 وتسميته اليوم. لكن يبدو أنه شخص يتمتع بقدر أكبر من الحكمة ، قرر التراجع والقيام بذلك بالطريقة الصحيحة ، حيث يمكن للأمن أن يخلق تأثيرات مضاعفة عندما لا يتم بشكل صحيح.

آمل أن يتم التكامل الكامل بين IS4 و ASP لدعم كل من Web API و MVC.

في هذه الأيام ، مطلوب المصادقة / التفويض من القوة الصناعية كحد أدنى. يعد Open Source (OSS) مناسبًا لمعظم الأشياء ولكن كانت هناك مخاوف جدية في بعض منتجات أمان OSS غير المقبولة في أي موقع ويب خاص بالمؤسسة. 85٪ من المشاريع تستخدم مكتبات قديمة تشكل مخاطر أمنية غير مقبولة. على سبيل المثال ، تستخدم خوادم الويب 45٪ Apache (https://www.cvedetails.com/vendor/45/Apache.html) الذي يحتوي على نقاط ضعف أكثر بكثير من IIS (https://www.cvedetails.com/product/3436/ Microsoft-IIS.html؟ vendor_id = 26). قد تكون المنتجات مثل Identity Server جيدة ولكن تعديلات المطور قد تجعلها غير آمنة تمامًا. نحتاج إلى حل مضمّن في Net Core يكون دائمًا آمنًا ...

في هذه الأيام ، مطلوب المصادقة / التفويض من القوة الصناعية كحد أدنى. يعد Open Source (OSS) مناسبًا لمعظم الأشياء ولكن كانت هناك مخاوف جدية في بعض منتجات أمان OSS غير المقبولة في أي موقع ويب خاص بالمؤسسة. 85٪ من المشاريع تستخدم مكتبات قديمة تشكل مخاطر أمنية غير مقبولة. على سبيل المثال ، تستخدم خوادم الويب 45٪ Apache (https://www.cvedetails.com/vendor/45/Apache.html) الذي يحتوي على نقاط ضعف أكثر بكثير من IIS (https://www.cvedetails.com/product/3436/ Microsoft-IIS.html؟ vendor_id = 26). قد تكون المنتجات مثل Identity Server جيدة ولكن تعديلات المطور قد تجعلها غير آمنة تمامًا. نحتاج إلى حل مضمّن في Net Core يكون دائمًا آمنًا ...

وجهة نظرك صحيحة تمامًا. لكن في بعض مقاطع الفيديو ، قال موظفو MS ، إنهم لن يعيدوا اختراع عجلات [الأمان] واستخدام نظام طرف ثالث [IS4]. لذلك آمل أن يكون هذا وضعًا مربحًا لنا جميعًا.

في هذه الأيام ، مطلوب المصادقة / التفويض من القوة الصناعية كحد أدنى. يعد Open Source (OSS) مناسبًا لمعظم الأشياء ولكن كانت هناك مخاوف جدية في بعض منتجات أمان OSS غير المقبولة في أي موقع ويب خاص بالمؤسسة. 85٪ من المشاريع تستخدم مكتبات قديمة تشكل مخاطر أمنية غير مقبولة. على سبيل المثال ، تستخدم خوادم الويب 45٪ Apache (https://www.cvedetails.com/vendor/45/Apache.html) الذي يحتوي على نقاط ضعف أكثر بكثير من IIS (https://www.cvedetails.com/product/3436/ Microsoft-IIS.html؟ vendor_id = 26). قد تكون المنتجات مثل Identity Server جيدة ولكن تعديلات المطور قد تجعلها غير آمنة تمامًا. نحتاج إلى حل مضمّن في Net Core يكون دائمًا آمنًا ...

لا يوجد شيء "آمن دائمًا" ، لا سيما شيء من Microsoft ؛)
دائمًا ما يكون في يد المستخدم هذه الأشياء لجعلها والحفاظ عليها آمنة.

سيتم تضمين IdentityServer في قوالب الشحن الجديدة post 2.2. سيكون التركيز الأولي هو التحكم في الوصول إلى واجهة برمجة التطبيقات - ولكن هناك خطط لتوسيع ذلك في المستقبل.

سيتم تزويد ASP.NET Core بواجهة برمجة تطبيقات (API) للتكوين المبسطة تغطي سيناريوهات القوالب فقط - ولكن سيكون من السهل جدًا البدء فيها. يمكنك الانتقال في أي وقت إلى نظام التكوين الأصلي IS الذي يمنحك سيناريوهات متقدمة.

سيتم تضمين IdentityServer في قوالب الشحن الجديدة post 2.2. سيكون التركيز الأولي هو التحكم في الوصول إلى واجهة برمجة التطبيقات - ولكن هناك خطط لتوسيع ذلك في المستقبل.

سيتم تزويد ASP.NET Core بواجهة برمجة تطبيقات (API) للتكوين المبسطة تغطي سيناريوهات القوالب فقط - ولكن سيكون من السهل جدًا البدء فيها. يمكنك الانتقال في أي وقت إلى نظام التكوين الأصلي IS الذي يمنحك سيناريوهات متقدمة.

شكرا على المعلومات دومينيك.
أعتقد أن "نقطة الانطلاق" هذه ستساعد الكثيرين على البدء ثم الانتقال إلى تنظيم الدولة الكامل. حركة جيدة.

سيتم تضمين IdentityServer في قوالب الشحن الجديدة post 2.2. سيكون التركيز الأولي هو التحكم في الوصول إلى واجهة برمجة التطبيقات - ولكن هناك خطط لتوسيع ذلك في المستقبل.

سيتم تزويد ASP.NET Core بواجهة برمجة تطبيقات (API) للتكوين المبسطة تغطي سيناريوهات القوالب فقط - ولكن سيكون من السهل جدًا البدء فيها. يمكنك الانتقال في أي وقت إلى نظام التكوين الأصلي IS الذي يمنحك سيناريوهات متقدمة.

جيد ان تعلم! شكرا لك.

أعتقد أن التحكم في الوصول إلى واجهة برمجة التطبيقات سيعتمد على نطاقات OAuth؟
لا يوجد دعم مباشر لمزيد من أذونات المستخدم المتقلبة مثل الموصوفة في Policyserver.io؟

سيتم تضمين IdentityServer في قوالب الشحن الجديدة post 2.2. سيكون التركيز الأولي هو التحكم في الوصول إلى واجهة برمجة التطبيقات - ولكن هناك خطط لتوسيع ذلك في المستقبل.
سيتم تزويد ASP.NET Core بواجهة برمجة تطبيقات (API) للتكوين المبسطة تغطي سيناريوهات القوالب فقط - ولكن سيكون من السهل جدًا البدء فيها. يمكنك الانتقال في أي وقت إلى نظام التكوين الأصلي IS الذي يمنحك سيناريوهات متقدمة.

جيد ان تعلم! شكرا لك.

أعتقد أن التحكم في الوصول إلى واجهة برمجة التطبيقات سيعتمد على نطاقات OAuth؟
لا يوجد دعم مباشر لمزيد من أذونات المستخدم المتقلبة مثل الموصوفة في Policyserver.io؟

PolicyServer هو الحل التجاري

أعتقد أن التحكم في الوصول إلى واجهة برمجة التطبيقات سيعتمد على نطاقات OAuth؟
لا يوجد دعم مباشر لمزيد من أذونات المستخدم المتقلبة مثل الموصوفة في Policyserver.io؟

IdentityServer "فقط". يحتوي ASP.NET Core على واجهة برمجة تطبيقات مدمجة لتخويل المستخدم - وإذا كان PolicyServer (المنتج) يبدو مثيرًا للاهتمام بالنسبة لك ، فأعلمني بذلك.

يتم إغلاق هذه المشكلة نظرًا لأنه تم شحن ASP.NET Core 2.2.

يجب ألا يتم تحديث هذا إلى ASP 3.0

أي تحديث حول متى سيتم شحن تحسينات Authorization Server؟