نظرات مطالب
اعتبارسنجی مبتنی بر JWT در ASP.NET Core 2.0 بدون استفاده از سیستم Identity
- مقدمه‌ی مطلب «پیاده سازی JSON Web Token با ASP.NET Web API 2.x» را مطالعه کنید.
- یک چنین کاری در Identity Server هم انجام می‌شود: «امن سازی برنامه‌های ASP.NET Core توسط IdentityServer 4x - قسمت نهم- مدیریت طول عمر توکن‌ها»؛ تحت مفهوم «Reference Tokens»:

نظرات مطالب
شروع به کار با EF Core 1.0 - قسمت 9 - بررسی رابطه‌ی One-to-One
منظورم این هست که به ازاری هر کاربر یک پروفایل وجود دارد و از این روش برای ارتباط بین User و Profile استفاده کردم. من از Asp.net Identity استفاده کردم و از این روش برای ارتباط One To One استفاده کردم.
HasKey(row => row.Id);
HasRequired(row => row.User).WithRequiredDependent(row => row.UserProfile);
Property(row => row.Id).HasColumnName("UserId");
این روش جواب داده است آیا این روش در asp.net core درست است یا از روشی که شما در مطلب گفتید استفاده کنم؟
نظرات مطالب
سفارشی سازی ASP.NET Core Identity - قسمت چهارم - User Claims
- این سیستم مدنظر شما نیست؟ اشکالی ندارد! از صفر خودتان آن‌را بنویسید و تنظیم کنید: «اعتبارسنجی مبتنی بر کوکی‌ها در ASP.NET Core 2.0 بدون استفاده از سیستم Identity»
- در Identity به ازای هر نقش کاربر، یک select به بانک اطلاعاتی وجود ندارد. دقیقا پس از لاگین، اطلاعات User Claims در کوکی شخص به صورت رمزنگاری شده، کش می‌شوند و در دفعات بعدی/درخواست‌های بعدی، از این کوکی خوانده خواهند شد. اما در پروژه‌ی DNT Identity به ازای هر درخواست، طوری تنظیم شده تا وضعیت اعتبار کاربر، بررسی شود و اینکار توسط تنظیم enableImmediateLogout و ValidationInterval = TimeSpan.Zero آن انجام می‌شود. چرا؟ چون اگر در سمت سرور، کاربری را غیرفعال کردید، آیا باید تا زمان منقضی شدن اعتبار کوکی آن، بتواند از سایت استفاده کند؟ بله. این مورد هزینه‌ی اعتبارسنجی User Claims و در نتیجه، کوئری گرفتن از بانک اطلاعاتی را به ازای هر درخواست، به همراه دارد؛ ولی ضروری است. یعنی این سیستم صرفا هر کوکی را که شامل یکسری User Claims باشد، معتبر نمی‌داند.
نظرات مطالب
امن سازی برنامه‌های ASP.NET Core توسط IdentityServer 4x - قسمت هشتم- تعریف سطوح دسترسی پیچیده
در Identity Server، دسترسی‌های کاربران بر اساس User Claims آن‌ها تعریف می‌شوند؛ مانند مثال ()public static List<TestUser> GetUsers مطلب جاری. بنابراین تعدادی Claims را به نام‌های SuperAdmin1 تا n، به کاربران SuperAdmin ای که مدنظر هستند، انتساب می‌دهید. سپس سایر کاربران زیر مجموعه‌ی آن‌ها هم Claims جدیدی مانند SuperAdmin1_User تا n را خواهند داشت. بعد از تعریف این Claims، نحوه‌ی دادن دسترسی‌ها دقیقا مانند مثال CanOrderFrame مطلب فوق است. یک Policy جدید را مانند SuperAdmin1User_Policy تعریف می‌کنید که policyBuilder.RequireClaim آن بر اساس Claim ای مانند SuperAdmin1_User کار کند. سپس قسمتی که قرار است صرفا با این Policy کار کند، توسط  [Authorize(Policy = " SuperAdmin1User_Policy")] محدود می‌شود.
ASP.NET Core Identity هم چنین طراحی مبتنی بر User Claims «تک» برنامه‌ای هم دارد. بحث جاری در مورد طراحی «چند» برنامه‌ای Identity Server هست.
مطالب
Blazor 5x - قسمت 21 - احراز هویت و اعتبارسنجی کاربران Blazor Server - بخش 1 - افزودن قالب ابتدایی Identity
در ادامه‌ی مثال این سری، می‌خواهیم امکان ثبت و ویرایش اتاق‌ها را (و یا امکانات رفاهی یک هتل را که به صورت تمرینی دقیقا مشابه افزودن مشخصات اتاق‌ها، اضافه شده و کدهای آن از فایل پیوستی انتهای بحث قابل دریافت است) به کاربران اعتبارسنجی شده‌ی دارای نقش مدیریتی، محدودیت کنیم و نمی‌خواهیم عموم کاربران برنامه بتوانند در این قسمت‌ها، تغییری را ایجاد کنند. برای این منظور از امکانات توکار و استاندارد ASP.NET Core Identity استفاده خواهیم کرد و این کتابخانه را از صفر و بدون تغییری، به پروژه‌ی جاری از نوع Blazor Server، به همان نحوی که طراحی شده، اضافه می‌کنیم و در مراحل بعدی، بر اساس نیازهای برنامه، قسمت‌های مختلف آن‌را سفارشی سازی خواهیم کرد.


تغییر نوع DbContext برنامه

پیش از شروع به یکپارچه کردن ASP.NET Core Identity با برنامه‌ی جاری، نیاز است نوع DbContext آن‌را به صورت زیر تغییر داد:
using BlazorServer.Entities;
using Microsoft.AspNetCore.Identity.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore;

