مطالب
آزمایش Web APIs توسط Postman - قسمت هفتم - استفاده از خروجی OpenAPI Swagger در Postman
در سری «OpenAPI Swagger» با نحوه‌ی مستندسازی یک Web API و همچنین آزمایش دستی اجزای آن به کمک Swagger-UI که رابط کاربری ایجاد شده‌ای بر اساس خروجی Open API است، آشنا شدیم. بنابراین اگر می‌توان رابط کاربری خودکاری را بر اساس OpenAPI Spec ایجاد کرد، به این معنا است که تمام اطلاعات لازم جهت انجام اینکار، هم اکنون در آن قرار دارد. در ادامه قصد داریم تعامل دستی با Swagger-UI را جهت آزمایش Web API، به Postman منتقل کرده تا اجرای مجموعه‌ای از آن‌ها را توسط Collection Runner، خودکار کنیم.


ساخت و ایجاد درخواست‌های Postman به کمک خروجی OpenAPI

در اینجا از همان برنامه‌ای که در سری «مستند سازی ASP.NET Core 2x API توسط OpenAPI Swagger» بررسی کردیم، استفاده خواهیم کرد. بنابراین، این برنامه از پیش تنظیم شده‌است و هم اکنون به همراه یک تولید کننده‌ی OpenAPI Specification نیز می‌باشد. آن‌را اجرا کنید تا بتوان به OpenAPI Specification تولیدی آن در آدرس زیر دسترسی یافت:
https://localhost:5001/swagger/LibraryOpenAPISpecification/swagger.json
سپس برنامه‌ی Postman را گشوده و از منوی File، گزینه‌ی Import آن‌را انتخاب کنید:


در برگه‌ی Import from link آن، همان URL فوق را که به خروجی OpenAPI Spec اشاره می‌کند، وارد کنید. اکنون با کلیک بر روی دکمه‌ی Import، یک مجموعه‌ی جدید، به نام Library API، به لیست مجموعه‌های Postman، اضافه می‌شود:


Postman تمام این اطلاعات را به صورت خودکار از OpenAPI Spec استخراج کرده‌است. تمام نام‌ها نیز بر اساس توضیحاتی که برای متدها نوشته‌ایم، انتخاب شده‌اند.


ارسال اولین درخواست به Web API

در اینجا برای نمونه اگر درخواست «Get list of authors» را انتخاب کنیم، یک چنین خروجی ظاهر می‌شود:


همانطور که مشاهده می‌کنید، متغیر {{baseUrl}} را جهت تنظیم آدرس پایه‌ی Web API انتخاب کرده‌است. این نکته در مطلب «قسمت پنجم - انواع متغیرهای قابل تعریف در Postman» بیشتر بحث شده‌است. هدف از تعریف متغیر {{baseUrl}} به این شکل در اینجا، امکان تعریف آن به صورت یک متغیر محیطی است تا بتوان آن‌را به سادگی بر اساس محیط‌های مختلفی که تعریف و انتخاب می‌کنیم، تغییر داد؛ بدون اینکه نیازی باشد اصل درخواست‌های تعریف شده، تغییری کنند. بنابراین در ادامه نیاز است یک محیط جدید را تعریف کنیم.
برای تعریف یک محیط جدید می‌توان بر روی دکمه‌‌ای با آیکن چشم، در بالای سمت راست صفحه و کلیک بر روی گزینه‌ی Add آن، یک محیط جدید را ایجاد کرد:


در صفحه‌ی باز شده ابتدا باید نامی را برای این محیط جدید انتخاب کرد و سپس می‌توان key/valueهایی را مخصوص این محیط، تعریف نمود:


ابتدا یک نام دلخواه وارد شده‌است و سپس متغیر محیطی baseUrl را با مقدار اولیه‌ی https://localhost:5001 تنظیم کرده‌ایم. پس از آن با کلیک بر روی Add پایین این صفحه، کار تعریف این محیط جدید به پایان می‌رسد.

مرحله‌ی بعد، انتخاب این محیط تعریف شده، به عنوان محیط کاری جاری است:


پس از این انتخاب، اگر اشاره‌گر ماوس را به متغیر baseUrl نزدیک کنیم، می‌توان مقدار تنظیم شده‌ی آن‌را مشاهده کرد:


اکنون اگر بر روی دکمه‌ی send این درخواست کلیک کنیم، چنین خروجی ظاهر می‌شود:


علت آن‌را می‌توان در برگه‌ی Authorization درخواست جاری مشاهده کرد:


همانطور که در مطلب «قسمت ششم - یک مثال تکمیلی: تبدیل رابط کاربری مثال JWT به یک مجموعه‌ی Postman» نیز مشاهده کردیم، برای تعریف هدرهای Authorization یا می‌توان به برگه‌ی هدرهای درخواست جاری مراجعه کرد و این هدرها را دستی تولید کرد و یا می‌توان با استفاده از برگه‌ی Authorization آن، کار تعریف این هدرها را ساده نمود. برای مثال در اینجا Postman بر اساس خروجی OpenAPI، دقیقا تشخیص داده‌است که این Web API از Basic authentication استفاده می‌کند. به همین جهت فیلدهای ورود نام کاربری و کلمه‌ی عبور را علاوه بر نوع اعتبارسنجی از پیش انتخاب شده، تدارک دیده‌است.
برای اینکه این مقادیر را نیز تبدیل به متغیرهای محیطی کنیم، برای ویرایش اطلاعات منتسب به محیط جاری، ابتدا باید آن‌را از dropdown محیط‌های بالای صفحه انتخاب کرد. اکنون با کلیک بر روی دکمه‌‌ای با آیکن چشم، در بالای سمت راست صفحه، لینک ویرایش این محیط انتخاب شده ظاهر می‌شود. با کلیک بر روی آن، می‌توان دو متغیر محیطی جدید را تعریف کرد:


