<div id="chart"></div> <script> $("#chart").kendoChart({ series: [{ data: [1, 2, 3] }], valueAxis: { notes: { label: { rotation: 90 }, data: [{ value: 1 }] } } }); </script>
چندی پیش در سایت جاری چند مقاله خوب توسط یکی از دوستان درباره Qunit منتشر شد. Qunit یک ابزار قدرتمند و مناسب برای تست کدهای جاوااسکریپت است و در اثبات صحت این گفته همین کافیست که بدانیم برای تست کدهای نوشته شده در پروژههای متن بازی هم چون Backbone.Js و JQuery از این فریم ورک استفاده شده است. اما به احتمال قوی در ذهن شما این سوال مطرح شده است که خب! در صورت آشنایی با Qunit چه نیاز به یادگیری Jasmine یا خدای نکرده Mocha و FuncUnit است؟ هدف صرفا معرفی یک ابزار غیر برای تست کد است نه مقایسه و نتیجه گیری برای تعیین میزان برتری این ابزارها. اصولا مهمترین دلیل برای انتخاب، علاوه بر امکانات و انعطاف پذیری، فاکتور راحتی و آسان بودن در هنگام استفاده است که به صورت مستقیم به شما و تیم توسعه نرم افزار بستگی دارد.
اما به عنوان توسعه دهنده نرم افزار که قرار است از این ابزار استفاده کنیم بهتر است با تفاوتها و شباهتهای مهم این دو فریم ورک آشنا باشیم:
»Jasmine یک فریم ورک تست کدهای جاوا اسکریپ بر مبنای Behavior-Driven Development است در حالی که Qunit بر مبنای Test-Driven Development است و همین مسئله مهمترین تفاوت بین این دو فریم ورک میباشد.
»اگر قصد دارید که از Qunit نیز به روش BDD استفاده نمایید باید از ترکیب Pavlov به همراه Qunit استفاده کنید.
»Jasmine از مباحث مربوط به Spies و Mocking به خوبی پشتیبانی میکند ولی این امکان به صورت توکار در Qunit فراهم نیست. برای اینکه بتوانیم این مفاهیم را در Qunit پیاده سازی کنیم باید از فریم ورکهای دیگر نظیر SinonJS به همراه Qunit استفاده کنیم.
»هر دو فریم ورک بالا به سادگی و راحتی کار معروف هستند
»تمام موارد مربوط به الگوهای Matching در هر دو فریم ورک به خوبی تعبیه شده است
» هر دو فریم ورک بالا از مباحث مربوط به Asynchronous Testing برای تست کدهای Ajax ای به خوبی پشتیبانی میکنند.
بررسی چند مفهوم
قبل از شروع، بهتر است که با چند مفهوم کلی و در عین حال مهم این فریم ورک آشنا شویم
describe('JavaScript addition operator', function () { it('adds two numbers together', function () { expect(1 + 2).toEqual(3); }); });
در تابع it کد بالا شما میتوانید کدهای مربوط بدنه توابع تست خود را بنویسید. برای پیاده سازی Assert در توابع تست مفهوم expectationها وجود دارد. در واقع expect برای بررسی مقادیر حقیقی با مقادیر مورد انتظار مورد استفاده قرار میگیرد و شامل مقادیر true یا false خواهد بود.
برای Setup و Teardown توابع تست خود باید از توابع beforeEach و afterEach که بدین منظور تعبیه شده اند استفاده کنید.
describe("A spec (with setup and tear-down)", function() { var foo; beforeEach(function() { foo = 0; foo += 1; }); afterEach(function() { foo = 0; }); it("is just a function, so it can contain any code", function() { expect(foo).toEqual(1); }); it("can have more than one expectation", function() { expect(foo).toEqual(1); expect(true).toEqual(true); }); });
اگر در کد تست خود قصد دارید که یک تابع describe یا it را غیر فعال کنید کافیست یک x به ابتدای آنها اضافه کنید و دیگر نیاز به هیچ کار اضافه دیگری برای comment کردن کد نیست.
xdescribe("A spec", function() { var foo; beforeEach(function() { foo = 0; foo += 1; }); xit("is just a function, so it can contain any code", function() { expect(foo).toEqual(1); }); });
درادامه قصد پیاده سازی یک مثال را با استفاده از Jasmine و RequireJs در پروژه Asp.Net MVC دارم.
- فولدر lib شامل فایلها کدهای Jasmine برای setup و tear down و spice و تست کدهای شما میباشد.
- فایل specRunner.html به واقع یک فایل برای نمایش فایلهای تست و همچنین نمایش نتیجه تست است.
- فولدر spec نیز شامل کدهای Jasmine برای کمک به نوشتن تست میباشد.
در این مثال قصد داریم فایلهای player.js و song.js که به عنوان نمونه به همراه این فریم ورک قرار دارد را در قالب یک پروژه MVC به همراه RequireJs، تست نماییم. در نتیجه این فایلها را از فولدر src انتخاب نمایید و آنها را در قسمت Scripts پروژه اصلی خود کپی کنید(ابتدا بک پوشه به نام App بسازید و فایلها را در آن قرار دهید)
برای استفاده از requireJs باید دستور define را در ابتدا این فایلها اضافه نماییم. در نتیجه فایلهای Player.js و Song.js را باز کنید و تغییرات زیر را در ابتدای این فایلها اعمال نمایید.
Song.js
define(function () { function Song() { } Song.prototype.persistFavoriteStatus = function (value) { // something complicated throw new Error("not yet implemented"); }; });
define(function () { function Player() { } Player.prototype.play = function (song) { this.currentlyPlayingSong = song; this.isPlaying = true; }; Player.prototype.pause = function () { this.isPlaying = false; }; Player.prototype.resume = function () { if (this.isPlaying) { throw new Error("song is already playing"); } this.isPlaying = true; }; Player.prototype.makeFavorite = function () { this.currentlyPlayingSong.persistFavoriteStatus(true); }; });
baseUrl در پیکر بندی requireJs به مسیر فایلهای پروژه که در پروژه اصلی MVC قرار دارد اشاره میکند. paths برای تعیین مسیر فایلهای تست که در پوشه spec در پروژه تست قرار دارد اشاره میکند. اگر دقت کرده باشید به دلیل اینگه تگهای script مربوط به لود فایلهای SpecHelper.js و PlayerSpec.js به صورت comment در آمده اند در نتیجه این فایلها لود نخواهند شد و خروجی مورد نظر مشاهده نمیشود. در این جا باید از مکانیزم AMD موجود در RequireJs استفاده نماییم و فایلهای مربوطه را لود کنیم. برای این کار نیاز به اضافه کردن دستور require در ابتدای تگ script به صورت زیر در این فایل است. در نتیجه فایلهای PlayerSpec و SpecHelper نیز توسط RequireJs لود خواهند شد.
نیاز به یک تغییر کوچک دیگر نیز وجود دارد. فایل PlayerSpec را باز نمایید و وابستگی فایلهای آن را تعیین نمایید. از آن جا که این فایل برای تست فایلهای Player , Song ایجاد شده است در نتیجه باید از define برای تعیین این وابستگیها استفاده نماییم.
یادآوری:
»دستور describe در فایل بالا برای تعریف تابع تست است. همان طور که میبینید بک نام به آن داده میشود به همراه بدنه تابع تست.
»دستور beforeEach برای آماده سازی مواردی است که قصد داریم در تست مورد استفاده قرار گیرند. همانند متدهای Setup در UnitTest.
» دستور expect نیز معادل Assert در UnitTest است و برای بررسی صحت عملکرد تست نوشته میشود.
اگر
فایل SpecRunner.html را دوباره در مرورگر خود باز نمایید تصویر زیر را
مشاهده خواهید کرد که به عنوان موفقیت آمیز بودن پیکر بندی پروژه و تستهای آن میباشد.
ASP.NET به صورت پیش فرض در مقابل ارسال هر نوع تگی عکس العمل نشان میدهد و پیغام خطای یافتن خطری بالقوه را گوشزد میکند. اما بین خودمان باشد، همه این قابلیت را خاموش میکنند! چون در یک برنامه واقعی نیاز است تا مثلا کاربران تگ html هم ارسال کنند. برای نمونه یک ادیتور متنی پیشرفته را درنظر بگیرید. خاموش کردن این قابلیت هم مساوی است با فراهم کردن امکان ارسال تگهای مجاز و در کنار آن بی دفاع گذاشتن برنامه در مقابل حملات XSS.
توصیه هم این است که همه جا از توابع مثلا HtmlEncode و موارد مشابه حتما استفاده کنید. ولی باز هم خودمونیم ... چند نفر از شماها اینکار را میکنید؟!
بهترین کار در این موارد وارد شدن به pipe line پردازشی ASP.NET و دستکاری آن است! اینکار هم توسط HttpModules میسر است. به عبارتی در ادامه میخواهیم ماژولی را بنویسیم که کلیه تگهای ارسالی کوئری استرینگها را پاک کرده و همچنین تگهای خطرناک موجود در مقادیر ارسالی فرمهای برنامه را هم به صورت خودکار حذف کند. اما هنوز اجازه بدهد تا کاربران بتوانند تگ HTML هم ارسال کنند.
مشکل! در ASP.NET مقادیر ارسالی کوئری استرینگها و همچنین فرمها به صورت NameValueCollection در اختیار برنامه قرار میگیرند و ... خاصیت IsReadOnly این مجموعهها در حین ارسال، به صورت پیش فرض true است و همچنین غیرعمومی! یعنی به همین سادگی نمیتوان عملیات تمیزکاری را روی مقادیر ارسالی، پیش از مهیا شدن آن جهت استفاده در برنامه اعمال کرد. بنابراین در ابتدای کار نیاز است با استفاده از قابلیت Reflection ، اندکی در سازوکار داخلی ASP.NET دست برد، این خاصیت فقط خواندنی غیرعمومی را برای مدت کوتاهی false کرد و سپس مقصود نهایی را اعمال نمود. پیاده سازی آن را در ادامه مشاهده میکنید:
using System; using System.Collections.Specialized; using System.Reflection; using System.Text.RegularExpressions; using System.Web; using Microsoft.Security.Application;
namespace AntiXssMdl { public class AntiXssModule : IHttpModule { private static readonly Regex _cleanAllTags = new Regex("<[^>]+>", RegexOptions.Compiled); public void Init(HttpApplication context) { context.BeginRequest += CleanUpInput; }
public void Dispose() { }
private static void CleanUpInput(object sender, EventArgs e) { HttpRequest request = ((HttpApplication)sender).Request; if (request.QueryString.Count > 0) { //تمیزکاری مقادیر کلیه کوئری استرینگها پیش از استفاده در برنامه CleanUpAndEncode(request.QueryString, allowHtmltags: false); }
if (request.HttpMethod == "POST") { //تمیزکاری کلیه مقادیر ارسالی به سرور if (request.Form.Count > 0) { CleanUpAndEncode(request.Form, allowHtmltags: true); } } }
private static void CleanUpAndEncode(NameValueCollection collection, bool allowHtmltags) { //اندکی دستکاری در سیستم داخلی دات نت PropertyInfo readonlyProperty = collection .GetType() .GetProperty("IsReadOnly", BindingFlags.Instance | BindingFlags.NonPublic); readonlyProperty.SetValue(collection, false, null);//IsReadOnly=false
for (int i = 0; i < collection.Count; i++) { if (string.IsNullOrWhiteSpace(collection[i])) continue;
if (!allowHtmltags) { //در حالت کوئری استرینگ دلیلی برای ارسال هیچ نوع تگی وجود ندارد collection[collection.Keys[i]] = AntiXss.HtmlEncode(_cleanAllTags.Replace(collection[i], string.Empty)); } else { //قصد تمیز سازی ویوو استیت را نداریم چون در این حالت وب فرمها از کار میافتند if (collection.Keys[i].StartsWith("__VIEWSTATE")) continue; //در سایر موارد کاربران مجازند فقط تگهای سالم را ارسال کنند و مابقی حذف میشود collection[collection.Keys[i]] = Sanitizer.GetSafeHtml(collection[i]); } }
readonlyProperty.SetValue(collection, true, null);//IsReadOnly=true } } }
در این کلاس از کتابخانه AntiXSS مایکروسافت استفاده شده است. آخرین نگارش آنرا از اینجا دریافت نمائید. نکته مهم آن متد Sanitizer.GetSafeHtml است. به کمک آن با خیال راحت میتوان در یک سایت، از یک ادیتور متنی پیشرفته استفاده کرد. کاربران هنوز میتوانند تگهای HTML را ارسال کنند؛ اما در این بین هرگونه سعی در ارسال عبارات و تگهای حاوی حملات XSS پاکسازی میشود.
و یک وب کانفیگ نمونه برای استفاده از آن به صورت زیر میتواند باشد (تنظیم شده برای IIS6 و 7):
<?xml version="1.0"?> <configuration> <system.web> <pages validateRequest="false" enableEventValidation="false" /> <httpRuntime requestValidationMode="2.0" /> <compilation debug="true" targetFramework="4.0" /> <httpModules> <add name="AntiXssModule" type="AntiXssMdl.AntiXssModule"/> </httpModules> </system.web>
<system.webServer> <validation validateIntegratedModeConfiguration="false"/> <modules> <add name="AntiXssModule" type="AntiXssMdl.AntiXssModule"/> </modules> </system.webServer> </configuration>
برای مثال به تصویر زیر دقت کنید. ماژول فوق، فقط تگهای سبز رنگ را (حین ارسال به سرور) مجاز دانسته، اسکریپت ذیل لینک را کلا حذف کرده و تگهای موجود در کوئری استرینگ را هم نهایتا (زمانیکه در اختیار برنامه قرار میگیرد) حذف خواهد کرد.
دریافت نسخه جدید و نهایی این مثال
- «تنظیم رشته اتصالی Entity Framework به بانک اطلاعاتی به وسیله کد»
- «استفاده از چندین بانک اطلاعاتی به صورت همزمان در EF Code First»
اما EF Core نه تنها این مشکل را پوشش را دادهاست، بلکه امکان تزریق وابستگیها و استفادهی از سرویسهای مختلف را نیز در این حین، پیش بینی کردهاست که در ادامه جزئیات آنرا مرور میکنیم.
نیاز به تغییر رشتهی اتصالی به بانک اطلاعاتی در زمان اجرا
دلایل نیاز به امکان تغییر رشتهی اتصالی در زمان اجرا شامل موارد زیر هستند:
- در برنامههایی کمی پیچیدهتر و سابقه دار، ممکن است عملیات تجاری یکسال را در بانک اطلاعاتی سال 98 و دیگری را در بانک اطلاعاتی سال 99 ثبت کنید. در این حالت کاربران باید بتوانند در زمان اجرا به هر بانک اطلاعاتی که پیشتر با آن کار کردهاند، متصل شده و از آن استفاده کنند.
- یکی از روشهای پیاده سازی برنامههای چند مستاجری، داشتن یک بانک اطلاعاتی مجزا، به ازای هر مستاجر است. در این حالت نیز تک برنامهی ما باید بتواند بر اساس Id مشتری، بانک اطلاعاتی متناظری را در زمان اجرا انتخاب کند.
- نیاز به داشتن چندین context در برنامه و کار با بانکهای اطلاعاتی متفاوت در زمان اجرا؛ مانند کار با SQL Server، اوراکل و یا SQLite
روش تغییر رشتهی اتصالی به بانک اطلاعاتی در EF Core در زمان اجرای برنامه
اگر به روش ثبت متداول سرویس DbContext برنامه و پروایدر آن دقت کنیم:
services.AddDbContext<ApplicationDbContext>(options => options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection") ));
یک نکته: چون این اطلاعات کش نمیشوند، اگر رشتهی اتصالی شما ثابت است (و نیازی به تغییر آن در زمان اجرای برنامه نیست)، محل تامین آنرا به پیش از سطر services.AddDbContext انتقال دهید و فقط نتیجهی محاسبه شدهی نهایی را استفاده کنید تا کارآیی برنامه افزایش یابد؛ در غیراینصورت فراخوانی Configuration.GetConnectionString مدام تکرار خواهد شد.
دریافت یک قالب قابل تغییر از تنظیمات برنامه و تغییر آن با هدرهای درخواست رسیدهی به آن
فرض کنید قالب رشتهی اتصالی برنامه در فایل appsettings.json به صورت زیر است:
"ConnectionStrings": { "ConnectionTemplate": "Data Source=.;Initial Catalog={db_Name};Integrated Security=True", }
بنابراین اکنون نیاز است به ازای هر درخواست رسیده بتوان به سرویس IHttpContextAccessor و شیء HttpContext.Request جاری دسترسی یافت و سپس از هدرهای رسیده، برای مثال هدر ویژهی tenantId و یا year را پردازش کرد؛ اما در تعریف services.AddDbContext فوق چگونه میتوان اینکار را انجام داد؟
خوشبختانه متد services.AddDbContext، دارای یک overload دیگر نیز هست که امکان دسترسی به تمام سرویسهای جاری سیستم را میسر میکند:
services.AddDbContext<ApplicationDbContext>((serviceProvider, dbContextBuilder) => { var connectionStringTemplate = Configuration.GetConnectionString("ConnectionTemplate"); var httpContextAccessor = serviceProvider.GetRequiredService<IHttpContextAccessor>(); var dbName = httpContextAccessor.HttpContext.Request.Headers["tenantId"].First(); var connectionString = connectionStringTemplate.Replace("{db_Name}", dbName); dbContextBuilder.UseSqlServer(connectionString); });
همچنین در صورت نیاز میتوان UseSqlServer آنرا نیز در این action delegate به هر پروایدر دیگری در زمان اجرا تغییر داد و از این لحاظ محدودیتی وجود ندارد.
یک نکته: البته برنامه نباید هر tenantId ای را پردازش کند و این خودش میتواند تبدیل به یک نقیصهی امنیتی شود. به همین جهت برای مثال میتوان tenantId را در یک JWT قرار داد و در حین تعیین اعتبار آن و کاربر جاری، این مقدار را نیز بررسی کرد.
@"<script>alert('xss')</script><div onload=""alert('xss')""" + @"style=""background-color: rgba(0, 0, 0, 1)"">Test<img src=""test.png""" + @"style=""background-image: url(javascript:alert('xss')); margin: 10px""></div>";
استفاده از NuGet Package Manager برای مدیریت وابستگیها
درباره اهمیت NuGet برای مصرف کنندگان قبلا این مطلب نوشته شده است.
بجای صرف وقت برای اینکه بررسی کنیم آیا این نسخهی جدید کتابخانهی X یا اسکریپت jQuery آمده است یا خیر، میتوان این وظیفه را به NuGet سپرد. علاوه بر این NuGet مزیتهای دیگری هم دارد؛ مثلا تیمهای برنامه نویسی میتوانند کتاب خانههای مشترک خودشان را در مخزنهای سفارشی NuGet قرار دهند و توزیع و Versioning آنرا به NuGet بسپارند.
تکیه بر Abstraction (انتزاع)
Abstraction در طراحی سیستمها منجر به تولید نرم افزار هایی Loosely coupled با قابلیت نگهداری بالا و همچنین فراهم شدن زمینه برای نوشتن Unit Test میشود.
اگر به مطالب قبلی وب سایت برگردیم در مطلب چرا ASP.NET MVC گفته شد که :
2) دستیابی به کنترل بیشتر بر روی اجزای فریم ورک :
در طراحی ASP.NET MVC همهجا interfaceها قابل مشاهد هستند. همین مساله به معنای افزونه پذیری اکثر قطعات تشکیل دهنده ASP.NET MVC است؛ برخلاف ASP.NET web forms. برای مثال تابحال چندین view engine، routing engine و غیره توسط برنامه نویسهای مستقل برای ASP.NET MVC طراحی شدهاند که هیچکدام با ASP.NET web forms میسر نیست. برای مثال از view engine پیش فرض آن خوشتان نمیآید؟ عوضش کنید! سیستم اعتبار سنجی توکار آنرا دوست ندارید؟ آنرا با یک نمونه بهتر تعویض کنید و الی آخر ...
به علاوه طراحی بر اساس interfaceها یک مزیت دیگر را هم به همراه دارد و آن هم ساده سازی mocking (تقلید) آنها است جهت ساده سازی نوشتن آزمونهای واحد.
از کلمهی کلیدی New استفاده نکنید
هر جا ممکن است کار وهله سازی اشیاء را به لایه و حتی Framework دیگری بسپارید. هر زمان اشیاء نرم افزار خودتان را با کلمهی new وهله سازی میکنید اصل Abstraction را فراموش کرده اید. هر زمان اشیاء نرم افزار را مستقیم وهله سازی میکنید در نظر داشته باشید میتوانید آنها را به صورت وابستگی تزریق کنید.
در همین رابطه مطالب زیر را از دست ندهید :
- تزریق وابستگی (dependency injection) به زبان ساده
- تزریق وابستگی (Dependency Injection) و توسعه پذیری
از HttpContext مستقیما استفاده نکنید (از HttpContextBase استفاده کنید)
از .NET 4 به بعد فضای نامی تعریف شده که در بر دارندهی کلاسهای انتزاعی (Abstraction) خیلی از قسمتهای اصلی ASP.NET است. یکی از مواردی که در توسعهی ASP.NET معمولا زیاد استفاده میشود، شیء HttpContext است . استفاده از HttpContextBase را به استفاده از HttpContext ترجیح دهید. اهمیت این موضوع در راستای اهمیت انتزاع (Abstraction) میباشد.
از "رشتههای جادویی" اجتناب کنید
استفاده از رشتههای جادویی در خیلی از جاها کار را ساده میکند؛ بعضی وقتها هم به آنها نیاز است اما مشکلات زیادی دارند :
- رشتهها معنای باطنی ندارند (مثلا : دشوار است که از روی نام یک ID مشخص کنم این ID چطور به ID دیگری مرتبط است و یا اصلا ربط دارد یا خیر)
- با اشتباهات املایی یا عدم رعایت حروف بزرگ و کوچک ایجاد مشکل میکنند.
- به Refactoring واکنش خوبی نشان نمیدهند. (برای درک بهتر این مطلب را بخوانید.)
<p> <label for="FirstName">First Name:</label> <span id="FirstName">@ViewData["FirstName"]</span> </p>
<p> <label for="FirstName">First Name:</label> <span id="FirstName">@Model.FirstName</span> </p>
در رابطه با Magic strings این مطلب را مطالعه بفرمایید.
از نوشتن HTML در کدهای "Backend" خودداری کنید
با توجه به اصل جداسازی وابستگیها (Separation of Concerns) وظیفهی کنترلرها و دیگر کدهای backend رندر کردن HTML نیست. (ساده سازی کنترلر ها) البته در نظر داشته باشید که قطعا تولید HTML در متدهای کمکی کلاس هایی که "تنها" وظیفهی آنها کمک به Viewها جهت تولید کد هست ایرادی ندارد. این کلاسها بخشی از View در نظر گرفته میشوند نه کدهای "backend".
در Viewها "Business logic" انجام ندهید
معکوس بند قبلی هم کاملا صدق میکند ، منظور این است که Viewها تا جایی که ممکن است باید حاوی کمترین Business logic ممکن باشند. در واقع تمرکز Viewها باید استفاده و نحوهی نمایش داده ای که برای آنها فراهم شده باشد نه انجام عملیات روی آن.
استفاده از Presentation Model را به استفاده مستقیم از Business Objectها ترجیح دهید
در مطالب مختلف وب سایت اشاره به اهمین ViewModelها شده است. برای اطلاعات بیشتر بند ج آموزش 11 از سری آموزشهای ASP.NET MVC را مطالعه بفرمایید.
Ifهای شرطی را در Viewها را در متدهای کمکی کپسوله کنید
استفاده از شرطها در View کار توسعه دهنده را برای یک سری اعمال ساده میکند اما میتواند باعث کمی کثیف کاری هم شود. مثلا:
@if(Model.IsAnonymousUser) { <img src="@Url.Content("~/content/images/anonymous.jpg")" /> } else if(Model.IsAdministrator) { <img src="@Url.Content("~/content/images/administrator.jpg")" /> } else if(Model.Membership == Membership.Standard) { <img src="@Url.Content("~/content/images/member.jpg")" /> } else if(Model.Membership == Membership.Preferred) { <img src="@Url.Content("~/content/images/preferred_member.jpg")" /> }
public static string UserAvatar(this HtmlHelper<User> helper) { var user = helper.ViewData.Model; string avatarFilename = "anonymous.jpg"; if (user.IsAnonymousUser) { avatarFilename = "anonymous.jpg"; } else if (user.IsAdministrator) { avatarFilename = "administrator.jpg"; } else if (user.Membership == Membership.Standard) { avatarFilename = "member.jpg"; } else if (user.Membership == Membership.Preferred) { avatarFilename = "preferred_member.jpg"; } var urlHelper = new UrlHelper(helper.ViewContext.RequestContext); var contentPath = string.Format("~/content/images/{0}", avatarFilename) string imageUrl = urlHelper.Content(contentPath); return string.Format("<img src='{0}' />", imageUrl); }
@Html.UserAvatar()
منتظر قسمت بعدی باشید.
- بسیار سبک ورزن است و تنها نیاز به نصب بستهی npm آنرا دارد.
- با فایلهای متنی معمولی کار میکند که ویرایش و copy/paste در آنها بسیار سادهاست.
- قرار دادن فایلهای نهایی متنی آن در ورژن کنترل بسیار سادهاست.
- امکان نوشتن درخواستهای به هم وابسته و آزمودن نتایج حاصل را دارا است.
- چون یک ابزار خط فرمان است، امکان استفادهی از آن به سادگی در فرآیندههای توسعهی مداوم وجود دارد.
- ابزارهای npm، چندسکویی هستند.
نصب strest
در ادامه قصد داریم مطلب «آزمایش Web APIs توسط Postman - قسمت ششم - اعتبارسنجی مبتنی بر JWT» را با استفاده از strest بازنویسی کنیم. به همین جهت در ابتدا نیاز است بستهی npm آنرا به صورت سراسری نصب کنیم:
npm i -g @strest/cli
مرحله 1: خاموش کردن بررسی مجوز SSL برنامه
مرحله 2: ایجاد درخواست login و دریافت توکنها
مجوز SSL آزمایشی برنامهی ASP.NET Core ما، از نوع خود امضاء شدهاست. به همین جهت اگر سعی در اجرای strest را با درخواستهای ارسالی به آن داشته باشیم، باشکست مواجه خواهند شد. بنابراین در ابتدا، خاصیت allowInsecure را به true تنظیم میکنیم:
version: 2 variables: baseUrl: https://localhost:5001/api logResponse: false allowInsecure: true
- همچنین در ابتدای این تنظیمات، روش تعریف متغیرها را نیز مشاهده میکنید که برای مثال توسط آنها baseUrl تعریف شدهاست.
درست در سطر پس از این تنظیمات، دستور اجرا و اعتبارسنجی درخواست Login را مینویسیم:
requests: loginRequest: request: url: <$ baseUrl $>/account/login method: POST postData: mimeType: application/json text: username: "Vahid" password: "1234" log: <$ logResponse $> validate: - jsonpath: content.access_token type: [string] - jsonpath: content.refresh_token type: [string]
- درخواستها با requests شروع میشوند. سپس ذیل آن میتوان نام چندین درخواست یا request را ذکر کرد که برای مثال نام درخواست تعریف شدهی در اینجا loginRequest است. این نام مهم است؛ از این جهت که با اشارهی به آن میتوان به فیلدهای خروجی response حاصل، در درخواستهای بعدی، دسترسی یافت.
- سپس، آدرس درخواست مشخص شدهاست. در اینجا روش کار با متغیرها را نیز مشاهده میکنید.
- نوع درخواست POST است.
- در ادامه جزئیات اطلاعات ارسالی به سمت سرور باید مشخص شوند. برای مثال در اینجا با فرمت application/json قرار است یک شیء تشکیل شدهی از username و password ارسال شوند.
- در سطر بعدی، خاصیت log با متغیر logResponse مقدار دهی شدهاست. اگر به true تنظیم شود، اصل خروجی response را توسط برنامهی خط فرمان strest میتوان مشاهده کرد. اگر اینکار خروجی را شلوغ کرد، میتوان آنرا به false تنظیم کرد و این خروجی را در فایل strest_history.json نهایی که حاصل از اجرای آزمایشهای تعریف شدهاست، در کنار فایل JWT.strest.yml خود یافت و مشاهده کرد.
- سپس به قسمت آزمودن نتیجهی درخواست میرسیم. در اینجا انتظار داریم که درخواست حاصل که با فرمت json است، دارای دو خاصیت رشتهای access_token و refresh_token باشد.
مرحلهی 3: ذخیره سازی توکنهای دریافتی در متغیرهای سراسری
مرحلهی 3: ذخیره سازی مراحل انجام شده
در حین کار با strest نیازی به ذخیره سازی نتیجهی حاصل از response، در متغیرهای خاصی نیست. برای مثال اگر بخواهیم به نتیجهی حاصل از عملیات لاگین فوق در درخواستهای بعدی دسترسی پیدا کنیم، میتوان نوشت <$ loginRequest.content.access_token $>
در اینجا درج متغیرها توسط <$ $> صورت میگیرد. سپس loginRequest به نام درخواست مرتبط اشاره میکند. خاصیت content.access_token نیز مقدار خاصیت access_token شیء response را بر میگرداند.
همچنین ذخیره سازی مراحل انجام شده نیز نکتهی خاصی را به همراه ندارد. یک تک فایل متنی JWT.strest.yml وجود دارد که آزمایشهای ما در آن درج میشوند.
مرحلهی 4: دسترسی به منابع محافظت شدهی سمت سرور
در ادامه روش تعریف دو درخواست جدید دیگر را در فایل JWT.strest.yml مشاهده میکنید که از نوع Get هستند و به اکشن متدهای محافظت شده ارسال میشوند:
myProtectedApiRequest: request: url: <$ baseUrl $>/MyProtectedApi method: GET headers: - name: Authorization value: Bearer <$ loginRequest.content.access_token $> log: <$ logResponse $> validate: - jsonpath: content.title expect: "Hello from My Protected Controller! [Authorize]" mProtectedAdminApiRequest: request: url: <$ baseUrl $>/MyProtectedAdminApi method: GET headers: - name: Authorization value: Bearer <$ loginRequest.content.access_token $> log: <$ logResponse $> validate: - jsonpath: content.title expect: "Hello from My Protected Admin Api Controller! [Authorize(Policy = CustomRoles.Admin)]"
- چون نیاز است به همراه درخواست خود، هدر اعتبارسنجی مبتنی بر JWT را که به صورت Bearer value است نیز به سمت سرور ارسال کنیم، خاصیت headers را توسط یک name/value مشخص کردهایم. همانطور که عنوان شد در فایلهای yaml، فاصلهها و تو رفتگیها مهم هستند و حتما باید رعایت شوند.
- سپس دومین آزمون نوشته شده را نیز مشاهده میکنید. در قسمت validate، مشخص کردهایم که خاصیت title دریافتی از response باید مساوی مقدار خاصی باشد.
دقیقا همین نکات برای درخواست دوم به MyProtectedAdminApi تکرار شدهاند.
مرحلهی 5: ارسال Refresh token و دریافت یک سری توکن جدید
اکشن متد account/RefreshToken در سمت سرور، نیاز دارد تا یک شیء جیسون با خاصیت refreshToken را دریافت کند. مقدار این خاصیت از طریق response متناظر با درخواست نامدار loginRequest استخراج میشود که در قسمت postData مشخص شدهاست:
refreshTokenRequest: request: url: <$ baseUrl $>/account/RefreshToken method: POST postData: mimeType: application/json text: refreshToken: <$ loginRequest.content.refresh_token $> log: <$ logResponse $> validate: - jsonpath: content.access_token type: [string] - jsonpath: content.refresh_token type: [string]
مرحلهی 6: آزمایش توکن جدید دریافتی از سرور
در قسمت قبل، توکنهای جدیدی صادر شدند که اکنون برای کار با آنها میتوان از متغیر refreshTokenRequest.content.access_toke استفاده کرد:
myProtectedApiRequestWithNewToken: request: url: <$ baseUrl $>/MyProtectedApi method: GET headers: - name: Authorization value: Bearer <$ refreshTokenRequest.content.access_token $> log: <$ logResponse $> validate: - jsonpath: content.title expect: "Hello from My Protected Controller! [Authorize]"
مرحلهی 7: آزمایش منقضی شدن توکنی که در ابتدای کار پس از لاگین دریافت کردیم
اکنون که refresh token صورت گرفتهاست، دیگر نباید بتوانیم از توکن دریافتی پس از لاگین استفاده کنیم و برنامه باید آنرا برگشت بزند:
myProtectedApiRequestWithOldToken: request: url: <$ baseUrl $>/MyProtectedApi method: GET headers: - name: Authorization value: Bearer <$ loginRequest.content.access_token $> log: <$ logResponse $> validate: - jsonpath: status expect: 401
مرحلهی 8: آزمایش خروج از سیستم
در اینجا نیاز است به آدرس account/logout، یک کوئری استرینگ را با کلید refreshToken و مقدار ریفرشتوکن دریافتی از درخواست نامدار refreshTokenRequest، به سمت سرور ارسال کنیم:
logoutRequest: request: url: <$ baseUrl $>/account/logout method: GET headers: - name: Authorization value: Bearer <$ refreshTokenRequest.content.access_token $> queryString: - name: refreshToken value: <$ refreshTokenRequest.content.refresh_token $> log: <$ logResponse $> validate: - jsonpath: content expect: true
مرحلهی 9: بررسی عدم امکان دسترسی به منابع محافظت شدهی سمت سرور، پس از logout
در مرحلهی قبل، از سیستم خارج شدیم. اکنون میخواهیم بررسی کنیم که آیا توکن دریافتی پیشین هنوز معتبر است یا خیر؟ آیا میتوان هنوز هم به منابع محافظت شده دسترسی یافت یا خیر:
myProtectedApiRequestWithNewTokenAfterLogout: request: url: <$ baseUrl $>/MyProtectedApi method: GET headers: - name: Authorization value: Bearer <$ refreshTokenRequest.content.access_token $> log: <$ logResponse $> validate: - jsonpath: status expect: 401
مرحلهی 10: اجرای تمام آزمونهای واحد نوشته شده
همانطور که در ابتدای بحث نیز عنوان شد فقط کافی است دستور strest JWT.strest.yml را در خط فرمان اجرا کنیم تا آزمونهای ما به ترتیب اجرا شوند:
فایل نهایی این آزمایش را در اینجا میتوانید مشاهده میکنید.
افزودن وابستگیهای MailKit به برنامه
برای شروع به استفادهی از MailKit، میتوان بستهی نیوگت آنرا به فایل project.json برنامه معرفی کرد:
{ "dependencies": { "MailKit": "1.10.0" } }
استفاده از MailKit جهت تکمیل وابستگیهای ASP.NET Core Identity
قسمتی از ASP.NET Core Identity، شامل ارسال ایمیلهای «ایمیل خود را تائید کنید» است که آنرا میتوان توسط MailKit به نحو ذیل تکمیل کرد:
using System.Threading.Tasks; using ASPNETCoreIdentitySample.Services.Contracts.Identity; using MailKit.Net.Smtp; using MailKit.Security; using MimeKit; namespace ASPNETCoreIdentitySample.Services.Identity { public class AuthMessageSender : IEmailSender, ISmsSender { public async Task SendEmailAsync(string email, string subject, string message) { var emailMessage = new MimeMessage(); emailMessage.From.Add(new MailboxAddress("DNT", "do-not-reply@dotnettips.info")); emailMessage.To.Add(new MailboxAddress("", email)); emailMessage.Subject = subject; emailMessage.Body = new TextPart(TextFormat.Html) { Text = message }; using (var client = new SmtpClient()) { client.LocalDomain = "dotnettips.info"; await client.ConnectAsync("smtp.relay.uri", 25, SecureSocketOptions.None).ConfigureAwait(false); await client.SendAsync(emailMessage).ConfigureAwait(false); await client.DisconnectAsync(true).ConfigureAwait(false); } } public Task SendSmsAsync(string number, string message) { // Plug in your SMS service here to send a text message. return Task.FromResult(0); } } }
در آخر، این پیام به SmtpClient جهت ارسال نهایی، فرستاده میشود. این SmtpClient هرچند هم نام مشابه آن در System.Net.Mail است اما با آن یکی نیست و متعلق است به MailKit. در اینجا ابتدا LocalDomain تنظیم شدهاست. تنظیم این مورد اختیاری بوده و صرفا به SMTP سرور دریافت کنندهی ایمیلها، مرتبط است که آیا قید آنرا اجباری کردهاست یا خیر. تنظیمات اصلی SMTP Server در متد ConnectAsync ذکر میشوند که شامل مقادیر host ،port و پروتکل ارسالی هستند.
ارسال ایمیل به SMTP pickup folder
روشی که تا به اینجا بررسی شد، جهت ارسال ایمیلها به یک SMTP Server واقعی کاربرد دارد. اما در حین توسعهی محلی برنامه میتوان ایمیلها را در داخل یک پوشهی موقتی ذخیره و آنها را توسط برنامهی Outlook (و یا حتی مرورگر Firefox) بررسی و بازبینی کامل کرد.
در این حالت تنها کاری را که باید انجام داد، جایگزین کردن قسمت ارسال ایمیل واقعی توسط SmtpClient در کدهای فوق، با قطعه کد ذیل است:
using (var stream = new FileStream($@"c:\smtppickup\email-{Guid.NewGuid().ToString("N")}.eml", FileMode.CreateNew)) { emailMessage.WriteTo(stream); }
FAQ و منبع تکمیلی
- نحوه ارسال فایل به سرور توسط ASP.NET MVC
- نحوه اعتبار سنجی سمت سرور ارسال فایلها
در ASP.NET MVC برای آپلود فایلها عموما عنوان میشود که از تگ input به نحو زیر استفاده شود:
<input type="file" name="file" />
<input type="file" data-val="true" data-val-required="لطفا فایلی را انتخاب کنید" name="file" /> @Html.ValidationMessage("file")
از این نکته خصوصا در طراحی html helperهای سفارشی نیز میتوان استفاده کرد.
برای مثال فرض کنید مشغول طراحی یک کنترل captcha هستید. قسمتی از آن مربوط به دریافت ورودی از کاربر است. به علاوه، پیغام خطایی هم که باید نمایش داده شود نیز باید توسط کاربر قابلیت سفارشی شدن را داشته باشد (و نمیتوان آنرا توسط یک attribute به سادگی به یک مدل خاص انتساب داد).
در این حالت تنظیم data-val و data-val-required به کمک anonymously typed objects پارامتر htmlAttributes میسر نیست (چون بین حروف آن dash وجود دارد) و باید از overload و نوع dictionary دار آن به نحو زیر استفاده کرد:
htmlHelper.TextBox("CaptchaInputText", string.Empty, new Dictionary<string, object> { { "data-val", "true"}, { "data-val-required", validationErrorMessage}, })