namespace BlazorServer.DataAccess
{
    public class ApplicationDbContext : IdentityDbContext
    {
      // ...
- بنابراین به فایل BlazorServer\BlazorServer.DataAccess\ApplicationDbContext.cs مراجعه کرده و برای شروع، بجای DbContext، از IdentityDbContext استفاده می‌کنیم.
- این تغییر، نیاز به نصب بسته‌ی نیوگت Microsoft.AspNetCore.Identity.EntityFrameworkCore را نیز در پروژه‌ی جاری دارد تا IdentityDbContext آن شناسایی شده و قابل استفاده شود.


نصب ابزار تولید کدهای ASP.NET Core Identity

اگر از ویژوال استودیوی کامل استفاده می‌کنید، گزینه‌ی افزودن کدهای ASP.NET Core Identity به صورت زیر قابل دسترسی است:
project -> right-click > Add > New Scaffolded Item -> select Identity > Add
اما از آنجائیکه قصد داریم این مطلب، برای کاربران VSCode و همچنین سایر سیستم عامل‌ها نیز قابل استفاده باشد، از NET Core CLI. استفاده خواهیم کرد. برای این منظور، ابتدا ابزار سراسری dotnet-aspnet-codegenerator را نصب می‌کنیم:
dotnet tool install -g dotnet-aspnet-codegenerator
سپس به پروژه‌ی اصلی Blazor Server مراجعه کرده (BlazorServer.App.csproj در این مثال) و در پوشه‌ی آن، دستورات زیر را اجرا می‌کنیم تا بسته‌های نیوگت مورد نیاز ASP.NET Core Identity و UI آن، نصب شوند:
dotnet add package Microsoft.VisualStudio.Web.CodeGeneration.Design
dotnet add package Microsoft.EntityFrameworkCore.Design
dotnet add package Microsoft.AspNetCore.Identity.EntityFrameworkCore
dotnet add package Microsoft.AspNetCore.Identity.UI
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
dotnet add package Microsoft.EntityFrameworkCore.Tools
پس از نصب این وابستگی‌ها، اکنون در همین ریشه‌ی پروژه‌ی اصلی، دستور زیر را اجرا می‌کنیم تا فایل‌های ASP.NET Core Identity اضافه شوند:
dotnet aspnet-codegenerator identity --dbContext BlazorServer.DataAccess.ApplicationDbContext --force
در اینجا ذکر فضای نام کامل کلاس ApplicationDbContext ضروری است.
حال اگر به پروژه دقت کنیم، پوشه‌ی جدید Areas که به همراه فایل‌های مدیریتی ASP.NET Core Identity است، اضافه شده و حاوی کدهای صفحات لاگین، ثبت نام کاربر و غیره است.


اعمال تغییرات ابتدایی مورد نیاز جهت استفاده از ASP.NET Core Identity

تا اینجا کدهای پیش‌فرض مدیریتی ASP.NET Core Identity را به پروژه اضافه کردیم. در ادامه نیاز است تغییرات ذیل را به پروژه‌ی اصلی Blazor Server اعمال کنیم تا بتوان از این فایل‌ها استفاده کرد:
- به فایل BlazorServer.App\Startup.cs مراجعه کرده و UseAuthentication و UseAuthorization را دقیقا در محلی که مشاهده می‌کنید، اضافه می‌کنیم. همچنین در اینجا نیاز است مسیریابی‌های razor pages را نیز فعال کرد.
namespace BlazorServer.App
{
    public class Startup
    {
        // ...
 
        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {

            // ...

            app.UseRouting();

            app.UseAuthentication();
            app.UseAuthorization();

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapRazorPages();
                // ...
            });
        }
    }
}
- سپس به پوشه‌ی BlazorServer.DataAccess برنامه وارد شده و دستورات Migrations را یکبار دیگر اجرا می‌کنیم، تا جداول پیش‌فرض Identity، بر اساس Context جدید آن ایجاد شوند:
dotnet tool update --global dotnet-ef --version 5.0.4
dotnet build
dotnet ef migrations --startup-project ../BlazorServer.App/ add AddIdentity --context ApplicationDbContext
dotnet ef --startup-project ../BlazorServer.App/ database update --context ApplicationDbContext
پس از اجرای این دستورات، جداول جدید زیر به بانک اطلاعاتی برنامه اضافه می‌شوند:



افزودن گزینه‌ی منوی لاگین به برنامه‌ی Blazor Server


پس از این تغییرات، به برنامه‌ای رسیده‌ایم که مدیریت قسمت Identity آن، توسط قالب استاندارد مایکروسافت که در پوشه‌ی Areas\Identity\Pages\Account نصب شده و بر اساس فناوری ASP.NET Core Razor Pages کار می‌کند، انجام می‌شود.
اکنون می‌خواهیم در منوی برنامه‌ی Blazor Server خود که با صفحات Identity یکی شده‌است، لینکی را به صفحه‌ی لاگین این Area اضافه کنیم. اگر به فایل Shared\MainLayout.razor آن مراجعه کنیم، به صورت پیش‌فرض، لینکی به صفحه‌ی About، قرار دارد. به همین جهت این مورد را به صورت زیر اصلاح می‌کنیم:
ابتدا کامپوننت جدید BlazorServer.App\Shared\LoginDisplay.razor را با محتوای زیر ایجاد می‌کنیم:
<a href="Identity/Account/Register">Register</a>
<a href="Identity/Account/Login">Login</a>

