اشتراک‌ها
کتاب ASP.NET MVC 5: A Beginner’s Guide

Table of Contents
  • Introduction
  • Prerequisites
  • Environment Settings and Tools Used
  • Getting Started
  • Brief Overview of ASP.NET MVC
  • Creating a Database
  • Creating Database Tables
  • Adding a New ASP.NET MVC 5 Project
  • Setting Up the Data Access using Entity Framework Database-First approach
  • Creating a Signup Page
  • Creating the Login Page
  • Implementing a Simple Role-Based Page Authorization
  • Implementing Fetch, Edit, Update and Delete Operations
  • Creating a User Profile Page
  • Implementing a ShoutBox Feature
  • Deploying Your ASP.NET MVC 5 App to IIS8
  • Summary 
کتاب ASP.NET MVC 5: A Beginner’s Guide
نظرات مطالب
امن سازی برنامه‌های ASP.NET Core توسط IdentityServer 4x - قسمت ششم - کار با User Claims
یک نکته‌ی تکمیلی: تعریف بیشتر از یک role سبب بروز خطا می‌شود
اگر در برنامه آرایه‌ای از claims مانند آرایه‌ای از roles تعریف شود، به خطای زیر برخواهید خورد:
An unhandled exception occurred while processing the request.
InvalidCastException: Cannot cast Newtonsoft.Json.Linq.JArray to Newtonsoft.Json.Linq.JToken.
Newtonsoft.Json.Linq.Extensions.Convert<T, U>(T token)

Exception: An error was encountered while handling the remote login.
Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler.HandleRequestAsync
مشکل اینجا است که نگاشت زیر:
options.ClaimActions.MapUniqueJsonKey(claimType: "role", jsonKey: "role");
به همراه واژه‌ی Unique است؛ یعنی یک آرایه را نمی‌پذیرد و به همین جهت است که عنوان می‌کند JArray دریافتی، قابل تبدیل به JToken نیست. برای رفع این مشکل می‌توان از متد زیر استفاده کرد:
options.ClaimActions.MapJsonKey(claimType: "role", jsonKey: "role"); // for having 2 or more roles
نظرات مطالب
معماری لایه بندی نرم افزار #3

- من در عمل تفاوتی بین لایه مخزن و سرویس شما مشاهده نمی‌کنم. یعنی لایه مخزن داره GetAll می‌کنه، بعد لایه سرویس هم داره همون رو به یک شکل دیگری بر می‌گردونه. این تکرار کد نیست؟ این دو یکی نیستند؟

عموما در منابع لایه مخزن رو به صورت روکشی برای دستورات مثلا EF یا LINQ to SQL معرفی می‌کنند. فرضشون هم این است که این روش ما رو از تماس مستقیم با ORM برحذر می‌داره (شاید فکر می‌کنند ایدز می‌گیرند اگر مستقیم کار کنند!). ولی عرض کردم این روکش در واقعیت فقط شاید با EF یا L2S قابل تعویض باشه نه با ORMهای دیگر با روش‌های مختلف و بیشتر یک تصور واهی هست که جنبه عملی نداره. بیشتر تئوری هست بدون پایه تجربه دنیای واقعی. ضمن اینکه این روکش باعث میشه نتونید از خیلی از امکانات ORM مورد استفاده درست استفاده کنید. مثلا ترکیب کوئری‌ها یا روش‌های به تاخیر افتاده و امثال این.

- پس در عمل شما Request ViewModel و Response ViewModel تعریف کردید.

مطالب
آشنایی با چالش های امنیتی در توسعه برنامه‌های تحت وب، بخش اول
در پروژه‌های بزرگ نرم افزاری، از قدیم بحث تامین امنیت پروژه، یکی از چالش‌های مهم بوده است. از دیدگاه شخصی بنده، یک مدیر نرم افزار یا حتی یک توسعه دهنده‌ی برنامه‌های تحت وب، لازم است علاوه بر صرف وقت مطالعاتی و آشنایی و تسلط بر مباحث طراحی معماری سیستم‌های تحت وب، که از اهمیت بالا و مقیاس بزرگی برخوردارند آشنایی لازم را با چالش‌های امنیتی در پیاده سازی اینگونه سیستم‌ها داشته باشد. امنیت در یک سیستم بزرگ و ارائه دهنده خدمات، باعث می‌شود تا کاربر علاوه بر یک تجربه کاربری (user experience) خوب از سیستم که حاصل پیاده سازی صحیح سیستم می‌باشد، اعتماد ویژه‌ای به سیستم مذکور داشته باشد. گاها کاربران به علت بی اعتمادی به شرایط امنیتی حاکم بر یک سیستم، از تجربه کاربری خوب یک سیستم چشم پوشی می‌کنند. اهمیت این مسئله تا جاییست که غول‌های تکنولوژی دنیا همچون Google درگیر این چالش می‌باشند و همیشه سعی بر تامین امنیت کاربران علاوه بر ایجاد تجربه کاربری خوب دارند. پس عدم توجه به این موضوع میتواند خسارات وارده جبران ناپذیری را به یک سیستم از جهت‌های مختلف وارد کند.

