Results and Impact
- Average Latency improved from 350ms to less than 250ms.
- CPU during peak time was [60–40%]. This dropped to [15–25%].
- AWS Cost Reduction by replacing Windows with Linux servers [by 45%]
- Apache benchmarking [89 vs. 57 req/s]: .NET Core — 89.68 requests / second. .NET Framework on Windows — 57.21 requests/second
- JMeter [Throughput — 142.9 vs. 60.5 per second]: .NET Core Solution: Hit 1000 requests on http://XXXX.redbus.pe/ , Throughput was 142.9/Sec. NET Framework on Windows: Hit 1000 requests on http://XXXX.redbus.pe/, Throughput was 60.5/Sec.
- Blazemeter [90% response time — 417ms vs. 1.09s]: .NET Core Solution: 90% Response time was 417ms. .NET Framework on Windows: 90% Response time was 1.09s.
Generic Host چیست؟
Generic Host یکی از ویژگیهای جدید ASP.NET Core 2.1 است. هدف آن جداسازی HTTP pipeline برنامه، از Web Host API آن است. یکی از مزایای اینکار، امکان استفادهی از آن نه فقط در پروژههای وب، بلکه در پروژههای کنسول نیز میباشد. به این ترتیب میتوان کارهای غیر HTTP را از برنامهی وب مجزا کرد تا به کارآیی بیشتری رسید و برای این منظور اینترفیس IHostedService را که در فضای نام Microsoft.Extensions.Hosting قرار دارد، برای ثبت کارهای پسزمینهی خارج از اعمال web host جاری، ارائه دادهاند:
namespace Microsoft.Extensions.Hosting { public interface IHostedService { Task StartAsync(CancellationToken cancellationToken); Task StopAsync(CancellationToken cancellationToken); } }
یک مثال: معرفی کار پسزمینهای که هر دو ثانیه یکبار انجام میشود
در SampleHostedService زیر، عبارت Hosted service executing به همراه زمان جاری، هر دو ثانیه یکبار لاگ میشود و اگر برنامه را توسط دستور dotnet run اجرا کنید، میتوانید خروجی آنرا در کنسول، مشاهده کنید:
using System; using System.Threading; using System.Threading.Tasks; using Microsoft.Extensions.Hosting; using Microsoft.Extensions.Logging; namespace MvcTest { public class SampleHostedService : IHostedService { private readonly ILogger<SampleHostedService> _logger; public SampleHostedService(ILogger<SampleHostedService> logger) { _logger = logger; } public async Task StartAsync(CancellationToken cancellationToken) { _logger.LogInformation("Starting Hosted service"); while (!cancellationToken.IsCancellationRequested) { _logger.LogInformation("Hosted service executing - {0}", DateTime.Now); await Task.Delay(TimeSpan.FromSeconds(2), cancellationToken); } } public Task StopAsync(CancellationToken cancellationToken) { _logger.LogInformation("Stopping Hosted service"); return Task.CompletedTask; } } }
namespace MvcTest { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddSingleton<IHostedService, SampleHostedService>();
services.AddHostedService<SampleHostedService>();
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
Startup.cs(82,56): error CS0104: 'IHostingEnvironment' is an ambiguous reference between 'Microsoft.AspNetCore.Hosting.IHostingEnvironment' and 'Microsoft.Extensions.Hosting.IHostingEnvironment'
مشکلات پیاده سازی کار پسزمینهی SampleHostedService فوق
هر چند اگر مثال فوق را اجرا کنید، خروجی مناسبی را دریافت خواهید کرد، اما دارای این اشکال مهم نیز هست:
D:\MvcTest>dotnet run info: MvcTest.SampleHostedService[0] Starting Hosted service info: MvcTest.SampleHostedService[0] Hosted service executing - 02/19/2019 14:45:10 info: MvcTest.SampleHostedService[0] Hosted service executing - 02/19/2019 14:45:12 info: MvcTest.SampleHostedService[0] Hosted service executing - 02/19/2019 14:45:14 Ctrl+C Application is shutting down... Hosting environment: Development Content root path: D:\MvcTest Now listening on: https://localhost:5001 Now listening on: http://localhost:5000 Application started. Press Ctrl+C to shut down.
از دیدگاه ASP.NET Core، یک کار پس زمینه زمانی خاتمه یافته محسوب میشود که متد StartAsync، مقدار Task.CompletedTask را بازگرداند؛ در غیراینصورت، در حال اجرا درنظر گرفته میشود و چون در پیاده سازی فوق این نکته رعایت نشدهاست، این Task همواره در حال اجرا و خاتمه نیافته محسوب میشود و نوبت به مابقی کارها نخواهد رسید. همچنین در قسمت StopAsync نیز بهتر است یک فیلد CancellationTokenSource تعریف شدهی در سطح کلاس را مورد استفاده قرار داد و متد Cancel آنرا فراخوانی کرد تا اطلاع رسانی صحیحی را به متد StartAsync در مورد خاتمهی برنامه، انجام دهد.
برای این منظور و جهت ساده سازی و پیاده سازی تمام این نکات، از اینترفیس خام IHostedService، یک کلاس abstract به نام BackgroundService نیز در فضای نام Microsoft.Extensions.Hosting پیش بینی شدهاست:
namespace Microsoft.Extensions.Hosting { public abstract class BackgroundService : IHostedService, IDisposable { protected BackgroundService(); public virtual void Dispose(); public virtual Task StartAsync(CancellationToken cancellationToken); public virtual Task StopAsync(CancellationToken cancellationToken); protected abstract Task ExecuteAsync(CancellationToken stoppingToken); } }
namespace MvcTest { public class PrinterHostedService : BackgroundService { private readonly ILogger<SampleHostedService> _logger; public PrinterHostedService(ILogger<SampleHostedService> logger) { _logger = logger; } protected override async Task ExecuteAsync(CancellationToken stoppingToken) { _logger.LogInformation("Starting Hosted service"); while (!stoppingToken.IsCancellationRequested) { _logger.LogInformation("Hosted service executing - {0}", DateTime.Now); await Task.Delay(TimeSpan.FromSeconds(2), stoppingToken); } } } }
namespace MvcTest { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddHostedService<PrinterHostedService>();
D:\MvcTest>dotnet run Hosting environment: Development infoContent root path: D:\MvcTest Now listening on: https://localhost:5001 Now listening on: http://localhost:5000 Application started. Press Ctrl+C to shut down. : MvcTest.SampleHostedService[0] Starting Hosted service info: MvcTest.SampleHostedService[0] Hosted service executing - 02/19/2019 15:00:23 info: MvcTest.SampleHostedService[0] Hosted service executing - 02/19/2019 15:00:25 info: MvcTest.SampleHostedService[0] Hosted service executing - 02/19/2019 15:00:27 Application is shutting down... ^C
یک نکته: تزریق وابستگی DbContext برنامه در یک سرویس کار پسزمینه
IHostedServiceها با طول عمر singleton به سیستم تزریق وابستگیها معرفی میشوند. در این حالت اگر سرویسهایی با طول عمر transient و یا scoped را به آنها تزریق کنید، دیگر طول عمر مدنظر شما را نداشته و آنها هم به صورت singleton عمل خواهند کرد. هر چند خود سیستم تزریق وابستگیهای NET Core. با صدور استثنائی، از این مساله جلوگیری میکند (در این مورد در مطالب «مهارتهای تزریق وابستگیها در برنامههای NET Core. - قسمت چهارم - پرهیز از الگوی Service Locator در برنامههای وب» و همچنین «قسمت سوم - رهاسازی منابع سرویسهای IDisposable» بیشتر بحث شدهاست). یک چنین مواردی را به صورت زیر با تزریق IServiceScopeFactory و ساخت صریح یک Scope میتوان مدیریت کرد:
using System; using System.Threading; using System.Threading.Tasks; using Microsoft.Extensions.DependencyInjection; using Microsoft.Extensions.Hosting; public abstract class ScopedBackgroundService : BackgroundService { private readonly IServiceScopeFactory _serviceScopeFactory; public ScopedBackgroundService(IServiceScopeFactory serviceScopeFactory) { _serviceScopeFactory = serviceScopeFactory; } protected override async Task ExecuteAsync(CancellationToken stoppingToken) { using (var scope = _serviceScopeFactory.CreateScope()) { await ExecuteInScope(scope.ServiceProvider, stoppingToken); } } public abstract Task ExecuteInScope(IServiceProvider serviceProvider, CancellationToken stoppingToken); }
طراحی سرویس کارهای پسزمینهی زمانبندی شده
ASP.NET Core، متد ExecuteAsync را یکبار بیشتر اجرا نمیکند. بنابراین پیاده سازی تایمری که بخواهد برای مثال ارسال ایمیلهای خبرنامهی سایت را هر روز ساعت 11 شب انجام دهد، به خود ما واگذار شدهاست. برای پیاده سازی بهتر این تایمر میتوان از کتابخانهی NCrontab که توسط نویسندهی کتابخانهی معروف ELMAH تهیه شدهاست، استفاده کرد که با برنامههای NET Core. نیز سازگاری دارد:
dotnet add package ncrontab
┌───────────── minute (0 - 59) │ ┌───────────── hour (0 - 23) │ │ ┌───────────── day of month (1 - 31) │ │ │ ┌───────────── month (1 - 12) │ │ │ │ ┌───────────── day of week (0 - 6) (Sunday to Saturday; │ │ │ │ │ 7 is also Sunday on some systems) │ │ │ │ │ │ │ │ │ │ * * * * *
* * * * * * - - - - - - | | | | | | | | | | | +--- day of week (0 - 6) (Sunday=0) | | | | +----- month (1 - 12) | | | +------- day of month (1 - 31) | | +--------- hour (0 - 23) | +----------- min (0 - 59) +------------- sec (0 - 59)
using System; using System.Threading; using System.Threading.Tasks; using Microsoft.Extensions.DependencyInjection; using NCrontab; using static NCrontab.CrontabSchedule; public abstract class ScheduledScopedBackgroundService : ScopedBackgroundService { private CrontabSchedule _schedule; private DateTime _nextRun; protected abstract string Schedule { get; } public ScheduledScopedBackgroundService(IServiceScopeFactory serviceScopeFactory) : base(serviceScopeFactory) { _schedule = CrontabSchedule.Parse(Schedule, new ParseOptions { IncludingSeconds = true }); _nextRun = _schedule.GetNextOccurrence(DateTime.Now); } public override async Task ExecuteInScope(IServiceProvider serviceProvider, CancellationToken stoppingToken) { do { var now = DateTime.Now; if (now > _nextRun) { await ScheduledExecuteInScope(serviceProvider, stoppingToken); _nextRun = _schedule.GetNextOccurrence(DateTime.Now); } await Task.Delay(1000, stoppingToken); //1 second delay } while (!stoppingToken.IsCancellationRequested); } public abstract Task ScheduledExecuteInScope(IServiceProvider serviceProvider, CancellationToken stoppingToken); }
روش استفادهی از آن برای تعریف یک وظیفهی جدید نیز به صورت زیر است:
using System; using System.Threading; using System.Threading.Tasks; using Microsoft.Extensions.DependencyInjection; using Microsoft.Extensions.Logging; public class MyScheduledTask : ScheduledScopedBackgroundService { private readonly ILogger<MyScheduledTask> _logger; public MyScheduledTask( IServiceScopeFactory serviceScopeFactory, ILogger<MyScheduledTask> logger) : base(serviceScopeFactory) { _logger = logger; } protected override string Schedule => "*/10 * * * * *"; //Runs every 10 seconds public override Task ScheduledExecuteInScope(IServiceProvider serviceProvider, CancellationToken stoppingToken) { _logger.LogInformation("MyScheduledTask executing - {0}", DateTime.Now); return Task.CompletedTask; } }
روش معرفی آن به سیستم نیز مانند قبل است:
namespace MvcTest { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddHostedService<MyScheduledTask>();
D:\MvcTest>dotnet run Hosting environment: Development Content root path: D:\MvcTest Now listening on: https://localhost:5001 Now listening on: http://localhost:5000 Application started. Press Ctrl+C to shut down. info: MyScheduledTask[0] MyScheduledTask executing - 02/19/2019 19:18:50 info: MyScheduledTask[0] MyScheduledTask executing - 02/19/2019 19:19:00 info: MyScheduledTask[0] MyScheduledTask executing - 02/19/2019 19:19:10 Application is shutting down... ^C
dotnet add package linq2db.EntityFrameworkCore
LinqToDB.EntityFrameworkCore.LinqToDBForEFTools.Initialize(); LinqToDB.Data.DataConnection.TurnTraceSwitchOn();
var runningTotalCountForEachYear = context.Bookings .Select(booking => new { booking.StartTime.Year, RunningTotalCount = Sql.Ext.Count(booking.StartTime) .Over() .OrderBy(booking.StartTime.Year) .ToValue() }) .OrderBy(result => result.Year) .Distinct() .ToLinqToDB() .ToList();
SELECT DISTINCT DatePart(year, [booking].[StartTime]), COUNT([booking].[StartTime]) OVER(ORDER BY DatePart(year, [booking].[StartTime])) FROM [Bookings] [booking] ORDER BY DatePart(year, [booking].[StartTime])
یکی از ویژگیهای جدید EF Core 3.0، بازگشت مجدد Interceptorهایی است که در این مطلب در مورد آنها بحث شدهاست. اگر بخواهیم مطلب جاری را برای EF Core 3.0 بازنویسی کنیم، به کلاس زیر خواهیم رسید:
using System; using System.Data; using System.Data.Common; using System.Threading; using System.Threading.Tasks; using DNTPersianUtils.Core; // dotnet add package DNTPersianUtils.Core using Microsoft.EntityFrameworkCore.Diagnostics; namespace EFCore3Interceptors { public class PersianYeKeCommandInterceptor : DbCommandInterceptor { public override InterceptionResult<DbDataReader> ReaderExecuting( DbCommand command, CommandEventData eventData, InterceptionResult<DbDataReader> result) { ApplyCorrectYeKe(command); return result; } public override Task<InterceptionResult<DbDataReader>> ReaderExecutingAsync( DbCommand command, CommandEventData eventData, InterceptionResult<DbDataReader> result, CancellationToken cancellationToken = new CancellationToken()) { ApplyCorrectYeKe(command); return Task.FromResult(result); } public override InterceptionResult<int> NonQueryExecuting( DbCommand command, CommandEventData eventData, InterceptionResult<int> result) { ApplyCorrectYeKe(command); return result; } public override Task<InterceptionResult<int>> NonQueryExecutingAsync( DbCommand command, CommandEventData eventData, InterceptionResult<int> result, CancellationToken cancellationToken = new CancellationToken()) { ApplyCorrectYeKe(command); return Task.FromResult(result); } public override InterceptionResult<object> ScalarExecuting( DbCommand command, CommandEventData eventData, InterceptionResult<object> result) { ApplyCorrectYeKe(command); return result; } public override Task<InterceptionResult<object>> ScalarExecutingAsync( DbCommand command, CommandEventData eventData, InterceptionResult<object> result, CancellationToken cancellationToken = new CancellationToken()) { ApplyCorrectYeKe(command); return Task.FromResult(result); } private static void ApplyCorrectYeKe(DbCommand command) { command.CommandText = command.CommandText.ApplyCorrectYeKe(); foreach (DbParameter parameter in command.Parameters) { switch (parameter.DbType) { case DbType.AnsiString: case DbType.AnsiStringFixedLength: case DbType.String: case DbType.StringFixedLength: case DbType.Xml: parameter.Value = parameter.Value is DBNull ? parameter.Value : parameter.Value.ToString().ApplyCorrectYeKe(); break; } } } } }
و روش استفاده و معرفی آن به سیستم توسط متد AddInterceptors، به صورت زیر است:
namespace EFCore3Interceptors { public class BloggingContext : DbContext { // ... protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { if (!optionsBuilder.IsConfigured) { optionsBuilder .UseSqlServer("...") .AddInterceptors(new PersianYeKeCommandInterceptor()); } } } }
مقایسه تعریف سطوح دسترسی «مبتنی بر نقشها» با سطوح دسترسی «مبتنی بر سیاستهای امنیتی»
- در سطوح دسترسی «مبتنی بر نقشها»
یکسری نقش از پیش تعریف شده وجود دارند؛ مانند PayingUser و یا FreeUser که کاربر توسط هر نقش، به یکسری دسترسیهای خاص نائل میشود. برای مثال PayingUser میتواند نگارش قاب شدهی تصاویر را سفارش دهد و یا تصویری را به سیستم اضافه کند.
- در سطوح دسترسی «مبتنی بر سیاستهای امنیتی»
سطوح دسترسی بر اساس یک سری سیاست که بیانگر ترکیبی از منطقهای دسترسی هستند، اعطاء میشوند. این منطقها نیز از طریق ترکیب User Claims حاصل میشوند و میتوانند منطقهای پیچیدهتری را به همراه داشته باشند. برای مثال اگر کاربری از کشور A است و نوع اشتراک او B است و اگر در بین یک بازهی زمانی خاصی متولد شده باشد، میتواند به منبع خاصی دسترسی پیدا کند. به این ترتیب حتی میتوان نیاز به ترکیب چندین نقش را با تعریف یک سیاست امنیتی جدید جایگزین کرد. به همین جهت نسبت به روش بکارگیری مستقیم کار با نقشها ترجیح داده میشود.
جایگزین کردن بررسی سطوح دسترسی توسط نقشها با روش بکارگیری سیاستهای دسترسی
در ادامه میخواهیم بجای بکارگیری مستقیم نقشها جهت محدود کردن دسترسی به قسمتهای خاصی از برنامهی کلاینت، تنها کاربرانی که از کشور خاصی وارد شدهاند و نیز سطح اشتراک خاصی را دارند، بتوانند دسترسیهای ویژهای داشته باشند؛ چون برای مثال امکان ارسال مستقیم تصاویر قاب شده را به کشور دیگری نداریم.
تنظیم User Claims جدید در برنامهی IDP
برای تنظیم این سیاست امنیتی جدید، ابتدا دو claim جدید subscriptionlevel و country را به خواص کاربران در کلاس src\IDP\DNT.IDP\Config.cs در سطح IDP اضافه میکنیم:
namespace DNT.IDP { public static class Config { public static List<TestUser> GetUsers() { return new List<TestUser> { new TestUser { Username = "User 1", // ... Claims = new List<Claim> { // ... new Claim("subscriptionlevel", "PayingUser"), new Claim("country", "ir") } }, new TestUser { Username = "User 2", // ... Claims = new List<Claim> { // ... new Claim("subscriptionlevel", "FreeUser"), new Claim("country", "be") } } }; }
namespace DNT.IDP { public static class Config { // identity-related resources (scopes) public static IEnumerable<IdentityResource> GetIdentityResources() { return new List<IdentityResource> { // ... new IdentityResource( name: "country", displayName: "The country you're living in", claimTypes: new List<string> { "country" }), new IdentityResource( name: "subscriptionlevel", displayName: "Your subscription level", claimTypes: new List<string> { "subscriptionlevel" }) }; }
namespace DNT.IDP { public static class Config { public static IEnumerable<Client> GetClients() { return new List<Client> { new Client { ClientName = "Image Gallery", // ... AllowedScopes = { // ... "country", "subscriptionlevel" } // ... } }; } }
استفادهی از User Claims جدید در برنامهی MVC Client
در ادامه به کلاس ImageGallery.MvcClient.WebApp\Startup.cs برنامهی MVC Client مراجعه کرده و دو scope جدیدی را که در سمت IDP تعریف کردیم، در اینجا در تنظیمات متد AddOpenIdConnect، درخواست میدهیم:
options.Scope.Add("subscriptionlevel"); options.Scope.Add("country");
البته همانطور که در قسمتهای قبل نیز ذکر شد، اگر claim ای در لیست نگاشتهای تنظیمات میانافزار OpenID Connect مایکروسافت نباشد، آنرا در لیست this.User.Claims ظاهر نمیکند. به همین جهت همانند claim role که پیشتر MapUniqueJsonKey را برای آن تعریف کردیم، نیاز است برای این دو claim نیز نگاشتهای لازم را به سیستم افزود:
options.ClaimActions.MapUniqueJsonKey(claimType: "role", jsonKey: "role"); options.ClaimActions.MapUniqueJsonKey(claimType: "subscriptionlevel", jsonKey: "subscriptionlevel"); options.ClaimActions.MapUniqueJsonKey(claimType: "country", jsonKey: "country");
ایجاد سیاستهای دسترسی در برنامهی MVC Client
برای تعریف یک سیاست دسترسی جدید در کلاس ImageGallery.MvcClient.WebApp\Startup.cs برنامهی MVC Client، به متد ConfigureServices آن مراجعه کرده و آنرا به صورت زیر تکمیل میکنیم:
namespace ImageGallery.MvcClient.WebApp { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddAuthorization(options => { options.AddPolicy( name: "CanOrderFrame", configurePolicy: policyBuilder => { policyBuilder.RequireAuthenticatedUser(); policyBuilder.RequireClaim(claimType: "country", requiredValues: "ir"); policyBuilder.RequireClaim(claimType: "subscriptionlevel", requiredValues: "PayingUser"); }); });
به علاوه policyBuilder شامل متد RequireRole نیز هست. به همین جهت است که این روش تعریف سطوح دسترسی، روش قدیمی مبتنی بر نقشها را جایگزین کرده و در برگیرندهی آن نیز میشود؛ چون در این سیستم، role نیز تنها یک claim است، مانند country و یا subscriptionlevel فوق.
بررسی نحوهی استفادهی از Authorization Policy تعریف شده و جایگزین کردن آن با روش بررسی نقشها
تا کنون از روش بررسی سطوح دسترسیها بر اساس نقشهای کاربران در دو قسمت استفاده کردهایم:
الف) اصلاح Views\Shared\_Layout.cshtml برای استفادهی از Authorization Policy
در فایل Layout با بررسی نقش PayingUser، منوهای مرتبط با این نقش را فعال میکنیم:
@if(User.IsInRole("PayingUser")) { <li><a asp-area="" asp-controller="Gallery" asp-action="AddImage">Add an image</a></li> <li><a asp-area="" asp-controller="Gallery" asp-action="OrderFrame">Order a framed picture</a></li> }
@using Microsoft.AspNetCore.Authorization @inject IAuthorizationService AuthorizationService
@if (User.IsInRole("PayingUser")) { <li><a asp-area="" asp-controller="Gallery" asp-action="AddImage">Add an image</a></li> } @if ((await AuthorizationService.AuthorizeAsync(User, "CanOrderFrame")).Succeeded) { <li><a asp-area="" asp-controller="Gallery" asp-action="OrderFrame">Order a framed picture</a></li> }
ب) اصلاح کنترلر ImageGallery.MvcClient.WebApp\Controllers\GalleryController.cs برای استفادهی از Authorization Policy
namespace ImageGallery.MvcClient.WebApp.Controllers { [Authorize] public class GalleryController : Controller { [Authorize(Policy = "CanOrderFrame")] public async Task<IActionResult> OrderFrame() {
اکنون برای آزمایش برنامه یکبار از آن خارج شده و سپس توسط اکانت User 1 که از نوع PayingUser در کشور ir است، به آن وارد شوید.
ابتدا به قسمت IdentityInformation آن وارد شوید. در اینجا لیست claims جدید را میتوانید مشاهده کنید. همچنین لینک سفارش تصویر قاب شده نیز نمایان است و میتوان به آدرس آن نیز وارد شد.
استفاده از سیاستهای دسترسی در سطح برنامهی Web API
در سمت برنامهی Web API، در حال حاضر کاربران میتوانند به متدهای Get ،Put و Delete ای که رکوردهای آنها الزاما متعلق به آنها نیست دسترسی داشته باشند. بنابراین نیاز است از ورود کاربران به متدهای تغییرات رکوردهایی که OwnerID آنها با هویت کاربری آنها تطابقی ندارد، جلوگیری کرد. در این حالت Authorization Policy تعریف شده نیاز دارد تا با سرویس کاربران و بانک اطلاعاتی کار کند. همچنین نیاز به دسترسی به اطلاعات مسیریابی جاری را برای دریافت ImageId دارد. پیاده سازی یک چنین سیاست دسترسی پیچیدهای توسط متدهای RequireClaim و RequireRole میسر نیست. خوشبختانه امکان بسط سیستم Authorization Policy با پیاده سازی یک IAuthorizationRequirement سفارشی وجود دارد. RequireClaim و RequireRole، جزو Authorization Requirementهای پیشفرض و توکار هستند. اما میتوان نمونههای سفارشی آنها را نیز پیاده سازی کرد:
using System; using System.Linq; using System.Threading.Tasks; using Microsoft.AspNetCore.Authorization; using Microsoft.AspNetCore.Mvc.Filters; using Microsoft.Extensions.Logging; namespace ImageGallery.WebApi.Services { public class MustOwnImageRequirement : IAuthorizationRequirement { } public class MustOwnImageHandler : AuthorizationHandler<MustOwnImageRequirement> { private readonly IImagesService _imagesService; private readonly ILogger<MustOwnImageHandler> _logger; public MustOwnImageHandler( IImagesService imagesService, ILogger<MustOwnImageHandler> logger) { _imagesService = imagesService; _logger = logger; } protected override async Task HandleRequirementAsync( AuthorizationHandlerContext context, MustOwnImageRequirement requirement) { var filterContext = context.Resource as AuthorizationFilterContext; if (filterContext == null) { context.Fail(); return; } var imageId = filterContext.RouteData.Values["id"].ToString(); if (!Guid.TryParse(imageId, out Guid imageIdAsGuid)) { _logger.LogError($"`{imageId}` is not a Guid."); context.Fail(); return; } var subClaim = context.User.Claims.FirstOrDefault(c => c.Type == "sub"); if (subClaim == null) { _logger.LogError($"User.Claims don't have the `sub` claim."); context.Fail(); return; } var ownerId = subClaim.Value; if (!await _imagesService.IsImageOwnerAsync(imageIdAsGuid, ownerId)) { _logger.LogError($"`{ownerId}` is not the owner of `{imageIdAsGuid}` image."); context.Fail(); return; } // all checks out context.Succeed(requirement); } } }
<Project Sdk="Microsoft.NET.Sdk"> <ItemGroup> <PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.1.0" /> <PackageReference Include="Microsoft.AspNetCore.Authorization" Version="2.1.1.0" /> <PackageReference Include="Microsoft.AspNetCore.Mvc.Abstractions" Version="2.1.1.0" /> </ItemGroup> </Project>
پیاده سازی سیاستهای پویای دسترسی شامل مراحل ذیل است:
1- تعریف یک نیازمندی دسترسی جدید
public class MustOwnImageRequirement : IAuthorizationRequirement { }
2- پیاده سازی یک AuthorizationHandler استفاده کنندهی از نیازمندی دسترسی تعریف شده
که کدهای کامل آنرا در کلاس MustOwnImageHandler مشاهده میکنید. کار آن با ارث بری از AuthorizationHandler شروع شده و آرگومان جنریک آن، همان نیازمندی است که پیشتر تعریف کردیم. از این آرگومان جنریک جهت یافتن خودکار AuthorizationHandler متناظر با آن توسط ASP.NET Core استفاده میشود. بنابراین در اینجا MustOwnImageRequirement تهیه شده صرفا کارکرد علامتگذاری را دارد.
در کلاس تهیه شده باید متد HandleRequirementAsync آنرا بازنویسی کرد و اگر در این بین، منطق سفارشی ما context.Succeed را فراخوانی کند، به معنای برآورده شدن سیاست دسترسی بوده و کاربر جاری میتواند به منبع درخواستی بلافاصله دسترسی یابد و اگر context.Fail فراخوانی شود، در همینجا دسترسی کاربر قطع شده و HTTP status code مساوی 401 (عدم دسترسی) را دریافت میکند.
در این پیاده سازی از filterContext.RouteData برای یافتن Id تصویر مورد نظر استفاده شدهاست. همچنین Id شخص جاری نیز از sub claim موجود استخراج گردیدهاست. اکنون این اطلاعات را به سرویس تصاویر ارسال میکنیم تا توسط متد IsImageOwnerAsync آن مشخص شود که آیا کاربر جاری سیستم، همان کاربری است که تصویر را در بانک اطلاعاتی ثبت کردهاست؟ اگر بله، با فراخوانی context.Succeed به سیستم Authorization اعلام خواهیم کرد که این سیاست دسترسی و نیازمندی مرتبط با آن با موفقیت پشت سر گذاشته شدهاست.
3- معرفی سیاست دسترسی پویای تهیه شده به سیستم
معرفی سیاست کاری پویا و سفارشی تهیه شده، شامل دو مرحلهی زیر است:
مراجعهی به کلاس ImageGallery.WebApi.WebApp\Startup.cs و افزودن نیازمندی آن:
namespace ImageGallery.WebApi.WebApp { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddAuthorization(authorizationOptions => { authorizationOptions.AddPolicy( name: "MustOwnImage", configurePolicy: policyBuilder => { policyBuilder.RequireAuthenticatedUser(); policyBuilder.AddRequirements(new MustOwnImageRequirement()); }); }); services.AddScoped<IAuthorizationHandler, MustOwnImageHandler>();
سپس یک Policy جدید را با نام دلخواه MustOwnImage تعریف کرده و نیازمندی علامتگذار خود را به عنوان یک policy.Requirements جدید، اضافه میکنیم. همانطور که ملاحظه میکنید یک وهلهی جدید از MustOwnImageRequirement در اینجا ثبت شدهاست. همین وهله به متد HandleRequirementAsync نیز ارسال میشود. بنابراین اگر نیاز به ارسال پارامترهای بیشتری به این متد وجود داشت، میتوان خواص مرتبطی را به کلاس MustOwnImageRequirement نیز اضافه کرد.
همانطور که مشخص است، در اینجا یک نیازمندی را میتوان ثبت کرد و نه Handler آنرا. این Handler از سیستم تزریق وابستگیها بر اساس آرگومان جنریک AuthorizationHandler پیاده سازی شده، به صورت خودکار یافت شده و اجرا میشود (بنابراین اگر Handler شما اجرا نشد، مطمئن شوید که حتما آنرا به سیستم تزریق وابستگیها معرفی کردهاید).
پس از آن هر کنترلر یا اکشن متدی که از این سیاست دسترسی پویای تهیه شده استفاده کند:
[Authorize(Policy ="MustOwnImage")]
اعمال سیاست دسترسی پویای تعریف شده به Web API
پس از تعریف سیاست دسترسی MustOwnImage که پویا عمل میکند، اکنون نوبت به استفادهی از آن در کنترلر ImageGallery.WebApi.WebApp\Controllers\ImagesController.cs است:
namespace ImageGallery.WebApi.WebApp.Controllers { [Route("api/images")] [Authorize] public class ImagesController : Controller { [HttpGet("{id}", Name = "GetImage")] [Authorize("MustOwnImage")] public async Task<IActionResult> GetImage(Guid id) { } [HttpDelete("{id}")] [Authorize("MustOwnImage")] public async Task<IActionResult> DeleteImage(Guid id) { } [HttpPut("{id}")] [Authorize("MustOwnImage")] public async Task<IActionResult> UpdateImage(Guid id, [FromBody] ImageForUpdateModel imageForUpdate) { } } }
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید.
برای اجرای برنامه:
- ابتدا به پوشهی src\WebApi\ImageGallery.WebApi.WebApp وارد شده و dotnet_run.bat آنرا اجرا کنید تا WebAPI برنامه راه اندازی شود.
- سپس به پوشهی src\IDP\DNT.IDP مراجعه کرده و و dotnet_run.bat آنرا اجرا کنید تا برنامهی IDP راه اندازی شود.
- در آخر به پوشهی src\MvcClient\ImageGallery.MvcClient.WebApp وارد شده و dotnet_run.bat آنرا اجرا کنید تا MVC Client راه اندازی شود.
اکنون که هر سه برنامه در حال اجرا هستند، مرورگر را گشوده و مسیر https://localhost:5001 را درخواست کنید. در صفحهی login نام کاربری را User 1 و کلمهی عبور آنرا password وارد کنید.
- معماری لایه ای
- استفاده از جدیدترین نسخه ASP.NET Identity
- به روز رسانی لایه IocConfig برای یک برنامه ASP.NET Core با توجه به بخش روش تعویض IoC Container توکار ASP.NET Core با StructureMap و https://github.com/structuremap/StructureMap.Microsoft.DependencyInjection جهت استفاده از تنظیمات StructureMap در یک لایه مجزا (IocConfig) با کانفیگهای مختص برای آخرین نگارش MVC و Web API و SignalR و Entity Framework .
به روز رسانی وابستگیهای VS.NET
برای دریافت آخرین نگارش TypeScript نیاز است افزونههای آنرا از سایت رسمی زبان TypeScript دریافت و نصب کرد:
به علاوه نصب افزونهی Web Essentials نیز جهت تکمیل امکانات کار با TypeScript مانند امکان مشاهدهی خروجی جاوا اسکریپت تولیدی، در حین کار با فایل TypeScript فعلی توصیه میشود. همچنین TSLint را نیز نصب میکند.
افزودن فایل تنظیمات tslint
افزونهی Web Essentials که Web Analyzer نیز اکنون جزئی از آن است، به همراه TSLint هم هست که کار آن ارائه راهنماهایی جهت تولید کدهای با کیفیت TypeScript است. گزینههای آنرا در منوی Tools -> Options میتوانید مشاهده کنید:
برای بازنویسی تنظیمات آن (در صورت نیاز) فایل جدیدی را به نام tslint.json به ریشهی پروژه (کنار فایل web.config) اضافه کنید. فایل پیش فرض آن چنین شکلی را دارد:
settings-defaults/tslint.json
و یک نمونهی اصلاح شدهی آن به صورت ذیل است که میتواند به ریشهی پروژه کپی شود:
tslint.json
تنظیمات کامپایلر TypeScript در VS.NET
هرچند قالب افزودن یک پروژهی جدید TypeScript نیز به همراه نصب بستههای TypeScript به لیست پروژههای موجود اضافه میشود، اما عموما نیاز است تا فایلهای ts. را به یک پروژهی وب موجود اضافه کرد. بنابراین، یک پوشهی جدید را به برای مثال به نام TypeScript ایجاد کرده و بر روی آن کلیک راست کنید. سپس گزینهی Add->new item را انتخاب کرده و در اینجا TypeScript را جستجو کنید:
پس از اضافه شدن اولین فایل ts. به پروژه، دیالوگ زیر نیز ظاهر خواهد شد:
در اینجا جستجوی فایلهای d.ts. را پیشنهاد میدهد. فعلا بر روی No کلیک کنید. اینکار را در ادامه انجام خواهیم داد.
پس از افزودن اولین فایل ts. به پروژه، اگر به خواص پروژهی جاری مراجعه کنید، برگهی جدید تنظیمات کامپایلر TypeScript را مشاهده خواهید کرد:
با این تنظیمات در مطلب «تنظیمات کامپایلر TypeScript» پیشتر آشنا شدهاید. برای مثال فرمت خروجی جاوا اسکریپت آن ES 5 باشد و یا در اینجا نوعهای any که به صورت صریح any تعریف نشدهاند، ممنوع شدهاست (تیک پیش فرض آنرا بردارید). نوع ماژولهای تولیدی نیز به commonjs تنظیم شدهاست.
همچنین در اینجا میتوانید گزینهی redirect JavaScript output to directory را هم مثلا به پوشهی Scripts واقع در ریشهی پروژه تنظیم کنید تا فایلهای js. نهایی را در آنجا قرار دهد.
پس از این تنظیمات اولیه، به منوی tools->options مراجعه کرده و گزینهی کامپایل فایلهای ts. ایی را که به solution explorer اضافه نشدهاند، نیز فعال کنید:
اعمال این تنظیمات نیاز به یکبار بستن و گشودن مجدد پروژه را دارد.
فعال سازی کامپایل خودکار فایلهای ts. پس از ذخیرهی آنها
پس از اعمال تغییرات فوق، اگر فایل ts. ایی را تغییر داده و ذخیره کردید و بلافاصله خروجی js. آنرا مشاهده نکردید (این فایلها در پوشهی TypeScriptOutDir تنظیمات ذیل ذخیره میشوند و برای مشاهدهی آنها باید گزینهی show all files را در solution explorer فعال کنید)، فایل csproj پروژهی جاری را در یک ادیتور متنی باز کرده و مداخل تنظیمات تنظیم شدهی در قسمت قبل را پیدا کنید. در اینجا نیاز است مدخل جدید TypeScriptCompileOnSaveEnabled را به صورت دستی اضافه کنید:
<PropertyGroup Condition="'$(Configuration)' == 'Debug'"> <TypeScriptModuleKind>commonjs</TypeScriptModuleKind> <TypeScriptCompileOnSaveEnabled>True</TypeScriptCompileOnSaveEnabled> <TypeScriptOutDir>.\Scripts</TypeScriptOutDir> <TypeScriptNoImplicitAny>True</TypeScriptNoImplicitAny> <TypeScriptTarget>ES5</TypeScriptTarget> <TypeScriptRemoveComments>false</TypeScriptRemoveComments> <TypeScriptOutFile></TypeScriptOutFile> <TypeScriptGeneratesDeclarations>false</TypeScriptGeneratesDeclarations> <TypeScriptSourceMap>true</TypeScriptSourceMap> <TypeScriptMapRoot></TypeScriptMapRoot> <TypeScriptSourceRoot></TypeScriptSourceRoot> <TypeScriptNoEmitOnError>true</TypeScriptNoEmitOnError> </PropertyGroup>
رفع مشکل عدم کامپایل پروژه
زمانیکه افزونههای TypeScript را نصب کنید و تنظیمات فوق را اعمال نمائید، در دو حالت ذخیرهی یک فایل ts و یا کامپایل کل پروژه، فایلهای js تولید خواهند شد. اما ممکن است نگارش نصب شدهی بر روی سیستم شما ناقص باشد و چنین خطایی را در حین کامپایل پروژه دریافت کنید:
Your project file uses a different version of the TypeScript compiler and tools than is currently installed on this machine. No compiler was found at C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.8\tsc.exe. You may be able to fix this problem by changing the <TypeScriptToolsVersion> element in your project file.
الف) ابتدا به تمام مسیرهای ذیل (در صورت وجود) مراجعه کرده و پوشهی TypeScript را تغییر نام دهید (یا کلا آنرا حذف کنید):
C:\Program Files (x86)\Microsoft SDKs C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\ C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\ C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\
اصلاح شماره نگارش کامپایلر TypeScript خط فرمان ویژوال استودیو
در فایل C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\VsDevCmd.bat که مربوط به خط فرمان VS.NET است، شماره نگارش TypeScript به 1.5 تنظیم شدهاست که نیاز به اصلاح دستی دارد؛ برای مثال تنظیم آن به نگارش 1.8 به صورت زیر است:
@rem Add path to TypeScript Compiler @if exist "%ProgramFiles%\Microsoft SDKs\TypeScript\1.8" set PATH=%ProgramFiles%\Microsoft SDKs\TypeScript\1.8;%PATH% @if exist "%ProgramFiles(x86)%\Microsoft SDKs\TypeScript\1.8" set PATH=%ProgramFiles(x86)%\Microsoft SDKs\TypeScript\1.8;%PATH%
تداخل ReSharper با شماره نگارش TypeScript نصب شده
برای نمونه اگر بخواهیم از decorators استفاده کنیم، یک چنین خطایی نمایش داده میشود:
هرچند در ابتدای بحث، آخرین نگارش TypeScript برای دریافت معرفی شدهاست، اما پس از نصب آن، ممکن است هنوز خطای استفاده از نگارش قدیمی 1.4 را مشاهده کنید. علت آن به نصب بودن ReSharper بر میگردد:
به منوی ReSharper و سپس گزینهی Options آن مراجعه کنید.
ReSharper -> Options -> Code Editing -> TypeScript -> Inspections -> Typescript language level
در اینجا میتوان نگارش TypeScript مورد استفاده را تغییر داد. این شمارهها، نگارشهایی هستند که ReSharper از آنها پشتیبانی میکند و نه شمارهای که نصب شدهاست.
و یا حتی میتوان به صورت کامل فایلهای ts را از کنترل ReSharper خارج کرد:
Tools -> Options -> ReSharper Options -> Code Inspection -> Settings -> File Masks to Skip -> add *.ts
افزودن فایل tsconfig.json به پروژه
همانطور که در مطلب «تنظیمات کامپایلر TypeScript» نیز مطالعه کردید، روش دیگری نیز برای ذکر تنظیمات ویژهی کامپایلر، خصوصا مواردی که در برگهی خواص پروژه هنوز اضافه نشدهاند، با استفاده از افزودن فایل ویژهی tsconfig.json وجود دارد.
پشتیبانی کاملی از فایلهای tsconfig.json در پروژههای VS 2015 با ASP.Core 1.0 وجود دارد و حتی گزینهای در منوی add->new item برای آن درنظر گرفته شدهاست.
اگر گزینهی فوق را در لیست موارد add->new item پیدا نمیکنید (تحت عنوان TypeScript JSON Configuration File)، مهم نیست. تنها کافی است فایل جدیدی را به نام tsconfig.json به ریشهی پوشهی فایلهای ts خود اضافه کنید؛ با این محتوا:
{ "compilerOptions": { "target": "es5", "outDir": "../Scripts", "module": "commonjs", "sourceMap": true, //"watch": true, // JsErrorScriptException (0x30001) //"compileOnSave": true, // https://github.com/Microsoft/TypeScript/issues/7362#issuecomment-196586037 "experimentalDecorators": true, "emitDecoratorMetadata": true } }
در اینجا نیازی به استفاده از گزینهی watch نیست و ممکن است سبب بروز خطای JsErrorScriptException (0x30001) شود. قرار است این مشکل در نگارشهای بعدی افزونهی TypeScript مخصوص VS.NET برطرف شود.
افزودن فایلهای d.ts. از طریق نیوگت
به ازای هر کتابخانهی جاوا اسکریپتی معروف، یک بستهی نیوگت تعاریف نوعهای TypeScript آن هم وجود دارد.
یک مثال: فرض کنید میخواهیم فایل d.ts. کتابخانهی jQuery را اضافه کنیم. برای این منظور jquery.typescript را در بین بستههای نیوگت موجود، جستجو کنید:
برای سایر کتابخانهها نیز به همین صورت است. نام کتابخانه را به همراه typescript جستجو کنید.
{ "type": "https://example.com/probs/out-of-credit", "title": "You do not have enough credit.", "detail": "Your current balance is 30, but that costs 50.", "instance": "/account/12345/msgs/abc", "status": 403, }
ProblemDetails بر اساس RFC7807 طراحی شدهاست
RFC7807، قالب استانداردی را برای ارائهی خطاهای HTTP APIها تعریف میکند تا نیازی به وجود تعاریف متعددی در این زمینه نباشد و خروجی آن قابل پیشبینی و قابل بررسی توسط تمام کلاینتهای یک API باشد. کلاس ProblemDetails در ASP.NET Core نیز بر همین اساس طراحی شدهاست.
این RFC دو فرمت خروجی را بر اساس مقدار مشخص شدهی در هدر Content-Type بازگشت داده شده، مجاز میداند:
- JSON: “application/problem+json” media type
- XML: “application/problem+xml” media type
که با توجه به این هدر ارسالی، اگر از یک کلاینت از نوع HttpClient استفاده کنیم، میتوان بر اساس مقدار ویژهی «application/problem+json» تشخیص داد که خروجی API دریافتی، به همراه خطا است و نحوهی پردازش آن به صورت زیر خواهد بود:
var mediaType = response.Content.Headers.ContentType?.MediaType; if (mediaType != null && mediaType.Equals("application/problem+json", StringComparison.InvariantCultureIgnoreCase)) { var problemDetails = await response.Content.ReadFromJsonAsync<ProblemDetails>(null, ct) ?? new ProblemDetails(); // ... }
- type: یک رشتهاست که به آدرس مستندات HTML ای مرتبط با خطای بازگشت داده شده، اشاره میکند.
- title: رشتهای است که خلاصهی خطای رخداده را بیان میکند.
- detail: رشتهای است که توضیحات بیشتری را در مورد خطای رخداده، بیان میکند.
- instance: رشتهای است که به آدرس محل بروز خطا اشاره میکند.
- status: عددی است که بیانگر HTTP status code بازگشتی از سمت سرور است.
البته اگر ویژگی ApiController بر روی کنترلرهای خود استفاده نمیکنید، میتوانید این خروجی را به صورت زیر هم با استفاده از return Problem، تولید کنید:
[HttpPost("/sales/products/{sku}/availableForSale")] public async Task<IActionResult> AvailableForSale([FromRoute] string sku) { return Problem( "Product is already Available For Sale.", "/sales/products/1/availableForSale", 400, "Cannot set product as available.", "http://example.com/problems/already-available"); }
امکان بسط این خروجی، با افزودن اعضای سفارشی نیز پیشبینی شدهاست. یک نمونهی متداول و پرکاربرد آن، بازگشت خطاهای مرتبط با اعتبارسنجی اطلاعات رسیدهاست:
HTTP/1.1 400 Bad Request Content-Type: application/problem+json Content-Language: en { "type": "https://tools.ietf.org/html/rfc7231#section-6.5.1", "title": "One or more validation errors occurred.", "status": 400, "errors": { "User": [ "The user name is not verified." ] } }
جهت افزودن اعضای سفارشی دیگری به شیء ProblemDetails میتوان به صورت زیر عمل کرد:
namespace WebApplication.Controllers { [ApiController] [Route("[controller]")] public class DemoController : ControllerBase { [HttpPost] public ActionResult Post() { var problemDetails = new ProblemDetails { Detail = "The request parameters failed to validate.", Instance = null, Status = 400, Title = "Validation Error", Type = "https://example.net/validation-error", }; problemDetails.Extensions.Add("invalidParams", new List<ValidationProblemDetailsParam>() { new("name", "Cannot be blank."), new("age", "Must be great or equals to 18.") }); return new ObjectResult(problemDetails) { StatusCode = 400 }; } } public class ValidationProblemDetailsParam { public ValidationProblemDetailsParam(string name, string reason) { Name = name; Reason = reason; } public string Name { get; set; } public string Reason { get; set; } } }
معرفی سرویس جدید ProblemDetails در دات نت 7
در دات نت 7 میتوان سرویسهای جدید ProblemDetails را به نحو زیر به برنامه اضافه کرد:
services.AddProblemDetails();
الف) با اضافه کردن میانافزار مدیریت خطاها
app.UseExceptionHandler();
ب) با افزودن میانافزار StatusCodePages
app.UseStatusCodePages();
ج) با افزودن میانافزار صفحهی استثناءهای توسعه دهندهها
app.UseDeveloperExceptionPage();
امکان بازگشت سادهتر یک ProblemDetails سفارشی در دات نت 7
برای سفارشی سازی خروجی ProblemDetails، علاوه بر راهحلی که پیشتر در این مطلب مطرح شد، میتوان در دات نت 7 از روش تکمیلی ذیل نیز استفاده کرد:
builder.Services.AddProblemDetails(options => options.CustomizeProblemDetails = ctx => ctx.ProblemDetails.Extensions.Add("MachineName", Environment.MachineName));
الف) تعریف یک ErrorFeature سفارشی
public class MyErrorFeature { public ErrorType Error { get; set; } } public enum ErrorType { ArgumentException }
ب) تنظیم مقدار ErrorFeature سفارشی در اکشن متدها
[HttpGet("{value}")] public IActionResult MyErrorTest(int value) { if (value <= 0) { var errorType = new MyErrorFeature { Error = ErrorType.ArgumentException }; HttpContext.Features.Set(errorType); return BadRequest(); } return Ok(value); }
ج) واکنش نشان دادن به دریافت ErrorFeature سفارشی
services.AddProblemDetails(options => options.CustomizeProblemDetails = ctx => { var MyErrorFeature = ctx.HttpContext.Features.Get<MyErrorFeature>(); if (MyErrorFeature is not null) { (string Title, string Detail, string Type) details = MyErrorFeature.Error switch { ErrorType.ArgumentException => ( nameof(ArgumentException), "This is an argument-exception.", "https://www.rfc-editor.org/rfc/rfc7231#section-6.5.1" ), _ => ( nameof(Exception), "default-exception", "https://www.rfc-editor.org/rfc/rfc7231#section-6.6.1" ) }; ctx.ProblemDetails.Title = details.Title; ctx.ProblemDetails.Detail = details.Detail; ctx.ProblemDetails.Type = details.Type; } } );
امکان تبدیل سادهتر اطلاعات استثناءهای سفارشی به یک ProblemDetails سفارشی در دات نت 7
بجای استفاده از تنظیمات services.AddProblemDetails جهت بازنویسی مقدار شیء ProblemDetails بازگشتی، میتوان جزئیات میانافزار app.UseExceptionHandler را نیز سفارشی سازی کرد و به بروز استثناءهای خاصی واکنش نشان داد. برای مثال فرض کنید یک استثنای سفارشی را به صورت زیر طراحی کردهاید:
public class MyCustomException : Exception { public MyCustomException( string message, HttpStatusCode statusCode = HttpStatusCode.BadRequest ) : base(message) { StatusCode = statusCode; } public HttpStatusCode StatusCode { get; } }
[HttpGet("{value}")] public IActionResult MyErrorTest(int value) { if (value <= 0) { throw new MyCustomException("The value should be positive!"); } return Ok(value); }
app.UseExceptionHandler(exceptionHandlerApp => { exceptionHandlerApp.Run(async context => { context.Response.ContentType = "application/problem+json"; if (context.RequestServices.GetService<IProblemDetailsService>() is { } problemDetailsService) { var exceptionHandlerFeature = context.Features.Get<IExceptionHandlerFeature>(); var exceptionType = exceptionHandlerFeature?.Error; if (exceptionType is not null) { (string Title, string Detail, string Type, int StatusCode) details = exceptionType switch { MyCustomException MyCustomException => ( exceptionType.GetType().Name, exceptionType.Message, "https://www.rfc-editor.org/rfc/rfc7231#section-6.5.1", context.Response.StatusCode = (int)MyCustomException.StatusCode ), _ => ( exceptionType.GetType().Name, exceptionType.Message, "https://www.rfc-editor.org/rfc/rfc7231#section-6.6.1", context.Response.StatusCode = StatusCodes.Status500InternalServerError ) }; await problemDetailsService.WriteAsync(new ProblemDetailsContext { HttpContext = context, ProblemDetails = { Title = details.Title, Detail = details.Detail, Type = details.Type, Status = details.StatusCode } }); } } }); });