@code {

}
که لینک‌هایی را به صفحات لاگین و ثبت نام یک کاربر جدید، تعریف می‌کند.
سپس از این کامپوننت در فایل BlazorServer.App\Shared\MainLayout.razor استفاده می‌کنیم:
<div class="top-row px-4">
    <LoginDisplay></LoginDisplay>
    <a href="https://docs.microsoft.com/aspnet/" target="_blank">About</a>
</div>


ثبت و فعالسازی سرویس‌های کار با ASP.NET Core Identity

البته اگر در این حال برنامه را اجرا کنیم، با کلیک بر روی لینک‌های فوق، استثنائی را مانند یافت نشدن سرویس UserManager، مشاهده خواهیم کرد. برای رفع این مشکل، به فایل BlazorServer.App\Startup.cs مراجعه کرده و سرویس‌های Identity را ثبت می‌کنیم:
namespace BlazorServer.App
{
    public class Startup
    {
        // ...

        public void ConfigureServices(IServiceCollection services)
        {
           // ...

            services.AddIdentity<IdentityUser, IdentityRole>()
                .AddEntityFrameworkStores<ApplicationDbContext>()
                .AddDefaultTokenProviders()
                .AddDefaultUI();

           // ...
اکنون اگر برنامه را اجرا کنیم، برای مثال صفحه‌ی ثبت یک کاربر جدید، بدون مشکل و خطایی نمایش داده می‌شود:


همانطور که مشاهده می‌کنید، قالب این قسمت Identity، با قالب قسمت Blazor Server یکی نیست؛ چون توسط Razor Pages و Area آن تامین می‌شود که master page خاص خودش را دارد. زمانیکه قالب Identity را اضافه می‌کنیم، علاوه بر Area خاص خودش، پوشه‌ی جدید Pages\Shared را نیز ایجاد می‌کند که قالب صفحات Identity را به کمک فایل Pages\Shared\_Layout.cshtml تامین می‌کند:


بنابراین سفارشی سازی قالب این قسمت، شبیه به قالبی که برای کامپوننت‌های Blazor مورد استفاده قرار می‌گیرد، باید در اینجا انجام شود و سفارشی سازی قالب کامپوننت‌های Blazor، در پوشه‌ی Shared ای که در ریشه‌ی پروژه‌است (BlazorServer.App\Shared\MainLayout.razor) انجام می‌شود.


کدهای کامل این مطلب را از اینجا می‌توانید دریافت کنید: Blazor-5x-Part-21.zip
مطالب
با HttpHandler بیشتر آشنا شوید
در  مقاله قبل توضیح دادیم که وظیفه httphandler رندر و پردازش خروجی یک درخواست هست؛ حالا در این مقاله قصد داریم که مفهوم httphandler را بیشتر بررسی کنیم.

HttpHandler
برای تهیه‌ی یک httphandler، باید کلاسی را بر اساس اینترفیس IHttpHandler پیاده سازی کنیم و بعدا آن را در web.config برنامه معرفی کنیم. برای پیاده سازی این اینترفیس، به یک متد به اسم ProcessRequest با یک پارامتر از نوع HttpContext و یک پراپرتی به اسم IsReusable نیاز داریم که مقدار برگشتی این پراپرتی را false بگذارید؛ بعدا خواهم گفت چرا اینکار را می‌کنیم. نحوه‌ی پیاده‌سازی یک httphandler به شکل زیر است:
public class MyHttpHandler : IHttpHandler
{
    public void ProcessRequest(HttpContext context)
    {        
    }

    public bool IsReusable
    {
        get { return false; }
    }
}
با استفاده از شیء context می‌توان به دو شیء httpresponse و httprequest دسترسی داشت. تکه کد زیر مثالی است در مورد نحوه‌ی تغییر در محتوای سایت:
public class MyHttpHandler : IHttpHandler
{
    public void ProcessRequest(HttpContext context)
    {
        HttpResponse response = context.Response;
        HttpRequest request = context.Request;

        response.Write("Every Page has a some text like this");
    }

    public bool IsReusable
    {
        get { return false; }
    }
}
بگذارید همین کد ساده را در وب کانفیگ معرفی کنیم:
<system.web>
  <httpHandlers>
      <add verb="*" path="*.aspx" type="MyHttpHandler"/>
  </httpHandlers>
</system.web>
اگر نسخه IIS شما همانند نسخه‌ی من باشد، نباید هیچ تغییری مشاهده کنید؛ زیرا کد بالا فقط در مورد نسخه‌ی IIS6 صدق می‌کند و برای نسخه‌های IIS 7 به بعد باید به شیوه زیر عمل کنید:
<configuration>
  <system.web>
    <httpHandlers>

  <add name="myhttphandler" verb="*" path="*.aspx" type="MyHttpHandler"/>

    </httpHandlers>
  </system.web>
</configuration>
خروجی نهایی باید تنها این متن باشد: Every Page has a some text like this 
گزینه Type که نام کلاس می‌باشد و اگر کلاس داخل یک فضای نام قرار گرفته باشد، باید اینطور نوشت : namespace.ClassName  
گزینه verb شامل مقادیری چون Get,Post,Head,Putو Delete می‌باشد و httphandler را فقط برای این نوع درخواست‌ها اجرا می‌کند و در صورتیکه بخواهید چندتا از آن‌ها را استفاده کنید، با , از هم جدا می‌شوند. مثلا Get,post و درصورتیکه همه‌ی گزینه‌ها را بخواهید علامت * را میتوان استفاده کرد. 
 گزینه‌ی path این امکان را به شما می‌دهد که مسیر و نوع فایل‌هایی را که قصد دارید روی آن‌ها فقط اجرا شود، مشخص کنید و ما در قطعه کد بالا گفته‌ایم که تنها روی فایل‌هایی با پسوند aspx اجرا شود و چون مسیری هم ذکر نکردیم برای همه‌ی مسیرها قابل اجراست. یکی از مزیت‌های دادن پسوند این است که می‌توانید پسوندهای اختصاصی داشته باشید. مثلا پسوند RSS برای فیدهای وب سایتتان. بسیاری از برنامه نویسان به جای استفاده از صفحات aspx از ashx استفاده می‌کنند که به مراتب سبک‌تر از aspx هست و شامل بخش ui نمی‌شود و نتیجه خروجی آن بر اساس کدی که می‌نویسید مشخص می‌شود که میتواند صفحه متنی یا عکس یا xml یا ... باشد. در اینجا در مورد ساخت صفحات ashx توضیح داده شده است. 

  IHttpHandlerFactory
کار این اینترفیس پیاده سازی یک کلاس است که خروجی آن یک کلاس از نوع IHttpHandler هست. اگر دقت کنید در مثال‌های قبلی ما برای معرفی یک هندلر در وب کانفیگ یک سری path را به آن میدادیم و برای نمونه aspx.* را معرفی می‌کردیم؛ یعنی این هندلر را بر روی همه‌ی فایل‌های aspx اجرا کن و اگر دو یا چند هندلر در وب کانفیگ معرفی کنیم و برای همه مسیر aspx را قرار بدهیم، یعنی همه این هندلرها باید روی صفحات aspx اجرا گردند ولی در httphandlerfactory، ما چند هندلر داریم و میخواهیم فقط یکی از آن‌ها بر روی صفحات aspx انجام بگیرد، پس ما یک هندلرفکتوری را برای صفحات aspx معرفی می‌کنیم و در حین اجرا تصمیم می‌گیریم که کدام هندلر را ارسال کنیم.
اجازه بدهید نوشتن این نوع کلاس را آغاز کنیم،ابتدا دو هندلر به نام‌های httphandler1 و httphandler2 می‌نویسیم :
public class MyHttpHandler1 :IHttpHandler
{
   
    public void ProcessRequest(HttpContext context)
    {
        HttpResponse response = context.Response;
        response.Write("this is httphandler1");
    }

    public bool IsReusable
    {
        get { return false; }
    }
}

public class MyHttpHandler2 : IHttpHandler
{

    public void ProcessRequest(HttpContext context)
    {
        HttpResponse response = context.Response;
        response.Write("this is httphandler2");
    }

    public bool IsReusable
    {
        get { return false; }
    }
}
سپس کلاس MyFactory را بر اساس اینترفیس IHttpFactory پیاده سازی می‌کنیم و باید دو متد برای آن صدا بزنیم؛ یکی که هندلر انتخابی را بر میگرداند و دیگری هم برای رها کردن یا آزادسازی یک هندلر هست که در این مقاله کاری با آن نداریم. عموما GC دات نت در این زمینه کارآیی خوبی دارد. در قسمت هندلرهای غیرهمزمان به طور مختصر خواهیم گفت که GC چطور آن‌ها را مدیریت می‌کند. کد زیر نمونه کلاسی است که توسط IHttpFactory پیاده سازی شده است:
public class MyFactory : IHttpHandlerFactory
{
    public IHttpHandler GetHandler(HttpContext context, string requestType, string url, string pathTrasnlated)
    {
        
    }

    public void ReleaseHandler(IHttpHandler handler)
    {
        
    }
}
در متد GetHandler چهار آرگومان وجود دارند که به ترتیب برای موارد زیر به کار می‌روند:
 Context یک شی از کلاس httpcontext که دسترسی ما را برای اشیاء سروری چون response,request,session و... فراهم می‌کند.
 RequestType  مشخص می‌کند که درخواست صفحه به چه صورتی است. این گزینه برای مواردی است که verb بیش از یک مورد را حمایت می‌کند. برای مثال دوست دارید یک هندلر را برای درخواست‌های Get ارسال کنید و هندلر دیگر را برای درخواست‌های نوع Post
 URL مسیر مجازی virtual Path صفحه صدا زده شده 
 PathTranslated مسیر فیزیکی صفحه درخواست کننده را ارسال می‌کند. 
متد GetHandler را بدین شکل می‌نویسیم و میخواهیم همه صفحات aspx هندلر شماره یک را انتخاب کنند و صفحات aspx که نامشان با t شروع می‌شوند، هندلر  شماره دو را انتخاب کند:
 public IHttpHandler GetHandler(HttpContext context, string requestType, string url, string pathTrasnlated)
    {
        string handlername = "MyHttpHandler1";
        if(url.Substring(url.LastIndexOf("/")+1).StartsWith("t"))
        {
            handlername = "MyHttpHandler2";
        }

        try
        {
            return (IHttpHandler) Activator.CreateInstance(Type.GetType(handlername));
        }
        catch (Exception e) 
        {
            throw new HttpException("Error: " + handlername, e);
        }
    }

    public void ReleaseHandler(IHttpHandler handler)
    {
        
    }
}
شی Activator که برای ساخت اشیاء با انتخاب بهترین constructor موجود بر اساس یک نوع Type مشخص به کار می‌رود و خروجی Object را می‌گرداند؛ با یک تبدیل ساده، خروجی به قالب اصلی خود باز میگردد. برای مطالعه بیشتر در مورد این کلاس به اینجا و اینجا مراجعه کنید.
نحوه‌ی تعریف factory در وب کانفیگ مانند قبل است و فقط باید در Type به جای نام هندلر نام فکتوری را نوشت. برنامه را اجرا کنید تا نتیجه آن را ببینیم:
تصویر زیر نتیجه صدا زده شدن فایل default.aspx است:

تصویر زیر نتیجه صدا زده شدن فایل Tours_List.aspx است:

AsyncHttpHandlers
برای اینکه کار این اینترفیس را درک کنید بهتر هست اینجا را مطالعه کنید. در اینجا به خوبی تفاوت متدهای همزمان و غیرهمزمان توضیح داده شده است.
متن زیر خلاصه‌ترین و بهترین توضیح برای این پرسش است، چرا غیرهمزمان؟
در اعمالی که disk I/O و یا network I/O دارند، پردازش موازی و اعمال async به شدت مقیاس پذیری سیستم را بالا می‌برند. به این ترتیب worker thread جاری (که تعداد آن‌ها محدود است)، سریعتر آزاد شده و به worker pool بازگشت داده می‌شود تا بتواند به یک درخواست دیگر رسیده سرویس دهد. در این حالت می‌توان با منابع کمتری، درخواست‌های بیشتری را پردازش کرد. 
موقعی که اینترفیس IHttpAsyncHandler را ارث بری کنید (این اینترفیس نیز از IHttpHandler ارث بری کرده است و دو متد اضافه‌تر دارد)، باید دو متد دیگر را نیز پیاده سازی کنید:
 public IAsyncResult BeginProcessRequest(HttpContext context, AsyncCallback callback, object obj)
    {
        
    }