در این سری از مقالات، بنده سعی دارم تا حد توان در رابطه با چالش‌های امنیتی موجود در زمینه توسعه برنامه‌های تحت وب، مطالبی را منتشر کنم. از این رو امیدوارم تا این سری از مقالات برای دوستان مفید واقع گردد.

در این سری از مقالات چالش‌های امنیتی زیر مورد بحث و بررسی واقع خواهند گردید 

XSS , LDAPi ,RFI ,LFI ,SQLi ,RFD ,LFD ,SOF ,BSQLI ,DNN ,BOF ,CRLF ,CSRF ,SSI ,PCI ,SCD ,AFD ,RCE

در بخش اول از این سری مقالات ، به بررسی آسیب پذیری Cross-site scripting میپردازیم .

واژه XSS مخفف Cross-site scripting، نوعی از آسیب پذیریست که در برنامه‌های تحت وب نمود پیدا میکند. به طور کلی و خلاصه، این آسیب پذیری به فرد نفوذ کننده اجازه تزریق اسکریپت‌هایی را به صفحات وب، می‌دهد که در سمت کاربر اجرا می‌شوند ( Client Side scripts ) . در نهایت این اسکریپت‌ها توسط سایر افرادی که از صفحات مورد هدف قرار گرفته بازدید می‌کنند اجرا خواهد شد.

هدف از این نوع حمله :

بدست آوردن اطلاعات کوکی‌ها و سشن‌های کاربران ( مرتبط با آدرسی که صفحه آلوده شده در آن قرار دارد ) است. سپس فرد نفوذ کننده متناسب با اطلاعات بدست آمده می‌تواند به اکانت شخصی کاربران مورد هدف قرار گرفته، نفوذ کرده و از اطلاعات شخصی آن‌ها سوء استفاده کند .

به صورت کلی دو طبقه بندی برای انواع حملات Cross-site scripting وجود دارند.

حملات XSS ذخیره سازی شده ( Stored XSS Attacks ) :

در این نوع ، کدهای مخرب تزریق شده، در سرور سایت قربانی ذخیره میشوند. محل ذخیره سازی می‌تواند دیتابیس سایت یا هر جای دیگری که داده‌ها توسط سایت یا برنامه تحت وب بازیابی می‌شوند و نمایش داده می‌شوند باشد. اما اینکه چگونه کدهای مخرب در منابع یاد شده ذخیره میشوند؟

فرض کنید در سایت جاری آسیب پذیری مذکور وجود دارد. راه‌های ارسال داده‌ها به این سایت چیست؟ نویسندگان میتوانند مطلب ارسال کنند و کاربران میتوانند نظر دهند. حال اگر در یکی از این دو بخش بررسی‌های لازم جهت مقابله با این آسیب پذیری وجود نداشته باشد و نوشته‌های کاربران که می‌تواند شامل کدهای مخرب باشد مستقیما در دیتابیس ذخیره شده و بدون هیچ اعتبار سنجی نمایش داده شود چه اتفاقی رخ خواهد داد؟ مسلما با بازدید صفحه آلوده شده، کدهای مخرب بر روی مرورگر شما اجرا و کوکی‌های سایت جاری که متعلق به شما هستند برای هکر ارسال میشود و ...

حملات XSS منعکس شده ( Reflected XSS Attacks ) :

در این نوع از حمله، هیچ نوع کد مخربی در منابع ذخیره سازی وبسایت یا اپلیکیشن تحت وب توسط فرد مهاجم ذخیره نمی‌شود ! بلکه از ضعف امنیتی بخش‌هایی همچون بخش جستجو وب سایت، بخش‌های نمایش پیغام خطا و ... استفاده میشود ... اما به چه صورت؟

در بسیاری از سایت‌ها، انجمن‌ها و سیستم‌های سازمانی تحت وب، مشاهده می‌شود که مثلا در بخش جستجو، یک فیلد برای وارد کردن عبارت جستجو وجود دارد. پس از وارد کردن عبارت جستجو و submit فرم، علاوه بر نمایش نتایج جستجو، عبارت جستجو شده نیز به نمایش گذاشته میشود و بعضا در بسیاری از سیستم‌ها این عبارت قبل از نمایش اعتبار سنجی نمی‌شود که آیا شامل کدهای مخرب می‌باشد یا خیر. همین امر سبب میشود تا اگر عبارت جستجو شامل کدهای مخرب باشد، آن‌ها به همراه نتیجه‌ی جستجو اجرا شوند.

اما این موضوع چگونه مورد سوء استفاده قرار خواهد گرفت؟ مگر نه اینکه این عبارت ذخیره نمیشود پس با توضیحات فوق، کد فقط بر روی سیستم مهاجم که کد جستجو را ایجاد می‌کند اجرا می‌شود، درست است؟ بله درست است ولی به نقطه ضعف زیر توجه کنید ؟

www.test.com/search?q=PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpOzwvc2NyaXB0Pg==