پس از تعریف متغیرهای محیطی {{username}} و {{password}}، آن‌ها را در قسمت Authorization درخواست جاری استفاده می‌کنیم:


اینبار اگر مجددا بر روی دکمه‌ی Send کلیک کنیم، خروجی ذیل حاصل خواهد شد:


 
مسیرراه‌ها
React 16x
پیش نیاز ها
کامپوننت ها
ترکیب کامپوننت ها
طراحی یک گرید
مسیریابی 
کار با فرم ها
ارتباط با سرور
احراز هویت و اعتبارسنجی کاربران 
React Hooks  
توزیع برنامه

مدیریت پیشرفته‌ی حالت در React با Redux و Mobx   

       Redux
       MobX  

مطالب تکمیلی 
    مطالب
    امن سازی برنامه‌های ASP.NET Core توسط IdentityServer 4x - قسمت هشتم- تعریف سطوح دسترسی پیچیده
    تعریف نقش‌ها، ساده‌ترین روش محدود کردن دسترسی به منابع است؛ برای نمونه مشخص می‌کنیم که کاربران دارای نقش PayingUser، امکان سفارش دادن نگارش قاب شده‌ی تصاویر را داشته باشند. اما می‌خواهیم منطق دسترسی به منابع مختلف را پیچیده‌تر کنیم. برای مثال می‌خواهیم بررسی کنیم اگر منبعی واقعا متعلق به کاربر جاری سیستم است، به آن دسترسی داشته باشد. برای مثال هرچند کاربر جاری دارای نقش PayingUser است، اما آیا باید اجازه‌ی ویرایش تصاویر تمام کاربران، برای او صادر شده باشد؟ برای پیاده سازی یک چنین موارد پیچیده‌ای که فراتر از مفهوم نقش‌ها هستند، ویژگی جدیدی به نام Authorization policies به ASP.NET Core اضافه شده‌است که آن‌را در این قسمت بر اساس امکانات IdentityServer 4 بررسی می‌کنیم.


    مقایسه تعریف سطوح دسترسی «مبتنی بر نقش‌ها» با سطوح دسترسی «مبتنی بر سیاست‌های امنیتی»

    - در سطوح دسترسی «مبتنی بر نقش‌ها»
    یک‌سری نقش از پیش تعریف شده وجود دارند؛ مانند 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")
                        }
                    }
                };
            }
    سپس باید تعاریف این claims جدید را به متد GetIdentityResources افزود تا به صورت scopeهای جدید از طرف کلاینت‌ها قابل درخواست باشند و چون این claimها استاندارد نیستند، برای تعریف آن‌ها از IdentityResource استفاده می‌کنیم:
    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" })
                };
            }
    همچنین باید مطمئن شد که کلاینت مدنظر ما قادر است این scopeهای تعریف شده را درخواست کند و IDP مجاز است تا آن‌ها را بازگشت دهد. برای این منظور آن‌ها را به لیست AllowedScopes تعریف کلاینت، اضافه می‌کنیم:
    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 جدید را از طریق IDP، پیدا کند.
    البته همانطور که در قسمت‌های قبل نیز ذکر شد، اگر 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");
                        });
                });
    در اینجا نحوه‌ی تعریف یک Authorization Policy جدید را مشاهده می‌کنید. ابتدا یک نام برای آن تعریف می‌شود که در قسمت‌های دیگر برنامه جهت ارجاع به آن مورد استفاده قرار می‌گیرد. سپس تنظیمات این سیاست دسترسی جدید را مشاهده می‌کنید که در آن نیاز است کاربر مدنظر حتما اعتبارسنجی شده باشد. از کشور ir بوده و همچنین سطح اشتراک او PayingUser باشد. در اینجا پارامتر requiredValues، یک آرایه را می‌پذیرد. بنابراین اگر برای مثال کشورهای دیگری نیز مدنظر هستند، می‌توان لیست آن‌ها را در اینجا اضافه کرد.
    به علاوه 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>
    }
    برای جایگزین کردن آن جهت استفاده‌ی از سیاست دسترسی جدید CanOrderFrame، ابتدا نیاز است در این View به سرویس IAuthorizationService دسترسی پیدا کنیم که روش تزریق آن‌را در ذیل مشاهده می‌کنید:
    @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>
    }
    اکنون لینک منوی درخواست نگارش قاب شده‌ی یک تصویر، صرفا به کاربران تامین کننده‌ی سیاست دسترسی CanOrderFrame نمایش داده می‌شود.

    ب) اصلاح کنترلر 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()
            {
    در اینجا فیلتر Authorize امکان پذیرش نام یک Policy را نیز به همراه دارد.

    اکنون برای آزمایش برنامه یکبار از آن خارج شده و سپس توسط اکانت 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);
            }
        }
    }
    در پروژه‌ی ImageGallery.WebApi.Services ابتدا یک Authorization Requirement و سپس پیاده سازی کننده‌ی آن که Authorization Handler نام دارد را تعریف کرده‌ایم. این پروژه نیاز به وابستگی‌های ذیل را دارد تا کامپایل شود.
    <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
    {
    }
    ابتدا نیاز است یک نیازمندی دسترسی جدید را با پیاده سازی اینترفیس IAuthorizationRequirement ارائه دهیم. این نیازمندی، خالی است و صرفا به عنوان نشانه‌ای جهت یافت AuthorizationHandler استفاده کننده‌ی از آن استفاده می‌شود. در اینجا در صورت نیاز می‌توان یک سری خاصیت اضافه را تعریف کرد تا آن‌ها را به صورت پارامترهایی ثابت به AuthorizationHandler ارسال کند.

    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>();
    ابتدا باید MustOwnImageHandler تهیه شده را به سیستم تزریق وابستگی‌ها معرفی کنیم.
    سپس یک Policy جدید را با نام دلخواه MustOwnImage تعریف کرده و نیازمندی علامتگذار خود را به عنوان یک policy.Requirements جدید، اضافه می‌کنیم. همانطور که ملاحظه می‌کنید یک وهله‌ی جدید از MustOwnImageRequirement در اینجا ثبت شده‌است. همین وهله به متد HandleRequirementAsync نیز ارسال می‌شود. بنابراین اگر نیاز به ارسال پارامترهای بیشتری به این متد وجود داشت، می‌توان خواص مرتبطی را به کلاس MustOwnImageRequirement نیز اضافه کرد.
    همانطور که مشخص است، در اینجا یک نیازمندی را می‌توان ثبت کرد و نه Handler آن‌را. این Handler از سیستم تزریق وابستگی‌ها بر اساس آرگومان جنریک AuthorizationHandler پیاده سازی شده، به صورت خودکار یافت شده و اجرا می‌شود (بنابراین اگر Handler شما اجرا نشد، مطمئن شوید که حتما آن‌را به سیستم تزریق وابستگی‌ها معرفی کرده‌اید).

    پس از آن هر کنترلر یا اکشن متدی که از این سیاست دسترسی پویای تهیه شده استفاده کند:
    [Authorize(Policy ="MustOwnImage")]
    به صورت خودکار توسط MustOwnImageHandler مدیریت می‌شود.


    اعمال سیاست دسترسی پویای تعریف شده به 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)
            {
            }
        }
    }
    در اینجا در سه قسمت GetImage ،DeleteImage و UpdateImage با اعمال سیاست دسترسی پویای MustOwnImage، اگر کاربر جاری همان Owner تصویر درخواستی نباشد، دسترسی او به اجرای کدهای داخل این اکشن متدها به صورت خودکار بسته خواهد شد.




    کدهای کامل این قسمت را از اینجا می‌توانید دریافت کنید.
    برای اجرای برنامه:
    - ابتدا به پوشه‌ی 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 وارد کنید.
    مطالب دوره‌ها
    کار با RavenDB از طریق REST API آن
    در این قسمت قصد داریم برخلاف رویه معمول کار با RavenDB که از طریق کتابخانه‌های کلاینت آن انجام می‌شود، با استفاده از REST API آن، ساز و کار درونی آن‌را بیشتر بررسی کنیم.


    REST چیست؟

    برای درک ساختار پشت صحنه RavenDB نیاز است با مفهوم REST آشنا باشیم؛ زیرا سرور این بانک اطلاعاتی، خود را به صورت یک RESTful web service در اختیار مصرف کنندگان قرار می‌دهد.
    REST مخفف representational state transfer است و این روزها هر زمانیکه صحبت از آن به میان می‌آید منظور یک RESTful web service است که با استفاده از تعدادی HTTP Verb استاندارد می‌توان با آن کار کرد؛ مانند GET، POST، PUT و DELETE. با استفاده از GET‌، یک منبع ذخیره شده بازگشت داده می‌شود. با استفاده از فعل PUT، اطلاعاتی به منابع موجود اضافه و یا جایگزین می‌شوند. POST نیز مانند PUT است با این تفاوت که نوع اطلاعات ارسالی آن اهمیتی نداشته و تفسیر آن به سرور واگذار می‌شود. از DELETE نیز برای حذف یک منبع استفاده می‌گردد.


    چند مثال
    فرض کنید REST API برنامه‌ای از طریق آدرس http://myapp.com/api/questions در اختیار شما قرار گرفته است. در این آدرس، به questions منابع یا Resource گفته می‌شود. اگر دستور GET پروتکل HTTP بر روی این آدرس اجرا شود، انتظار ما این است که لیست تمام سؤالات بازگشت داده شود و اگر از دستور POST استفاده شود، باید یک سؤال جدید به مجموعه منابع موجود اضافه گردد.
    اکنون آدرس http://myapp.com/api/questions/1 را درنظر بگیرید. در اینجا عدد یک معادل Id اولین سؤال ثبت شده است. بر اساس این آدرس خاص، اینبار اگر دستور GET صادر شود، تنها اطلاعات سؤال یک بازگشت داده خواهد شد و یا اگر از دستور PUT استفاده شود، اطلاعات سؤال یک با مقدار جدید ارسالی جایگزین می‌شود و یا با فراخوانی دستور DELETE، سؤال شماره یک حذف خواهد گردید.


    کار با دستور GET

    در ادامه، به مثال قسمت قبل مراجعه کرده و تنها سرور RavenDB را اجرا نمائید (برنامه Raven.Server.exe)، تا در ادامه بتوانیم دستورات HTTP را بر روی آن امتحان کنیم. همچنین نیاز به برنامه معروف فیدلر نیز خواهیم داشت. از این برنامه برای ساخت دستورات HTTP استفاده خواهد شد.
    پس از دریافت و نصب فیدلر، برگه Composer آن‌را گشوده و http://localhost:8080/docs/questions/1 را در حالت GET اجرا کنید:


    در این حالت دستور بر روی بانک اطلاعاتی اجرا شده و خروجی را در برگه Inspectors آن می‌توان مشاهده کرد:



    به علاوه در اینجا یک سری هدر اضافی (یا متادیتا) را هم می‌توان مشاهده کرد که RavenDB جهت سهولت کار کلاینت خود ارسال کرده است:


    یک نکته: اگر آدرس http://localhost:8080/docs/questions را اجرا کنید، به معنای درخواست دریافت تمام سؤالات است. اما RavenDB به صورت پیش فرض طوری طراحی شده‌است که تمام اطلاعات را بازگشت ندهد و شعار آن Safe by default است. به این ترتیب مشکلات مصرف حافظه بیش از حد، پیش از بکارگیری یک سیستم در محیط کاری واقعی، توسط برنامه نویس یافت شده و مجبور خواهد شد تا برای نمایش تعداد زیادی رکورد، حتما صفحه بندی اطلاعات را پیاده سازی کرده و هربار تعداد معقولی از رکوردها را واکشی نماید.


    کار با دستور PUT

    اینبار نوع دستور را به PUT و آدرس را به http://localhost:8080/docs/questions/1 تنظیم می‌کنیم. همچنین در قسمت Request body، مقداری را که قرار است در سؤال یک درج شود، با فرمت JSON وارد می‌کنیم.
    برای آزمایش صحت عملکرد آن، مرحله کار با دستور GET را یکبار دیگر تکرار نمائید:


    همانطور که مشاهده می‌کنید، تغییر ما در عنوان سؤال یک، با موفقیت اعمال شده است.


    کار با دستور POST

    در حین کار با دستور PUT، نیاز است حتما Id سؤال مورد نظر برای به روز رسانی (و یا حتی ایجاد نمونه جدید، در صورت عدم وجود) ذکر شود. اگر نیاز است اطلاعاتی به سیستم اضافه شوند و Id آن توسط RavenDB انتساب داده شود، بجای دستور PUT از دستور POST استفاده خواهیم کرد.


    مطابق تصویر، اطلاعات شیء مدنظر را با فرمت JSON به آدرس http://localhost:8080/docs/ ارسال خواهیم کرد. در این حالت اگر به برگه‌ی Inspectors مراجعه نمائیم، یک چنین خروجی JSON ایی دریافت می‌گردد:


    Key در اینجا شماره منحصربفرد سند ایجاد شده است و برای دریافت آن تنها کافی است که دستور GET را بر روی آدرس زیر که نمایانگر Key دریافتی است، اجرا کنیم:
    http://localhost:8080/docs/e0a92054-9003-4dda-84e2-93e83b359102


    کار با دستور DELETE

    برای حذف یک سند تنها کافی است آدرس آن‌را وارد کرده و نوع دستور را بر روی Delete قرار دهیم. برای مثال اگر دستور Delete را بر روی آدرس فوق که به همراه Id تولید شده توسط RavenDB است اجرا کنیم، بلافاصله سند از بانک اطلاعاتی حذف خواهد شد.


    بازگشت چندین سند از بانک اطلاعاتی RavenDB

    برای نمونه، در فراخوانی‌های Ajaxایی نیاز است چندین رکورد با هم بازگشت داده شوند. برای این منظور باید یک درخواست Post ویژه را مهیا کرد:



    در اینجا آدرس ارسال اطلاعات، آدرس خاص http://localhost:8080/queries است. اطلاعات ارسالی به آن، آرایه‌ای از Idهای اسنادی است که به اطلاعات آن‌ها نیاز داریم.


    بنابراین برای کار با RavenDB در برنامه‌های وب و خصوصا کدهای سمت کلاینت آن، نیازی به کلاینت یا کتابخانه ویژه‌ای نیست و تنها کافی است یک درخواست Ajax از نوع post را به آدرس کوئری‌های سرور RavenDB ارسال کنیم تا نتیجه نهایی را به شکل JSON دریافت نمائیم.
    نظرات مطالب
    Blazor 5x - قسمت هشتم - مبانی Blazor - بخش 5 - تامین محتوای نمایشی کامپوننت‌های فرزند توسط کامپوننت والد
    یک نکته‌ی تکمیلی: روش ارسال داده‌ها به RenderFragmentها

    در مباحث اعتبارسنجی و احراز هویت Blazor در قسمت‌های بعدی، به قطعه کد context@ داری در داخل یک RenderFragment خواهیم رسید:
    <AuthorizeView>
        <Authorized>
                    Hello, @context.User.Identity.Name!
        </Authorized>
    </AuthorizeView>
    اکنون این سؤال مطرح است که این context@ از کجا آمده‌است و چه مفهومی را دارد؟
    برای پاسخ به این سؤال نیاز است با مفهوم «Templated components» در برنامه‌های Blazor آشنا شد. تا اینجا از RenderFragmentها صرفا جهت فراهم آوردن قسمت ثابتی از قالب کامپوننت جاری، توسط استفاده کننده‌ی از آن، کمک گرفتیم. اما در همان سمت استفاده کننده، امکان دسترسی به اطلاعات مهیای داخل آن فرگمنت نیز وجود دارد. برای نمونه به کدهای کامپوننت TableTemplate.razor دقت کنید:
    @typeparam Titem
    
    <table class="table">
        <thead>
            <tr>@TableHeader</tr>
        </thead>
        <tbody>
            @foreach (var item in Items)
            {
                <tr>@RowTemplate(item)</tr>
            }
        </tbody>
    </table>
    
    @code {
        [Parameter]
        public RenderFragment TableHeader { get; set; }
    
        [Parameter]
        public RenderFragment<TItem> RowTemplate { get; set; }
    
        [Parameter]
        public IReadOnlyList<TItem> Items { get; set; }
    }
    - این کامپوننت، قالب سفارشی ثابت هدر جدول را توسط یک RenderFragment، از بکارگیرنده‌ی خود دریافت می‌کند.
    - همچنین یک RenderFragment جنریک را نیز مشاهده می‌کنید که قالب ردیف‌های جدول را تامین می‌کند. نوع جنریک قابل دسترسی در این کامپوننت، توسط دایرکتیو typeparam Titem@ تعریف شده‌ی در ابتدای آن، مشخص شده‌است.
    - بنابراین هربار که ردیفی از بدنه‌ی جدول در حال رندر است، یک شیء item از نوع TItem را به قالب سفارشی تامین شده‌ی توسط بکارگیرنده‌ی خود ارسال می‌کند.
    اکنون این سؤال مطرح می‌شود که چگونه می‌توان به شیء item، در سمت والد یا بکارگیرنده‌ی کامپوننت TableTemplate فوق دسترسی یافت؟
    برای اینکار می‌توان از پارامتر ویژه‌ای به نام context که یک implicit parameter است و به صورت پیش‌فرض تعریف شده و مهیا است، در سمت کدهای بکارگیرند‌ه‌ی کامپوننت، استفاده کرد:
    @page "/pets"
    <h1>Pets</h1>
    <TableTemplate Items="pets">
        <TableHeader>
            <th>ID</th>
            <th>Name</th>
        </TableHeader>
        <RowTemplate>
            <td>@context.PetId</td>
            <td>@context.Name</td>
        </RowTemplate>
    </TableTemplate>
    
    @code {
        private List<Pet> pets = new()
        {
            new Pet { PetId = 2, Name = "Mr. Bigglesworth" },
            new Pet { PetId = 4, Name = "Salem Saberhagen" },
            new Pet { PetId = 7, Name = "K-9" }
        };
    
        private class Pet
        {
            public int PetId { get; set; }
            public string Name { get; set; }
        }
    }
    - در اینجا روش بکارگیری کامپوننت TableTemplate را در کامپوننتی دیگر مشاهده می‌کنید. توسط فرگمنت TableHeader، قالب ثابت هدر این جدول تامین شده‌است. توسط فرگمنت RowTemplate قالب پویای ردیف‌های جدول ارائه شده‌است.
    - همچنین در اینجا پارامتر ویژه‌ای به نام context@ را نیز مشاهده می‌کنید. این پارامتر همان شیء item ای است که در حین رندر هر ردیف جدول، به فرگمنت RowTemplate ارسال می‌شود. به این ترتیب کامپوننت والد می‌تواند از اطلاعات در حال رندر توسط کامپوننت فرگمنت دار، مطلع شود و از آن استفاده کند. در این مثال، نوع context@، از نوع کلاس Pet است که سعی شده بر اساس نوع پارامتر Items ارسالی به آن، توسط کامپایلر تشخیص داده شود. حتی می‌توان این نوع را به صورت صریحی نیز مشخص کرد:
    <TableTemplate Items="pets" TItem="Pet">
    این مورد زمانی مفید است که چندین پارامتر جنریک را در کامپوننت تعریف کرده باشیم:
    <SomeGenericComponent TParam1="Person" TParam2="Supplier" TItem=etc/>
    و یا می‌توان نام پارامتر ویژه‌ی context@ را در تمام RenderFragmentهای جنریک، با ذکر ویژگی Context برای مثال به pet تغییر داد:
    <TableTemplate Items="pets" Context="pet">
        <TableHeader>
            <th>ID</th>
            <th>Name</th>
        </TableHeader>
        <RowTemplate>
            <td>@pet.PetId</td>
            <td>@pet.Name</td>
        </RowTemplate>
    </TableTemplate>
    و یا حتی می‌توان این نام را به صورت اختصاصی به ازای هر RenderFragment جنریک، مشخص کرد. برای اینکار ویژگی Context را دقیقا بر روی RenderFragment مدنظر قرار می‌دهیم:
    <TableTemplate Items="pets">
        <TableHeader>
            <th>ID</th>
            <th>Name</th>
        </TableHeader>
        <RowTemplate Context="pet">
            <td>@pet.PetId</td>
            <td>@pet.Name</td>
        </RowTemplate>
    </TableTemplate>
    این تغییرنام بهتر است زمانی صورت گیرد که نام پیش‌فرض context، با نام مشابه دیگری در کامپوننت جاری، تداخل پیدا کرده‌است.
    نظرات مطالب
    مقایسه بین حلقه های تکرار (Lambda ForEach و for و foreach)
    "این آزمایشات رو اگر در هر سیستم دیگر با هر Config اجرا کنید نتیجه کلی تغییر نخواهد کرد و فقط از نظر زمان اجرا تفاوت خواهیم داشت نه در نتیجه کلی." 
    این مطلب لزوما صحیح نیست. یک بنچمارک میتونه تو مجموعه سخت افزارهای مختلف، نتایج کاملا متفاوتی داشته باشه. مثلا سوالی در همین زمینه آقای شهروز جعفری تو StackOverflow پرسیدن که در جوابش دو نفر نتایج متفاوتی ارائه دادن.
    معمولا برای بیان نتایج تستهای بنچمارک ابتدا مشخصات سخت افزاری ارائه میشه مخصوصا وقتیکه نتایج دقیق (و نه کلی) نشون داده میشه. مثل همین نتایج دقیق زمانهای اجرای حلقه‌ها.
    نکته ای که من درکامنتم اشاره کردم صرفا درباره تست "سرعت اجرای" انواع حلقه‌ها بود که ممکنه با تست کارایی حلقه‌ها در اجرای یک کد خاص فرق داشته باشه.
    نکته دیگه هم اینکه نمیدونم که آیا شما از همون متد Console.WriteLine در حلقه‌ها برای اجرای تستون استفاده کردین یا نه. فقط باید بگم که به خاطر مسائل و مشکلات مختلفی که استفاده از این متد به همراه داره، به نظر من بکارگیری اون تو این جور تست‌ها اصلا مناسب نیست و باعث دور شدن زیاد نتایج از واقعیت میشه. مثلا من تست کردم و هر دفعه یه نتیجه‌ای می‌داد که نمیشه بر اساس اون نتیجه‌گیری کرد. 

    مورد دیگه ای هم که باید اضافه کنم اینه که بهتر بود شما کد کامل تست خودتون رو هم برای دانلود میذاشتین تا دیگران هم بتونن استفاده کنن. اینجوری خیلی بهتر میشه نتایج مختلف رو با هم مقایسه کرد. این مسئله برای تستای بنچمارک نسبتا رایج هست. مثل کد زیر که من آماده کردم:
    static void Main(string[] args)
    {
      //Action<int> func = Console.WriteLine;
      Action<int> func = number => number++;
      do
      {
        try
        {
          Console.Write("Iteration: ");
          var iterations = Convert.ToInt32(Console.ReadLine());
          Console.Write("Loop Type (for:0, foreach:1, List.ForEach:2, Array.ForEach:3): ");
          var loopType = Console.ReadLine();
          switch (loopType)
          {
            case "0":
              Console.WriteLine("FOR loop test for {0} iterations", iterations.ToString("0,0"));
              TestFor(iterations, func);
              break;
            case "1":
              Console.WriteLine("FOREACH loop test for {0} iterations", iterations.ToString("0,0"));
              TestForEach(iterations, func);
              break;
            case "2":
              Console.WriteLine("LIST.FOREACH test for {0} iterations", iterations.ToString("0,0"));
              TestListForEach(iterations, func);
              break;
            case "3":
              Console.WriteLine("ARRAY.FOREACH test for {0} iterations", iterations.ToString("0,0"));
              TestArrayForEach(iterations, func);
              break;
          }
        }
        catch (Exception ex)
        {
          Console.WriteLine(ex);
        }
        Console.Write("Continue?(Y/N)");
        Console.WriteLine("");
      } while (Console.ReadKey(true).Key != ConsoleKey.N);
    
      Console.WriteLine("Press any key to exit");
      Console.ReadKey();
    }
    
    
    static void TestFor(int iterations, Action<int> func)
    {
      StartupTest(func);
    
      var watch = Stopwatch.StartNew();
      for (int i = 0; i < iterations; i++)
      {
        func(i);
      }
      watch.Stop();
      ShowResults("for loop test: ", watch);
    }
    
    static void TestForEach(int iterations, Action<int> func)
    {
      StartupTest(func);
      var list = Enumerable.Range(0, iterations);
    
      var watch = Stopwatch.StartNew();
      foreach (var item in list)
      {
        func(item);
      }
      watch.Stop();
      ShowResults("foreach loop test: ", watch);
    }
    
    static void TestListForEach(int iterations, Action<int> func)
    {
      StartupTest(func);
      var list = Enumerable.Range(0, iterations).ToList();
    
      var watch = Stopwatch.StartNew();
      list.ForEach(func);
      watch.Stop();
      ShowResults("list.ForEach test: ", watch);
    }
    
    static void TestArrayForEach(int iterations, Action<int> func)
    {
      StartupTest(func);
      var array = Enumerable.Range(0, iterations).ToArray();
    
      var watch = Stopwatch.StartNew();
      Array.ForEach(array, func);
      watch.Stop();
      ShowResults("Array.ForEach test: ", watch);
    }
    
    static void StartupTest(Action<int> func)
    {
      // clean up
      GC.Collect();
      GC.WaitForPendingFinalizers();
      GC.Collect();
    
      // warm up
      func(0);
    }
    static void ShowResults(string description, Stopwatch watch)
    {
      Console.Write(description);
      Console.WriteLine(" Time Elapsed {0} ms", watch.ElapsedMilliseconds);
    }
    قبل از اجرای تست بهتره برنامه رو برای نسخه Release بیلد کنیم. ساده‌ترین روشش در تصویر زیر نشون داده شده:

    پس از این تغییر و بیلد پروژه نتایج رو مقایسه میکنیم. نتایج اجرای این تست در همون سیستمی که قبلا تستای StringBuilder و Microbenchmark رو انجام دادم (یعنی لپ تاپ msi GE 620 با Core i7-2630QM) بصورت زیر:

    البته نتایج این تستها مطلق نیستن. نکاتی که در کامنت قبلی اشاره کردم از عوامل تاثیرگذار هستن.
    موفق باشین.
    مطالب
    روش دیگر نوشتن Model binderهای سفارشی در ASP.NET Core 7x با معرفی IParseable
    ASP.NET MVC از روش بکارگیری binding providerها برای تدارک زیرساخت model binding استفاده می‌کند که در این روش، داده‌های پارامترهای یک action method از طریق هدرها، کوئری استرینگ‌ها، بدنه‌ی درخواست و غیره تهیه می‌شوند. در حالت پیش‌فرض اگر این پارامترها از نوع‌های ساده‌ای مانند اعداد و یا DateTime تشکیل شده باشند و یا به همراه یک TypeConverter باشند که امکان تبدیل این رشته را به آن نوع خاص بدهد، به صورت خودکار bind خواهند شد و هر نوع دیگری، به صورت یک نوع پیچیده درنظر گرفته می‌شود. نوع پیچیده یعنی bind برای مثال اطلاعات بدنه‌ی درخواست به تک تک خواص آن نوع. برای نمونه در کنترلر زیر:
    [Route("[controller]")]
    public class WeatherForecastController : ControllerBase
    {
        private static readonly string[] Summaries =
        {
            "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy",
            "Hot", "Sweltering", "Scorching",
        };
    
        // /WeatherForecast/GetForecast2?from=1&to=3
        [HttpGet("[action]")]
        public IEnumerable<WeatherForecast> GetForecast2(Duration days)
        {
            return Enumerable.Range(days.From, days.To)
                             .Select(index => new WeatherForecast
                                              {
                                                  Date = DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
                                                  TemperatureC = Random.Shared.Next(-20, 55),
                                                  Summary = Summaries[Random.Shared.Next(Summaries.Length)],
                                              })
                             .ToArray();
        }
    }
    که از دو مدل زیر استفاده می‌کند:
    public class Duration
    {
        public int From { get; set; }
        public int To { get; set; }
    }
    
    public class WeatherForecast
    {
        public DateOnly Date { get; set; }
    
        public int TemperatureC { get; set; }
    
        public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
    
        public string? Summary { get; set; }
    }
    می‌توان خواص پارامتر days را از طریق کوئری استرینگ‌های HttpGet، برای مثال با ارائه‌ی آدرس WeatherForecast/GetForecast2?from=1&to=3 به صورت خودکار تامین کرد. زمانیکه اطلاعات رسیده چنین شکلی را داشته باشند، کار پردازش و bind آن‌ها در حالت HttpGet، خودکار است.


    روش دیگر پردازش اطلاعات رشته‌ای رسیده و تشکیل یک Model Binder سفارشی در ASP.NET Core 7x

    اکنون فرض کنید بجای آدرس WeatherForecast/GetForecast2?from=1&to=3 که اطلاعات را از طریق کوئری استرینگ مشخص و استانداردی دریافت می‌کند، می‌خواهیم اطلاعات آن‌را از طریق یک قالب سفارشی و غیراستاندارد مانند WeatherForecast/GetForecast3/1-3 دریافت کنیم:
    // /WeatherForecast/GetForecast3/1-3
    [HttpGet("[action]/{days}")]
    public IEnumerable<WeatherForecast> GetForecast3(Days days)
        {
            return Enumerable.Range(days.From, days.To)
                             .Select(index => new WeatherForecast
                                              {
                                                  Date = DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
                                                  TemperatureC = Random.Shared.Next(-20, 55),
                                                  Summary = Summaries[Random.Shared.Next(Summaries.Length)],
                                              })
                             .ToArray();
        }
    یکی از راه‌های انجام اینکار، نوشتن model binderهای سفارشی مخصوص است و یا اکنون در ASP.NET Core 7x می‌توان با پیاده سازی اینترفیس IParsable به صورت خودکار و با روشی دیگر به این مقصود رسید:
    using System.Diagnostics.CodeAnalysis;
    using System.Globalization;
    
    namespace NET7Mvc.Models;
    
    public class Days : IParsable<Days>
    {
        public Days(int from, int to)
        {
            From = from;
            To = to;
        }
    
        public int From { get; }
        public int To { get; }
    
        public static bool TryParse([NotNullWhen(true)] string? value,
                                    IFormatProvider? provider,
                                    [MaybeNullWhen(false)] out Days result)
        {
            var items = value?.Split('-', StringSplitOptions.RemoveEmptyEntries);
            if (items is { Length: 2 })
            {
                if (int.TryParse(items[0], NumberStyles.None, provider, out var from)
                    && int.TryParse(items[1], NumberStyles.None, provider, out var to))
                {
                    result = new Days(from, to);
                    return true;
                }
            }
    
            result = default;
            return false;
        }
    
        public static Days Parse(string value, IFormatProvider? provider)
        {
            if (!TryParse(value, provider, out var result))
            {
                throw new ArgumentException("Could not parse the given value.", nameof(value));
            }
    
            return result;
        }
    }
    - برای پیاده سازی این اینترفیس باید دو متد TryParse و Parse آن‌را به صورت فوق پیاده سازی کرد و توسط آن، روش تبدیل رشته‌ی دریافتی از کاربر را به شیء مدنظر، مشخص کرد.
    - همینقدر که مدلی IParsable را پیاده سازی کرده باشد، از امکانات آن به صورت خودکار استفاده خواهد شد و نیازی به معرفی و یا تنظیمات خاص دیگری ندارد.
    - البته این قابلیت جدید نیست و پشتیبانی از IParsable، پیشتر در Minimal API دات نت 6 ارائه شده بود؛ اما در دات نت 7 توسط ASP.NET Core MVC نیز قابل استفاده شده‌است.
    مطالب
    ساخت یک سایت ساده‌‌ی نمایش لیست فیلم با استفاده از Vue.js - قسمت اول
    Vue.js  یکی از محبوب ترین فریم ورک‌های  SPA است و سایت جاری نیز دارای مقالات خوبی درباره‌ی Vue.js می‌باشد. قصد داریم طی چند مقاله با استفاده از Vue.js و چندین پلاگین مطرح آن، یک سایت ساده‌ی نمایش فیلم را ایجاد کنیم. ابتدا Node.js  را بر روی سیستم خود نصب کنید (پیشنهاد ما نسخه‌ی LTS می‌باشد). مراحل نصب آن ساده است و بصورت Nextهایی پی در پی می‌باشد؛ بصورت پیش فرض npm نیز همراه آن نصب میشود. سپس دو دستور زیر را جهت صحت انجام مراحل نصب، تست نمایید.

    در این مقاله با ادیتور VS Code کار میکنیم. بعد از نصب آن، از منوی Terminal، گزینه‌ی New Terminal را کلیک کنید تا پنجره‌ی PowerShell نمایش داده شود؛ برای سرعت و دقت بیشتر در برنامه‌های  vue.js ای. با دستور زیر vue cli را  نصب میکنیم  (فقط یک مرتبه و برای برنامه‌های بعدی vue.jsای، نیازی به اجرای این دستور نداریم):

    npm install -g @vue/cli

    جهت راه اندازی یک برنامه‌ی پیش فرض Vue.js ای، کافیست دستور زیر را اجرا نماییم تا پکیج‌های مورد نیاز، به همراه کانفیگ اولیه (Zero config) برای ما ایجاد شوند:

    vue create movie-app

    بعد از ایجاد برنامه در vs code، از طریق منوی File، گزینه Open Folder را کلیک کرده و پوشه برنامه‌ای را که ایجاد کردیم، Select Folder میکنیم. ساختار اولیه‌ی برنامه‌ی ایجاد شده، به شکل زیر می‌باشد:

    نیازمندیهای مثال جاری

    A) برای گرفتن اطلاعات مورد نمایش در مثال جاری، از سایت omdbapi.com استفاده میکنیم که با دریافت یک api key آن بصورت رایگان، میتوانیم web serviceهای آن را Call نماییم.

    B) از  vuetify برای ui استفاده میکنیم که بصورت Material Design و دارای کامپوننت‌های غنی می‌باشد؛ ضمن اینکه RTL را هم پشتیبانی میکند.

    برای نصب آن در Terminal دستور زیر را اجرا میکنیم:

    vue add vuetify

    سپس جهت تست و صحت افزوده شدن و کانفیگ درست، با دستور زیر برنامه را اجرا میکنیم:

    npm run serve

    بعد از اجرای دستور فوق، روی گزینه زیر ctrl+click میکنیم تا نتیجه کار در مرورگر قابل رویت باشد:

    نمایش صفحه زیر نشان دهنده‌ی درستی انجام کار تا اینجا است:


    نکته: جهت استفاده از امکان RTL کافیست در فایل vuetify.js واقع در پوشه‌ی plugins، تغییرات زیر را انجام دهیم. در مثال جاری بدلیل اینکه اطلاعات انگلیسی می‌باشند، از نسخه LTR آن استفاده میکنیم؛ هر چند یکسری api فارسی نیز موجود می‌باشد که میتوان از آنها استفاده نمود.

    import Vue from 'vue'
    import Vuetify from 'vuetify/lib'
    import 'vuetify/src/stylus/app.styl'
    
    Vue.use(Vuetify, {
      iconfont: 'md',
      rtl: true
    })


    C) نصب  vue-router : جهت انجام routeهای تودرتو ، مپ کردن کامپوننت ها با آدرسی مشخص، کار با پارامتر و  HTML5 History API  مورد استفاده قرار میگیرد. برای نصب آن، دستور زیر را اجرا میکنیم:

    npm install vue-router

    برای نوشتن routeهای مورد نیاز، یک فولدر را با نام router، در پوشه src برنامه ایجاد میکنیم و یک فایل جاوا اسکریپتی را در آن با نام index.js، میسازیم (این ساختار برای مدیریت بهتر پروژه می‌باشد):

    درون فایل  index.js، محتویات زیر را طبق مستندات آن قرار میدهیم:

    import Vue from 'vue'
    import VueRouter from 'vue-router'
    
    Vue.use(VueRouter)

    جهت استفاده از این router، نیاز است تا در نمونه‌ی وهله سازی شده‌ی vue برنامه بکار گرفته شود. فایل  main.js  را باز کنید و خط زیر را در قسمت بالای برنامه وارد کنید:

    import router from './router'

    اکنون محتویات فایل  main.js بشکل زیر می‌باشد:

    import Vue from 'vue'
    import './plugins/vuetify'
    import App from './App.vue'
    import router from './router'
    
    Vue.config.productionTip = false
    
    new Vue({
      render: h => h(App),
      router
    }).$mount('#app')


    D) نصب axios : برای انجام  درخواستهای  HTTP  و عملیات ا‌ی‌جکس در vue.js  ترجیحا بهتر است از axios که یک کتابخانه‌ی محبوب می‌باشد و کار با آن ساده است، استفاده شود. برای نصب آن، دستور زیر را اجرا میکنیم:

    npm install axios


    E) نصب vuex : کتابخانه‌ای جهت مدیریت حالت (state management) برای  vue.js میباشد و مشابه آن Flux و Redux برای React می‌باشند. برای  نصب، دستور زیر را اجرا میکنیم:

    npm install vuex


    برای بکارگیری آن یک فولدر را با نام store در پوشه‌ی src برنامه ایجاد میکنیم و یک فایل جاوا اسکریپتی را در آن با نام index.js میسازیم (این ساختار برای مدیریت بهتر پروژه می‌باشد). درون فایل  index.js، محتویات زیر را طبق مستندات آن و ^ قرار میدهیم. 

    import Vue from 'vue'
    import Vuex from 'vuex'
    
    Vue.use(Vuex)
    
    export const store = new Vuex.Store()

    برای استفاده و کانفیگ آن، محتویات فایل  main.js را بشکل زیر تغییر دهید:

    import Vue from 'vue'
    import './plugins/vuetify'
    import App from './App.vue'
    import router from './router'
    import {store} from './store'
    
    Vue.config.productionTip = false
    
    new Vue({
      render: h => h(App),
      store,
      router
    }).$mount('#app')



    دریافت کد قسمت اول 

    نکته: برای اجرای برنامه و دریافت پکیج‌های مورد استفاده در مثال جاری، نیاز است دستور زیر را اجرا کنید:

    npm install