    public void EndProcessRequest(IAsyncResult result)
    {
        
    }
پراپرتی ISResuable هم موقعی که true برگشت بدهد، باعث می‌شود pooling فعال شده و این هندلر در حافظه باقی بماند و تمامی درخواست‌ها از طریق همین یک نمونه اجرا شوند.
به زبان ساده‌تر، این پراپرتی می‌گوید اگر چندین درخواست از طرف کلاینت‌ها برسد، توسط یک نمونه یا instance از هندلر پردازش خواهند شد؛ چون به طور پیش فرض موقعی که تمام درخواست‌های از pipeline بگذرند، هندلر‌ها توسط httpapplication در یک لیست بازیافت قرار گرفته و همه‌ی آن‌ها با null مقداردهی می‌شوند تا از حافظه پاک شوند ولی اگر این پراپرتی true برگرداند، هندلر مربوطه نال نشده و برای پاسخگویی به درخواست‌های بعدی در حافظه خواهد ماند.
مهمترین مزیت این گزینه، این می‌باشد که کاآیی سیستم را بالا می‌برد و اشیا کمتری به GC پاس می‌شوند. ولی یک عیب هم دارد که این تردهایی که ایجاد می‌کند، امنیت کمتری دارند و باید توسط برنامه نویس این امنیت بالاتر رود. این پراپرتی را در مواقعی که با هندلرهای همزمان کار می‌کنید برابر با false بگذارید چون این گزینه بیشتر بر روی هندلرهای غیرهمزمان اثر دارد و هم اینکه بعضی‌ها توصیه می‌کنند که false بگذارید چون GC مدیریت خوبی در مورد هندلرها دارد و هم این که ارزش یافتن باگ در کد را ندارد.
بر میگردیم سراغ کد نویسی هندلر غیر همزمان. در آخرین قطعه کد نوشته شده، ما دو متد دیگر را پیاده سازی کردیم که یکی از آن‌ها BeginProcessRequest  است و خروجی آن کلاسی است که از اینترفیس IAsyncResult  ارث بری کرده است. پس یک کلاس با ارث بری از این اینترفیس می‌نویسیم و در این کلاس نیاز است که 4 پراپرتی را پیاده سازی کنیم که این کلاس به شکل زیر در خواهد آمد:
public class AsynchOperation : IAsyncResult
{
    private bool _completed;
    private Object _state;
    private AsyncCallback _callback;
    private HttpContext _context;