این آدرس حاصل submit  شدن فرم جستجو وب‌سایت test (نام وب‌سایت واقعی نیست و برای مثال است )  و ارجاع به صفحه نتایج جستجو میباشد. در واقع این لینک برای جستجوی یک کلمه یا عبارت توسط این وبسایت تولید شده و از هر کجا به این لینک مراجعه کنید عبارت مورد نظر مورد جستجو واقع خواهد شد. در واقع عبارت جستجو به صورت Base64 به عنوان یک query String به وبسایت ارسال می‌شود؛ علاوه بر نمایش نتایج، عبارت جستجو شده نیز به کاربر نشان داده شده و اگر آسیب پذیری مورد بحث وجود داشته باشد و عبارت شامل کدهای مخرب باشد، کدهای مخرب بر روی مرورگر فردی که این لینک را باز کرده اجرا خواهد شد!

در این صورت کافیست فرد مهاجم لینک مخرب را به هر شکلی به فرد مورد هدف بدهد ( مثلا ایمیل و ... ). حال در صورتیکه فرد لینک را باز کند (با توجه به اینکه لینک مربوط به یک سایت معروف است و عدم آگاهی کاربر از آسیب پذیری موجود در لینک، باعث باز کردن لینک توسط کاربر می‌شود)، کدها بر روی مرورگرش اجرا شده و کوکی‌های سایت مذکور برای مهاجم ارسال خواهد شد ... به این نوع حمله XSS   ، نوع انعکاسی می‌گویند که کاملا از توضیحات فوق الذکر، دلیل این نامگذاری مشخص می‌باشد.

اهمیت مقابله با این حمله :

برای نمونه این نوع باگ حتی تا سال گذشته در سرویس ایمیل یاهو وجود داشت. به شکلی که یکی از افراد انجمن hackforums به صورت Private این باگ را به عنوان Yahoo 0-Day XSS Exploit در محیط زیر زمینی و بازار سیاه هکرها به مبلغ چند صد هزار دلار به فروش می‌رساند. کاربران مورد هدف کافی بود تا فقط یک ایمیل دریافتی از هکر را باز کنند تا کوکی‌های سایت یاهو برای هکر ارسال شده و دسترسی ایمیل‌های فرد قربانی برای هکر فراهم شود ... ( در حال حاظر این باگ در یاهو وجو ندارد ).

چگونگی جلوگیری از این آسیب پذیری

در این سری از مقالات کدهای پیرامون سرفصل‌ها و مثال‌ها با ASP.net تحت فریم ورک MVC و به زبان C# خواهند بود. هر چند کلیات مقابله با آسیب پذیری هایی از این دست در تمامی زبان‌ها و تکنولوژی‌های تحت وب یکسان میباشند.

خوشبختانه کتابخانه‌ای قدرتمند برای مقابله با حمله مورد بحث وجود دارد با نام AntiXSS که میتوانید آخرین نسخه آن را با فرمان زیر از طریق nugget به پروژه خود اضافه کنید. البته ذکر این نکته حائز اهمیت است که Asp.net و فریم ورک MVC به صورت توکار تا حدودی از بروز این حملات جلوگیری می‌کند. برای مثال به این صورت که در View ‌ها شما تا زمانی که از MvcHtmlString استفاده نکنید تمامی محتوای مورد نظر برای نمایش به صورت Encode شده رندر می‌شوند. این داستان برای Url ‌ها هم که به صورت پیش فرض encode میشوند صدق می‌کند. ولی گاها وقتی شما برای ورود اطلاعات مثلا از یک ادیتور WYSWYG استفاده می‌کنید و نیاز دارید داده‌ها را بدون encoding رندر کنید. آنگاه به ناچار مجاب بر اعمال یک سری سیاست‌های خاص‌تر بر روی داده مورد نظر برای رندر می‌شوید و نمی‌توانید از encoding توکار فوق الذکر استفاده کنید. آنگاه این کتابخانه در اعمال سیاست‌های جلوگیری از بروز این آسیب پذیری می‌تواند برای شما مفید واقع شود.

 PM> Install-Package AntiXSS
این کتابخانه مجموعه‌ای از توابع کد کردن عبارات است که از مواردی همچون Html, XML, Url, Form, LDAP, CSS, JScript and VBScript پشتیبانی می‌کند. استفاده از آن بسیار ساده می‌باشد. کافیست ارجاعات لازم را به پروژه خود افزوده و به شکل زیر از توابع ارائه شده توسط این کتابخانه استفاده کنید: 
…
var reviewContent = model.UserReview;
reviewContent = Microsoft.Security.Application.Encoder.HtmlEncode(review);
…

امیدوارم در اولین بخش از این سری مقالات، به صورت خلاصه مطالب مهمی که باعث ایجاد فهم کلی در رابطه با حملات Xss وجود دارد، برای دوستان روشن شده و پیش زمینه فکری برای مقابله با این دست از حملات برایتان به وجود آمده باشد. 

نظرات مطالب
متوقف سازی حملات خودکار تزریق اس کیوال در IIS
بله. اگر کسی از یکی از ORM های موجود استفاده کند، نیازی به این بازی‌ها نخواهد داشت:
https://www.dntips.ir/2009/11/linq-to-sql.html