    bool IAsyncResult.IsCompleted { get { return _completed; } }
    WaitHandle IAsyncResult.AsyncWaitHandle { get { return null; } }
    Object IAsyncResult.AsyncState { get { return _state; } }
    bool IAsyncResult.CompletedSynchronously { get { return false; } }
}
متدهای private اجباری نیستند؛ ولی برای ذخیره مقادیر get و set نیاز است. همانطور که از اسامی آن‌ها پیداست مشخص است که برای چه کاری ساخته شده اند.
خب اجازه بدهید یک تابع سازنده به آن برای مقداردهی اولیه این متغیرهای خصوصی داشته باشیم:
   public AsynchOperation(AsyncCallback callback, HttpContext context, Object state)
    {
        _callback = callback;
        _context = context;
        _state = state;
        _completed = false;
    }
همانطور که می‌بینید موارد موجود در متد BeginProcessRequest را تحویل می‌گیریم تا اطلاعات درخواستی مربوطه را داشته باشیم و مقدار _Completed را هم برابر با false قرار می‌دهیم. سپس نوبت این می‌رسد که ما درخواست را در صف pool قرار دهیم. برای همین تکه کد زیر را اضافه می‌کنیم: 
   public void StartAsyncWork()
    {
        ThreadPool.QueueUserWorkItem(new WaitCallback(StartAsyncTask),null);
    }
با اضافه شدن درخواست به صف، هر موقع درخواست‌های قبلی تمام شوند و callback خودشان را ارسال کنند، نوبت درخواست‌های جدیدتر هم میرسد. StartAsyncTask هم متدی است که وظیفه‌ی اصلی پردازش درخواست را به دوش دارد و موقعی که نوبت درخواست برسد، کدهای این متد اجرا می‌گردد که ما در اینجا مانند مثال اول روی صفحه چیزی نوشتیم:
 private void StartAsyncTask(Object workItemState)
    {

        _context.Response.Write("<p>Completion IsThreadPoolThread is " + Thread.CurrentThread.IsThreadPoolThread + "</p>\r\n");

        _context.Response.Write("Hello World from Async Handler!");
        _completed = true;
        _callback(this);
    }
دو خط اول اطلاعات را چاپ کرده و در خط سوم متغیر _completed را true کرده و در آخر این درخواست را فراخوانی مجدد می‌کنیم تا بگوییم که کار این درخواست پایان یافته‌است؛ پس این درخواست را از صف بیرون بکش و درخواست بعدی را اجرا کن.
نهایتا کل این کلاس را در متد BeginProcessRequest  صدا بزنید:
context.Response.Write("<p>Begin IsThreadPoolThread is " + Thread.CurrentThread.IsThreadPoolThread + "</p>\r\n");
        AsynchOperation asynch = new AsynchOperation(callback, context, obj);
        asynch.StartAsyncWork();
        return asynch;
کل کد مربوطه : (توجه:کدها از داخل سایت msdn برداشته شده است و اکثر کدهای موجود در نت هم به همین قالب می‌نویسند)
public class MyHttpHandler : IHttpAsyncHandler
{
    public IAsyncResult BeginProcessRequest(HttpContext context, AsyncCallback callback, object obj)
    {
        context.Response.Write("<p>Begin IsThreadPoolThread is " + Thread.CurrentThread.IsThreadPoolThread + "</p>\r\n");
        AsynchOperation asynch = new AsynchOperation(callback, context, obj);
        asynch.StartAsyncWork();
        return asynch;
    }

    public void EndProcessRequest(IAsyncResult result)
    {
        
    }
    public void ProcessRequest(HttpContext context)
    {
       throw new InvalidOperationException(); 

    }

    public bool IsReusable
    {
        get { return false; }
    }
}

public class AsynchOperation : IAsyncResult
{
    private bool _completed;
    private Object _state;
    private AsyncCallback _callback;
    private HttpContext _context;

    bool IAsyncResult.IsCompleted { get { return _completed; } }
    WaitHandle IAsyncResult.AsyncWaitHandle { get { return null; } }
    Object IAsyncResult.AsyncState { get { return _state; } }
    bool IAsyncResult.CompletedSynchronously { get { return false; } }

    public AsynchOperation(AsyncCallback callback, HttpContext context, Object state)
    {
        _callback = callback;
        _context = context;
        _state = state;
        _completed = false;
    }


    public void StartAsyncWork()
    {
        
        ThreadPool.QueueUserWorkItem(new WaitCallback(StartAsyncTask),null);

    }
    private void StartAsyncTask(Object workItemState)
    {

        _context.Response.Write("<p>Completion IsThreadPoolThread is " + Thread.CurrentThread.IsThreadPoolThread + "</p>\r\n");

        _context.Response.Write("Hello World from Async Handler!");
        _completed = true;
        _callback(this);
    }

آشنایی با فایل ASHX
در مطالب بالاتر به فایل‌های Ashx اشاره کردیم. این فایل به نام Generic Web Handler شناخته می‌شوند و می‌توانید با Add New Item این نوع فایل‌ها را اضافه کنید. این فایل شامل هیچ UI ایی نمی‌باشد و فقط شامل بخش کد می‌باشد. برای همین نسبت به aspx سبک‌تر بوده و شامل یک directive به اسم  WebHandler@ است.
مایکروسافت در MSDN نوشته است که httphandler‌ها در واقع فرآیندهایی هستند (به این فرایندها بیشتر End Point می‌گویند) که در پاسخ به درخواست‌های رسیده شده توسط asp.net application اجرا می‌شوند و بیشترین درخواست هایی هم که می‌رسد از نوع صفحات Aspx می‌باشد و موقعی که کاربری درخواست صفحه‌ی aspx می‌کند هندلرهای مربوط به page اجرا می‌شوند.
در متن بالا به خوبی روشن هست که ashx به دلیل نداشتن UI، تعداد کمتری از handlerها را در مسیر Pipeline قرار می‌دهند و اجرای آن‌ها سریعتر است. غیر از این دو هندلر aspx و ashx، هندلر توکار دیگری چون asmx که مختص وب سرویس هست و axd مربوط به اعمال trace نیز وجود دارند.

در این لینک که در بالاتر هم درج شده بود یک نمونه هندلر برای نمایش تصویر نوشته است. اگر تصاویرتان را بدین صورت اجرا کنید می‌توان جلوی درخواست‌های رسیده از وب سایت‌های دیگر را سد کرد. برای مثال یک نفر مطالب شما را کپی می‌کند و در داخل وبلاگ یا وب سایتش می‌گذارد و شما در اینجا درخواست‌های رسیده خارج از وب سایت خود را لغو خواهید کرد و تصاویر کپی شده نمایش داده نخواهند شد.
نظرات مطالب
مهارت‌های تزریق وابستگی‌ها در برنامه‌های NET Core. - قسمت چهارم - پرهیز از الگوی Service Locator در برنامه‌های وب
ارتقاء به ASP.NET Core 3.0: محدود شدن امکان تزریق وابستگی‌ها در سازنده‌ی کلاس آغازین برنامه

یکی از تغییرات مهم ASP.NET Core 3.0 نسبت به نگارش‌های قبلی، جنریک شدن Host آن است (چون حالت‌های هاستینگ بیشتری را نسبت به حالت صرف MVC پشتیبانی می‌کند). به این ترتیب HostBuilder نگارش 2x:
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
                 WebHost.CreateDefaultBuilder(args)
                 .UseStartup<Startup>();
اکنون در نگارش 3x به این صورت در آمده‌است:
public static IHostBuilder CreateHostBuilder(string[] args) =>
               Host.CreateDefaultBuilder(args)
                     .ConfigureWebHostDefaults(webBuilder =>
                     {
                        webBuilder.UseStartup<Startup>();
                     });
این مورد، یک تغییر مهم را هم در وضعیت تزریق وابستگی‌های سفارشی در کلاس آغازین برنامه ایجاد کرده‌است: در نگارش 3x، فقط و فقط سرویس‌های IHostEnvironment ،IWebHostEnvironment و IConfiguration را می‌توانید به سازنده‌ی کلاس آغازین آن تزریق کنید.
علت اینجا است که در ASP.NET Core 3x، یک باگ بسیار مهم سیستم تزریق وابستگی‌های ASP.NET Core برطرف شده‌است: اکنون فقط یک dependency injection container به ازای کل برنامه‌ی ASP.NET Core 3x ساخته می‌شود. در نگارش‌های قبلی، یک container برای برنامه و یک container مجزا برای host تولید می‌شدند. در این حالت اگر یک سرویس Singleton را در فایل program.cs معرفی می‌کردید:
WebHost.CreateDefaultBuilder()
             .UseStartup<Startup>()
             .ConfigureServices(services => 
                     services.AddSingleton<MySingleton>())
             .Build()
             .Run();
برخلاف تصور، این سرویس Singleton رفتار نمی‌کرد؛ چون همانطور که عنوان شد، دو container، برنامه را مدیریت می‌کردند (یعنی دوبار توسط دو ظرف متفاوت نگهدارنده‌ی اشیاء، وهله سازی می‌شد) که اکنون در نگارش 3x به یک مورد کاهش یافته‌است.
در اینجا هرچند متد ConfigureServices وجود دارد، اما اگر از آن استفاده کنید، سرویس معرفی شده‌ی توسط آن، در سازنده‌ی کلاس Startup شناسایی نمی‌شود.
مطالب
Angular CLI - قسمت اول - نصب و راه اندازی
از زمان Angular 2 به بعد، تنها یک نام برای نگارش‌های جدید آن درنظر گرفته شده‌است و آن هم «Angular» است. بنابراین در اینجا منظور از Angular همان +AngularJS 2.0 است.
ایجاد و توزیع برنامه‌های جدید AngularJS به همراه تمام وابستگی‌های آن‌ها و همچنین رعایت بهترین تجربه‌های کاری آن، اندکی مشکل است. به همین جهت تیم Angular برنامه‌ای را به نام Angular CLI تدارک دیده‌است که تمام این مراحل را به سادگی هرچه تمام‌تر مدیریت می‌کند. ممکن است قالب‌های زیادی را در مورد شروع به کار با AngularJS 2.0+ در وب پیدا کنید؛ اما هیچکدام از آن‌ها تمام قابلیت‌های Angular CLI را ارائه نمی‌دهند و همواره چندین قدم عقب‌تر از تیم Angular هستند. به همین جهت در طی یک سری قصد داریم قابلیت‌های گوناگون این ابزار را بررسی کنیم.


Angular CLI چیست؟

ایجاد برنامه‌های جدید Angular لذت بخش هستند؛ اما ایجاد برنامه‌هایی که از بهترین تجربه‌های کاری توصیه شده‌ی توسط تیم Angular پیروی می‌کنند، به همراه Unit tests هستند و همچنین برای توزیع بهینه سازی شده‌اند، بسیار چالش برانگیز می‌باشند. به همین جهت برنامه‌ی خط فرمانی به نام Angular CLI برای مدیریت این مسایل توسط تیم Angular ایجاد شده‌است، تا توسعه دهندگان بیشتر وقت خود را صرف بهینه سازی کدهای خود کنند تا اینکه درگیر تدارک مسایل جانبی این فریم ورک باشند.
اگر به پروژه‌های سورس باز ارائه شده‌ی جهت شروع کار با +AngularJS 2.0 دقت کنید، تعداد بی‌شماری پروژه‌ی seed، قالب‌های آماده، کدساز و غیره را خواهید یافت. اکثر آن‌ها تفاوت‌های قابل ملاحظه‌ای را با یکدیگر داشته و در اغلب موارد بهترین تجربه‌های کاری Angular را نیز رعایت نمی‌کنند. برای مثال خبری از style guide آن و یا مباحث بهینه سازی ساخت و توزیع لحاظ شده‌ی در نگارش‌های جدید Angular، در آن‌ها نیست.
در اینجا بود که تیم Angular تصمیم گرفت تا در جهت ساماندهی به این وضعیت آشفته، برنامه‌ی Angular CLI را ایجاد کند تا برنامه نویس‌ها به همراه ابزاری باشند که بر اساس بهترین تجربه‌های کاری Angular تهیه شده‌است؛ سبب ایجاد برنامه‌هایی خواهد شد که یکدست به نظر می‌رسند و همچنین همواره آخرین تغییرات توزیع و آزمایش برنامه‌ها را نیز به همراه دارد.


پیشنیازهای نصب Angular CLI

پیش از شروع به نصب Angular CLI باید مطمئن شوید که آخرین نگارش NodeJS را نصب کرده‌اید. برای این منظور خط فرمان را گشوده و دستور ذیل را صادر کنید:
C:\>node -v
v5.10.1
در اینجا نگارش نصب شده‌ی بر روی سیستم من 5.10 است که برای کار با Angular CLI مناسب نیست و این برنامه‌ی خط فرمان، حداقل نیاز به نصب نگارش 6.9 آن‌را دارد. به همین جهت نیاز است به آدرس https://nodejs.org/en/download مراجعه کرده و آخرین نگارش node.js را دریافت و نصب کرد.

اگر این مطلب را در چند ماه بعد پس از نگارش آن مطالعه می‌کنید، به پروژه‌ی Angular CLI مراجعه کرده و قسمت Prerequisites مستندات ابتدایی آن‌را برای مشاهده‌ی آخرین نگارش NodeJS مورد نیاز آن، بررسی کنید.


نصب Angular CLI

پس از نصب پیشنیاز آن، اکنون خط فرمان را گشوده و دستور ذیل را صادر کنید:
 C:\>npm install -g @angular/cli
به این ترتیب پس از چند دقیقه، Angular CLI به صورت global و عمومی نصب خواهد شد.

پس از نصب آن، جهت اطمینان از عملیات انجام شده، دستور ذیل را در خط فرمان صادر کنید:
 C:\>npm list -g @angular/cli --depth=0
کار سوئیچ list، ارائه گزارشی از بسته‌های عمومی نصب شده‌ی با نام angular/cli@ است. depth=0 به این معنا است که نیازی به تهیه لیستی از وابستگی‌های آن نیست. برای نمونه خروجی آن می‌تواند به صورت ذیل باشد:
 C:\>npm list -g @angular/cli --depth=0
C:\Users\Vahid\AppData\Roaming\npm
`-- @angular/cli@1.0.0

و همچنین برای مشاهده‌ی نگارش CLI نصب شده، دستور ذیل را اجرا نمائید:
C:\>ng -v
    _                      _                 ____ _     ___
   / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
  / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
 / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
/_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
               |___/
@angular/cli: 1.0.0
node: 6.10.2
os: win32 x64
در اینجا ng همان Angular CLI است.


ایجاد یک برنامه‌ی جدید توسط Angular CLI

پس از نصب Angular CLI، اکنون می‌توان از آن جهت ساخت یک برنامه‌ی جدید Angular استفاده کرد. برای این منظور یک پوشه‌ی جدید را ایجاد کرده و سپس از طریق خط فرمان به آن وارد شده (نگه داشتن دکمه‌ی shift و سپس کلیک راست و انتخاب گزینه‌ی Open command window here) و دستور ذیل را صادر کنید:
> ng new ngtest --skip-install
ng به معنای اجرای Angular CLI است. پارامتر new آن سبب ایجاد یک برنامه‌ی جدید خواهد شد و پارامتر skip-install آن، کار فراخوانی خودکار npm install را لغو می‌کند. به این ترتیب می‌توان در سریعترین زمان ممکن، یک برنامه‌ی Angular را ایجاد کرد.


در اینجا ساختار یک پروژه‌ی جدید Angular را مشاهده می‌کنید.
فایل
توضیحات
 .angular-cli.json   تنظیمات cli را به همراه دارد.
 editorconfig   مربوط به تنظیمات VSCode است.
 karma.conf.js   برای انجام unit tests است. 
 package.json    وابستگی‌های npm برنامه را به همراه دارد (که در زمان نگارش این مطلب تنظیمات Angular 4 را به همراه دارد). 
 protractor.conf.js   برای اجرای آزمون‌های end to end که در اینجا e2e نام گرفته‌است، می‌باشد. 
 tsconfig.json   تنظیمات کامپایلر TypeScript را به همراه دارد. 
 tslint.json   جهت اجرای Lint و ارائه‌ی بهترین تجربه‌های کاری با TypeScript است. 

داخل پوشه‌ی src، فایل‌های اصلی پروژه قرار دارند:

- فایل index.html کار ارائه و شروع برنامه را انجام می‌دهد.
- فایل main.ts نقطه‌ی آغاز برنامه است.

با توجه به استفاده‌ی از پارامتر skip-install، هنوز وابستگی‌های فایل package.json نصب نشده‌اند. برای این منظور به پوشه‌ی اصلی پروژه وارد شده (جایی که پوشه‌ی ngtest و فایل package.json قرار دارد) و دستور npm install را صادر کنید تا وابستگی‌های برنامه نیز دریافت شوند. البته اگر از پارامتر یاد شده استفاده نمی‌شد، اینکار به صورت خودکار توسط ng new  انجام می‌گرفت.
>npm install


به این ترتیب وابستگی‌های پروژه در پوشه‌ی node_modules تشکیل خواهند شد.


به روز رسانی Angular CLI

روش به روز رسانی AngularCLI شامل این مراحل است:
الف) به روز رسانی بسته‌ی عمومی نصب شده‌ی آن
npm uninstall -g @angular/cli
npm cache clean
npm install -g @angular/cli@latest
ابتدا باید نگارش موجود عزل شود. سپس cache قدیمی مربوط به npm نیز باید پاک شود و پس از آن نیاز است مجددا آخرین نگارش cli نصب گردد.

ب) به روز رسانی یک برنامه‌ی محلی
در ادامه به پوشه‌ی برنامه‌ی خود وارد شده و دستورات ذیل را اجرا کنید:
rm rmdir /S/Q node_modules dist
npm install --save-dev @angular/cli@latest
npm install
این دستورات ابتدا پوشه‌های node_modules و همچنین dist قبلی را پاک می‌کنند. دستور بعدی، کار به روز رسانی وابستگی‌های package.json را انجام می‌دهد و در آخر دستور npm install، تغییرات فایل package.json را دریافت و نصب می‌کند.

مورد «الف» را به ازای هر نگارش جدید CLI، تنها یکبار باید انجام داد. اما مورد «ب» به ازای هر پروژه‌ی موجود باید یکبار انجام شود (که سریعترین روش به روز رسانی وابستگی‌های یک برنامه، به آخرین نگارش Angular است).