ولی در سایر موارد فقط کافی است یکی یک مورد را فراموش کند؛ یا پروژه‌های قدیمی هنوز برقرار باشند. بنابراین بهتر است کمی احتیاط کرد.
مطالب
C# 6 - Exception Filtering
سی‌شارپ نیز مانند بسیاری از زبان‌های شیءگرای دیگر، امکان فیلتر کردن استثناءها را بر اساس نوع آن‌ها، دارا است. برای مثال:
try
{
    // some code to check  ...
}
catch (InvalidOperationException ex)
{
    // do your handling for invalid operation ...
}
catch (IOException ex)
{
    // do your handling for IO error ...
}
در اینجا می‌توان بر اساس نوع استثنای مدنظر، چندین catch را نوشت و مدیریت کرد. اما گاهی از اوقات شاید بهتر باشد بجای مدیریت کلی یک نوع از استثناءها، فقط نوعی خاص را صرفا بر اساس شرایطی مشخص، مدیریت کرد. این قابلیت، تحت عنوان Exception Filtering به C# 6 اضافه شده‌است و شکل کلی آن به صورت ذیل است:
 catch (SomeException ex) when (someConditionIsMet)
{
    // Your handler logic
}
در این حالت ابتدا نوع استثناء بررسی می‌شود و سپس شرطی که در قسمت when ذکر شده‌است. اگر هر دو با هم برقرار بودند، آنگاه این استثنای خاص مدیریت خواهد شد؛ در غیر اینصورت، از مدیریت این نوع استثناء صرفنظر می‌گردد. این قابلیت، از ابتدای ارائه‌ی CLR وجود داشته‌است، اما C#6 تازه شروع به استفاده‌ی از آن کرده‌است (و VB.NET از چند نگارش قبل).

علاوه بر این در اینجا می‌توان چندین بدنه‌ی catch مجزا را به ازای یک نوع استثنای مشخص به همراه whenهای متفاوتی نیز تعریف کرد و از این لحاظ محدودیتی وجود ندارد. فقط در این حالت باید به تقدم و تاخرها دقت داشت. برای نمونه در مثال ذیل، ترکیب چندین شرط متفاوت را بر اساس یک نوع مشخص استثناء، مشاهده می‌کنید. در اینجا اگر برای نمونه شرط ذکر شده‌ی در قسمت when مربوط به catch اولی صادق باشد، همینجا کار خاتمه می‌یابد و سایر catchها بررسی نمی‌شوند:
 catch (SomeDependencyException ex) when (condition1 && condition2)
{
 
}
catch (SomeDependencyException ex) when (condition1)
{
 
}
catch (SomeDependencyException ex)
{
 
}
مورد آخر، حالت catch all را دارد و در صورت شکست دو catch قبلی اجرا می‌شود. اما باید دقت داشت که اگر این catch all بدون شرط و بدون قسمت when را در ابتدا ذکر کنیم، دیگر کار به بررسی سایر catchهای این نوع استثنای خاص نخواهد رسید:
 catch (SomeDependencyException ex)
{
 
}
catch (SomeDependencyException ex) when (condition1 && condition2)
{
 
}
catch (SomeDependencyException ex) when (condition1)
{
 
}
در مثال فوق هیچگاه دو catch تعریف شده‌ی پس از catch all اولی اجرا نمی‌شوند.


لاگ کردن استثناءها در C# 6 بدون مدیریت آن‌ها

به مثال ذیل دقت کنید:
 try
{
    DoSomethingThatMightFail(s);
}
catch (Exception ex) when (Log(ex, "An error occurred"))
{
    // this catch block will never be reached
}

...

static bool Log(Exception ex, string message, params object[] args)
{
   Debug.Print(message, args);
   return false;
}
در قسمت when می‌توان هر متدی که true یا false را برگرداند، فراخوانی کرد. در این مثال، متدی تعریف شده‌است که false بر می‌گرداند. یعنی این استثناء کلی از نوع Exception هرچند به ظاهر دارای قسمت when است و مدیریت شده‌است، اما چون خروجی متد Log قسمت when آن مساوی false است، مدیریت نخواهد شد. یعنی در اینجا می‌توان بدون مدیریت یک استثناء، اطلاعات کامل آن‌را لاگ کرد!


تفاوت C# 6 - Exception Filtering با if/else نوشتن در بدنه‌ی catch چیست؟

تا اینجا به این نتیجه رسیدیم که کدهای if/else دار داخل بدنه‌ی catch کدهای قدیمی را مانند کد ذیل:
try
{
    var request = WebRequest.Create("http://www.google.coom/");
    var response = request.GetResponse();
}
catch (WebException we)
{
    if (we.Status == WebExceptionStatus.NameResolutionFailure)
    {
        //handle DNS error
        return;
    }
    if (we.Status == WebExceptionStatus.ConnectFailure)
    {
        //handle connection error
        return;
    }
 
    throw;
}
می‌توان به شکل جدید C# 6 به همراه when نوشت و تبدیل کرد:
try
{
    var request = WebRequest.Create("http://www.google.coom/");
    var response = request.GetResponse();
}
catch (WebException we) when (we.Status == WebExceptionStatus.NameResolutionFailure)
{
    //Handle NameResolutionFailure Separately
}
catch (WebException we) when (we.Status == WebExceptionStatus.ConnectFailure)
{
    //Handle ConnectFailure Separately
}
اما باید دقت داشت که تفاوت مهم قطعه کد دوم، در مباحث Stack unwinding است. در مثال اولی که if/else داخل بدنه‌ی catch نوشته شده‌است، اطلاعات local محل فراخوانی متدی را که سبب بروز استثناء شده‌است، از دست خواهیم داد؛ اما در مثال دوم خیر.
به این معنا که exception filters سبب Stack unwinding نمی‌شوند. با هربار ورود به بدنه‌ی catch، اصطلاحا عملیات Stack unwinding صورت می‌گیرد. یعنی اطلاعات stack مربوط به متدهای پیش از فراخوانی متدی که سبب بروز استثناء شده‌است، از بین می‌روند. به این ترتیب تشخیص مقادیر متغیرهایی که سبب بروز این استثناء شده‌اند نیز میسر نخواهد بود و دیگر نمی‌توان با قطعیت عنوان کرد که چه مقادیری و چه اطلاعاتی سبب بروز این مشکل شده‌اند. اما در حالت exception filters در قسمت when آن هنوز وارد بدنه‌ی catch نشده‌ایم. در اینجا دسترسی کاملی به اطلاعات stack جاری و مقادیر متغیرهای محلی که سبب بروز این استثناء شده‌اند وجود دارد.

تفاوت stack با stack trace چیست؟ stack قطعه‌ای از حافظه‌است که اطلاعاتی در مورد نحوه‌ی فراخوانی متدها، آدرس بازگشتی آن‌ها، آرگومان و همچنین متغیرهای محلی آن‌ها را دارا است. اما stack trace تنها یک رشته‌است و بیانگر نام متدهایی است که هم اکنون بر روی stack قرار دارند. احتمالا پیشتر خوانده بودید که فراخوانی throw داخل بدنه‌ی catch سبب حفظ stack trace می‌شود و اگر throw ex صورت گیرد، این اطلاعات از دست می‌روند و بازنویسی می‌شوند. اما در C# 6 امکان حفظ کل اطلاعات stack به همراه exception filtering میسر شده‌است.
مطالب
نحوه‌ی استفاده از ViewComponent درون Controller
در ASP.NET Core یک View Component، در نهایت خلاصه‌ایی از قابلیت‌هایی را ارائه میدهد که قرار است توسط یک کنترلر مدیریت شوند؛ زیرا پارامترهای یک View Component از طریق یک HTTP Request تامین نمی‌شوند. یعنی به صورت مستقیم از طریق درخواست‌های HTTP قابل دسترسی نیستند. فرض کنید در یک برنامه می‌خواهیم لیست کاربران سایت را نمایش دهیم تا با کلیک بر روی نام کاربر، امکان ویرایش کاربر انتخاب شده را داشته باشیم. با کلیک بر روی لینک مورد نظر، اطلاعات درخواست، به کنترلر UserManagerController و سپس اکشن متد Edit ارسال خواهد شد. در حالت عادی باید یک ViewComponent برای لیست کاربران و همچنین یک UserManagerController، برای ویرایش کاربر درون پروژه داشته باشیم:
public class UserListViewComponent : ViewComponent
{
    private readonly UserRepository repository;

    public UserListViewComponent(UserRepository repository)
    {
        this.repository = repository;
    }
    public IViewComponentResult Invoke()
    {
        var users = repository.GetUsers().Take(10).ToList();
        return View(model: users);
    }
}

ویووی کامپوننت فوق نیز به این صورت تعریف شده است:
@model IList<User>
@foreach (var user in Model)
{
    <li>
        <a asp-controller="UserManager" asp-action="Edit" asp-route-id="@user.Id">@user.Name</a>
    </li>
}
<a class="btn btn-info" asp-controller="UserManager" asp-action="Index">More...</a>

کنترلر UserManager نیز یک چنین تعریفی را دارد:
public class UserManagerController : Controller
{
    private readonly UserRepository repository;

    public UserManagerController(UserRepository repository)
    {
        this.repository = repository;
    }

    public ViewResult Index()
    {
        var users = repository.GetUsers().ToList();
        return View(users);
    }

    public ViewResult Edit(int id)
    {
        var user = repository.GetUsers().FirstOrDefault(u => u.Id == id);
        return View(user);
    }

    [HttpPost]
    public IActionResult Edit(User user)
    {
        repository.Edit(user);
        return RedirectToAction("Index", "Home");
    }
}

در ادامه ویووهای تعریف شده‌ی برای کنترلر فوق را نیز مشاهده میکنید:
// Views/UserManager/Edit.cshtml
@model User
<div class="row">
    <div class="col-md-8">
        <form method="post">
            <input type="hidden" asp-for="Id" />
            <div class="form-group">
                <label asp-for="Name"></label>
                <input asp-for="Name" class="form-control"/>
            </div>
            <div class="form-group">
                <label asp-for="LastName"></label>
                <input asp-for="LastName" class="form-control"/>
            </div>
            <div class="form-group">
                <label asp-for="Age"></label>
                <input asp-for="Age" class="form-control"/>
            </div>
            <button type="submit" class="btn btn-primary">Save</button>
        </form>
    </div>
</div>

// Views/UserManager/Index.cshtml
@model IList<User>
<table class="table">
    <tr>
        <td>Id</td>
        <td>Name</td>
        <td>LastName</td>
        <td>Age</td>
    </tr>
    @foreach (var user in Model)
    {
         <tr>
            <td>@user.Id</td>
            <td>@user.Name</td>
            <td>@user.LastName</td>
            <td>@user.Age</td>
        </tr>
    }
</table>

همانطور که مشاهده می‌کنید، کنترلر UserManager و کامپوننت UserList، به ترتیب کار مدیریت و نمایش کاربران را انجام میدهند و منطقاً هر دو جزو قابلیت‌های User هستند. برای جلوگیری از تکرار کد، می‌توانیم کنترلر و ویو‌وکامپوننت فوق را با هم ادغام کنیم؛ در واقع می‌توانیم UserListViewComponent را درون UserManagerController تعریف کنیم. برای این کار کافی است فایل UserManagerController را اینگونه تغییر دهیم:
[ViewComponent(Name = "UserList")]
public class UserManagerController : Controller
{
    private readonly UserRepository repository;

    public UserManagerController(UserRepository repository)
    {
        this.repository = repository;
    }

    public ViewResult Index()
    {
        var users = repository.GetUsers().ToList();
        return View(users);
    }

    public ViewResult Edit(int id)
    {
        var user = repository.GetUsers().FirstOrDefault(u => u.Id == id);
        return View(user);
    }

    [HttpPost]
    public IActionResult Edit(User user)
    {
        repository.Edit(user);
        return RedirectToAction("Index", "Home");
    }

    public IViewComponentResult Invoke()
    {
        var users = repository.GetUsers().Take(10).ToList();
        return new ViewViewComponentResult
        {
            ViewData = new ViewDataDictionary<IList<User>>(ViewData, users)
        };
    }
}

  
توضیحات:
همانطور که پیش‌تر نیز بحث شده است، از ویژگی ViewComponent زمانی استفاده خواهد شد که کلاس موردنظر از کلاس پایه ViewComponent ارث‌بری نکرده باشد و همچنین نام کلاس به ViewComponent ختم نشده باشد. با تعیین پراپرتی Name، یک نام برای ViewComponent تعیین کرده‌ایم که در نهایت درون ویوو، توسط Component.Invoke@  قابل فراخوانی باشد. همچنین از آنجائیکه UserManagerController از کلاس پایه ViewComponent ارث‌بری نکرده است، در نتیجه به اشیاء IViewComponentResult دسترسی نداریم، از این جهت به صورت مستقیم ViewViewComponentResult را ایجاد کرده‌ایم و مدلی که قرار است که به ویوو کامپوننت پاس داده شود را مقداردهی کرده‌ایم.

محل تعریف Viewها
Viewهای کنترلر و همچنین ویووکامپوننت مانند روش فوق قابل ترکیب نیستند؛ در نتیجه نیازی به تغییر هیچکدام از ویووها نخواهیم داشت.
UserManagerController:
/Views/UserManager/Edit.cshtml
/Views/UserManager/Index.cshtml

UserListViewComponent:
/Views/Shared/Components/UserList/Default.cshtml

نکته: دقت داشته باشید که ویجت نمایش لیست کاربران که پیشتر به صورت مستقل از عملکرد یک اکشن متد کار می‌کرده، قرار نیست جایگزین لیست کاربران (اکشن متد Index درون کنترلر UserManager) شود؛ یعنی به صورت مستقل از آن عمل میکند. هدف بیشتر قرار دادن View Component موردنظر درون کنترلر UserManager است.
مطالب
آزمایش Web APIs توسط Postman - قسمت دوم - ایجاد گردش کاری بین درخواست‌ها
تا اینجا مثال‌هایی را که بررسی کردیم، متکی به خود بودند و اطلاعات هر کدام، از یک درخواست به درخواستی دیگر کاملا متفاوت بود. همچنین اطلاعات ارسالی و یا دریافتی توسط آن‌ها نیز ثابت و از پیش تعیین شده بود.


کار با اطلاعات متغیر دریافتی از سرور

در Postman یک برگه‌ی جدید را باز کنید و سپس آدرس https://httpbin.org/uuid را در حالت Get درخواست نمائید:


این درخواست، یک Guid اتفاقی جدید را باز می‌گرداند. هربار که بر روی دکمه‌ی Send کلیک کنیم، مقدار Guid دریافتی متفاوت خواهد بود. این خروجی دقیقا حالتی است که در برنامه‌های دنیای واقعی با آن سر و کار داریم. در این نوع برنامه‌ها، پیشتر نمی‌توان مقدار خروجی دریافتی از سرور را پیش‌بینی کرد. همچنین علاقمندیم این مقدار دریافتی (از درخواست 1) را به Post request ای که در انتهای قسمت قبل ایجاد کردیم (درخواست 2)، ارسال کنیم و اطلاعاتی را بین درخواست‌ها به اشتراک بگذاریم.
برای این منظور، مجموعه‌ی httpbin ای را که در قسمت قبل ایجاد کردیم، انتخاب کرده و Post request ذخیره شده‌ی در آن‌را انتخاب کنید تا مجددا جزئیات آن بازیابی شود:

اکنون با مراجعه به برگه‌ی بدنه‌ی درخواست آن، قصد داریم یک خاصیت جدید id را با guid دریافتی از سرور توسط درخواستی دیگر، مقدار دهی کنیم:


برای دسترسی به این اطلاعات، می‌توان از ویژگی بسیار قدرتمند postman به نام متغیرها استفاده کرد. به همین جهت به برگه‌ی درخواست دریافت guid مراجعه کرده و برگه‌ی Tests آن‌را باز کنید:


این قسمت پس از پایان درخواست جاری، اجرا می‌شود. بنابراین دراینجا فرصت خواهیم داشت تا مقدار دریافتی از سرور را در یک متغیر ذخیره کنیم. سپس می‌توان از این متغیر در حین ارسال درخواستی دیگر استفاده کرد. در پنل کنار textbox نوشتن آزمون‌ها، تعدادی نمونه کد هم وجود دارند. برای مثال در اینجا نمونه کد «Set a global variable» را با کلیک بر روی آن انتخاب می‌کنیم:
 pm.globals.set("uuid", "foo");
در این مثال key/value این متغیر سراسری، با یک کلید مشخص و مقداری ثابت، مقدار دهی شده‌اند.

اکنون مجددا بر روی دکمه‌ی Send این درخواست کلیک کنید. پس از اجرای آن، این قطعه کد اجرا شده و یک متغیر سراسری، با کلید uuid و مقدار ثابت مشخص شده، در تمام برگه‌های postman در دسترس خواهند بود. برای بررسی صحت این عملیات، می‌توانید بر روی دکمه‌‌ای با آیکن چشم، در بالای سمت راست صفحه، کلیک کنید:


در ادامه برای استفاده‌ی از این متغیر سراسری، به برگه‌ی Post request مراجعه کرده و بدنه‌ی درخواست را به صورت زیر ویرایش می‌کنیم:
{
"name": "Vahid",
"id": "{{uuid}}"
}
در جائیکه بدنه‌ی درخواست درج می‌شود، متغیرها باید درون {{ }} قرار گیرند.
سپس این درخواست را ارسال کنید، در خروجی دریافتی از سرور httpbin، خاصیت و مقدار جدید id قابل مشاهده هستند که به معنای ارسال صحیح آن به سرور است:
    "json": {
        "id": "foo",
        "name": "Vahid"
    },
در اینجا، foo، مقداری است که از یک درخواست دیگر خوانده شده و توسط درخواست مجزای post جاری، ارسال گردیده‌است.
در این مرحله بر روی دکمه‌ی Save برگه‌ی uuid کلیک کرده و آن‌را در مجموعه‌ی httpbin، ذخیره کنید.


روش دسترسی و به اشتراک گذاری مقدار متغیر uuid دریافتی

تا اینجا متغیر سراسری uuid تنظیم شده، دارای یک مقدار ثابت است. برای تنظیم آن به مقدار Guid دریافتی از سرور، مجددا به برگه‌ی Tests درخواست uuid مراجعه می‌کنیم و آن‌را به نحو زیر تکمیل خواهیم کرد:



pm.response حاوی کل اطلاعات شیء response است و برای مثال بدنه‌ی response دریافتی از سمت سرور httpbin، یک چنین شکلی را دارد:
{
    "uuid": "4594e7ad-cae3-487b-bd42-fc49c312c0e9"
}
با فراخوانی متد json بر روی این شیء، اکنون می‌توان به اطلاعات آن همانند یک شیء متداول جاوا اسکریپتی که دارای کلید و خاصیت uuid است، دسترسی یافت:
let jsonResponse = pm.response.json();
pm.globals.set("uuid", jsonResponse.uuid);
پس از این تنظیم، مجددا درخواست را ارسال کنید که سبب دریافت uuid جدیدی می‌شود:
{
    "uuid": "83d437a8-bce6-438b-8693-068e5399182c"
}
برای بررسی نتیجه‌ی این عملیات، با کلیک بر روی دکمه‌‌ای با آیکن چشم، در بالای سمت راست صفحه، چنین خروجی قابل مشاهده خواهد بود:


که به معنای دسترسی به مقدار متغیر uuid دریافتی از سمت سرور و تنظیم آن به عنوان یک متغیر سراسری است.
اکنون اگر مجددا به برگه‌ی مجزای Post request مراجعه و آن‌را ارسال کنیم، در خروجی بدنه‌ی response دریافتی از سمت سرور:
   "json": {
        "id": "83d437a8-bce6-438b-8693-068e5399182c",
        "name": "Vahid"
    },
دقیقا ارسال همان مقدار متغیر دریافتی از برگه‌ای دیگر که توسط متغیر {{uuid}} تنظیم شده‌، قابل مشاهده‌است.
تا اینجا تمام برگه‌های باز را ذخیره کنید:


در این تصویر، uuid پس از Post request قرار گرفته، چون ترتیب ذخیره سازی آن‌ها به همین صورت بوده‌است. اما نیاز است uuid را به پیش از درخواست post، منتقل کرد. برای اینکار می‌توان از drag/drop آیتم آن کمک گرفت.


نوشتن یک آزمون ساده

هدف اصلی از برگه‌ی Tests هر درخواست در Postman، نوشتن آزمون‌های مختلف است. به همین جهت برای نوشتن یک آزمون ساده، به برگه‌ی Post request که هم اکنون باز است، مراجعه کرده و سپس برگه‌ی Tests آن‌را به صورت زیر تنظیم می‌کنیم:


pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});
در اینجا در پنل code snippets کناری آن، بر روی لینک و گزینه‌ی «Status code: code is 200» کلیک کرده‌ایم تا به صورت خودکار، قطعه کد فوق را تولید کند. البته Tests را در قسمت‌های بعدی با جزئیات بیشتری بررسی خواهیم کرد. در اینجا بیشتر هدف آشنایی مقدماتی با برگه‌ی Tests آن است.
این آزمون، بررسی می‌کند که آیا status code بازگشتی از سرور 200 است یا خیر؟ برای اجرای آن، فقط کافی است بر روی دکمه Send این برگه کلیک کنید:


نتیجه‌ی آن‌را در برگه‌ی جدید Test Results، در قسمت نمایش response دریافتی از سمت سرور، می‌توان مشاهده کرد که بیانگر موفقیت آمیز بودن آزمایش انجام شده‌است.
اگر علاقمندید تا حالت شکست آن‌را نیز مشاهده کنید، بجای عدد 200، عدد 404 را وارد کرده و مجددا درخواست را ارسال کنید.


اجرای ترتیبی آیتم‌های یک مجموعه

تا اینجا اگر درخواست‌ها را در مجموعه‌ی httpbin ذخیره کرده و همچنین ترتیب آن‌ها را نیز به نحوی که گفته شد، اصلاح کرده باشید، یک چنین شکلی را باید مشاهده کنید:


در اینجا برای اجرای ترتیبی این آیتم‌ها و اجرای گردش کاری کوچکی که ایجاد کرده‌ایم (درخواست post باید پس از درخواست uuid و بر اساس مقدار دریافتی آن از سرور اجرا شود)، می‌توان از collection runner برنامه‌ی Postman استفاده کرد:


با کلیک بر روی دکمه‌ی Runner، در نوار ابزار برنامه‌ی Postman، صفحه‌ی Collection runner آن ظاهر می‌شود. در این صفحه ابتدا httpbin collection را انتخاب می‌کنیم که سبب نمایش محتویات و اجزای آن خواهد شد. سپس بدون ایجاد هیچگونه تغییری در تنظیمات این صفحه، بر روی دکمه‌ی run httpbin کلیک می‌کنیم:


پس از اجرای خودکار مراحل این مجموعه، نتیجه‌ی عملیات ظاهر می‌شود:


در اینجا هر مرحله، پس از مرحله‌ای دیگر اجرا شده و اگر آزمایشی نیز به همراه آن‌ها بوده باشد نیز اجرا شده‌است. همچنین اگر بر روی نام هر کدام از مراحل کلیک کنیم، می‌توان جزئیات آن‌ها را نیز دقیقا بررسی کرد:


امکان اجرای یک چنین قابلیتی توسط برنامه‌ی CLI ای به نام newman نیز به همراه Postman وجود دارد که جهت استفاده‌ی در continuous integration servers می‌تواند بسیار مفید باشد. جزئیات آن‌را در قسمت‌های بعدی بررسی خواهیم کرد.
نظرات مطالب
بخش اول - آشنایی و شروع کار با Svelte
تلاش شما قابل تقدیر هست؛ ولی به نظر شما صرف اینکه شبه فریم ورکی حجم کمتری داره، یعنی بهتره و باید انتخاب بشه، یا اینکه معیارهای دیگری هم برای انتخاب موجود هستند؟
Svelte   Vue React  Angular   
  120  35,540    142,533   168,458    تعداد سؤال در استک‌اور فلو
 17,350   139,850    130,092    48,583    تعداد ستاره در GitHub
 141  275  1297  935  تعداد مشارکت کننده در GitHub
اشتراک‌ها
سری ساخت یک برنامه‌ی #C از آغاز تا پایان

C# Application From Start to Finish: Tournament Tracker Course - YouTube
28 videos, 192,192 views, Last updated on Jan 13, 2019
Follow along in this free course as I show you how to create an application in C# from idea through the finished product. Everything is shown on screen and in great detail. Learn how to use SQL databases, CSV text files, custom events, Linq, Lambda expressions, emailing, and more. Everything you learn will be in context of a real application.

سری ساخت یک برنامه‌ی #C از آغاز تا پایان