- بدست آوردن آمار بازدید وب سایت در ASP.NET MVC
شما برای این کار باید چند مرحله را انجام دهید:
مرحلهی اول: یک پروژهی جدید بسازید
نکته: برای اینکار میتوانید پروژه را از نوع ASP.NET 5 Web Application نیز انتخاب نمایید و مراحل کوتاهتری را طی نمایید. اما راه اندازی دستی قسمتهای مختلف پروژه برای یکبار، به درک بهتر ساختار آن کمک زیادی میکند. از طرفی کار کردن بر روی یک پروژهی تمیز و خالی، برای انتقال دادههای مورد نیاز از یک پروژهی دیگر، از بروز خطاهای پیش بینی نشده و تداخلهای احتمالی نیز جلوگیری میکند.
مرحلهی دوم: اعمال تنظیمات جهت
استفادهی از MVC
همان طور که مشاهده میکنید در این پروژه دیگر خبری از web.config نیست. اما نگران نباشید، امکان اعمال تنظیمات، باز هم وجود دارد و فقط به فایلهای json منتقل شدهاند که project.json هم یکی از آنهاست. برای استفادهی از Microsoft.AspNet.Mvc فقط کافی است فایل project.json را باز کنید و در قسمت "dependencies" پکیج "Microsoft.AspNet.Mvc" را به آن اضافه نمایید تا به صورت خودکار دانلود و به پروژه اضافه گردد.
"dependencies": { "Microsoft.AspNet.Server.IIS": "1.0.0-beta5", "Microsoft.AspNet.Server.WebListener": "1.0.0-beta5", "Microsoft.AspNet.Mvc": "6.0.0-beta5" },
public void ConfigureServices(IServiceCollection services) { services.AddMvc(); } public void Configure(IApplicationBuilder app) { app.UseMvc(routes => { routes.MapRoute( name: "default", template: "{controller=Home}/{action=Index}/{id?}"); }); }
<h1>My First MVC6 Website!</h1>
برنامه را اجرا کنید تا خروجی مورد انتظار را مشاهده نمایید.
مرحلهی سوم: انتقال فایلهای پروژهی قبلی به پروژهی جدید
Viewهای مربوط به این controller را نیز به پوشهی Views/Home منتقل نمایید و پروژه را بار دیگر اجرا نمایید. حال باید نمایی از محتوای این فایلها بدون اعمال استایلها را مشاهده نمایید.
همان طور که میدانیم MVC 5 برای استایل صفحات خود از bootstrap استفاده میکند و فایلهای مورد نیاز آن در پوشههای Content و Script -که در root سایت موجود هستند- قرار دارند و نیز ارجاع به این فایلها در Layout.cshtml_ قرار دارد. اما در MVC 6 قضیه کمی متفاوت و البته بهتر شده است. در MVC 6 تمام فایلهای client-side شامل css و js در پوشهی wwwroot قرار دارند و ما میتواینم فایلهای bootstrap و غیره را از پروژهی خود، به این مکان کپی نماییم. ولی روش بهتر، استفاده از ابزارهای bower و gulp برای این کار است. همان طور که میدانید bower یک package manager برای نصب، به روزرسانی و مدیریت کتابخانههای سمت کلاینت و gulp نیز یک task runner برای انجام کارهای مختلف از قبیل script minification و ... در سمت کلاینت است. gulp و bower به طور تو کار در ویژوال 2015 پشتیبانی میشوند و حتی اگر پروژهی خود را از نوع ASP.NET 5 Web Application انتخاب کرده باشید، به صورت پیش فرض از آنها استفاده میکند.
در اینجا برای استفاده، ابتدا یک فایل از نوع Bower JSON Configuration را به root پروژه اضافه کرده و آن را bower.json بنامید و در خاصیت "dependencies" آن bootstrap, jquery, jquery-validation, jquery-validation-unobtrusive را اضافه نمایید.
نکته: من در این قسمت، در restore کردن پکیجها با استفاده از bower، با خطای زیر مواجه شدم:
visual 2015 ECMDERR Failed to execute "git ls-remote --tags --heads git://github.com/jquery/jquery.git", exit code of #-532462766
من از نسخهی Visual Studio 2015 Update 1 CTP استفاده میکنم، ولی ظاهرا این مشکل در نسخههای دیگر هم وجود دارد و فایل bower.cmd ویژوال به درستی کار نمیکند. من برای حل این مشکل، ابتدا git را نصب کردم و در تنظیمات bower، مسیر پیش فرض ویژال رو به مسیر نصب git تغییر دادم. یعنی در پروژه بر روی پوشهی Bower کلیک راست و configure external tools را انتخاب کردم و تیک $(DevEnvDir)\Extensions\Microsoft\Web Tools\External\git را برداشته و در عوض مسیر پیش فرض خودم یعنی C:\Program Files\Git\bin را اضافه کردم.
اگر راه درست و اصولیتری برای حل این مشکل وجود دارد ممنون میشوم دوستان راهنمایی بفرمایند.
خب بعد از اضافه کردن خاصیت dependencies و پکیجهای مورد نیاز، خاصیت exportsOverride را نیز مانند نمونه به فایل bower.json اضافه نمایید.
{ "name": "ASP.NET", "private": true, "dependencies": { "bootstrap": "3.3.6", "jquery": "2.1.4", "jquery-validation": "1.14.0", "jquery-validation-unobtrusive": "3.2.4" }, "exportsOverride": { "bootstrap": { "js": "dist/js/*.*", "css": "dist/css/*.*", "fonts": "dist/fonts/*.*" }, "jquery": { "": "jquery.{js,min.js,min.map}" }, "jquery-validation": { "": "jquery.validate.js" }, "jquery-validation-unobtrusive": { "": "jquery.validate.unobtrusive.{js,min.js}" } } }
"devDependencies": { "gulp": "3.9.0", "rimraf": "2.4.4", "gulp-concat": "2.6.0" }
var gulp = require('gulp'); var rimraf = require('rimraf'); var paths = { bower: "./bower_components/", lib: "./wwwroot/lib/" }; gulp.task('clean', function (callback) { rimraf(paths.lib, callback); }); gulp.task('default', ['clean'], function () { var bower = { "bootstrap": "bootstrap/dist/**/*.{js,map,css,ttf,svg,woff,eot}", "jquery": "jquery/jquery*.{js,map}", "jquery-validation": "jquery-validation/jquery.validate.js", "jquery-validation-unobtrusive": "jquery-validation-unobtrusive/jquery.validate.unobtrusive.js" }; for (var destinationDir in bower) { gulp.src(paths.bower + bower[destinationDir]) .pipe(gulp.dest(paths.lib + destinationDir)); } });
اگر پردازش فوق با موفقیت و بدون خطا انجام شود، میتوانید پکیجهای ایجاد شده را در مسیر wwwroot/lib، مشاهده نمایید.
مرحلهی چهارم: ویرایش برخی از view ها
حال که پکیجهای مورد نیاز پروژه، در پوشهی wwwroot قرار گرفتند، باید view هایی که ارجاعی را به این فایلها دارند، نیز ویرایش نماییم. یکی از این فایلها Layout.cshtml_ است که در مسیر Views/Shared قرار دارد. این فایل را باز کرده و به جای متد ()Styles .Render از عنصر <link> برای لود کردن استایلهای بوت استرپ و غیره استفاده نمایید.
<link rel="stylesheet" href="~/lib/bootstrap/dist/css/bootstrap.css" /> <link rel="stylesheet" href="~/css/site.css" />
<script src="~/lib/jquery/dist/jquery.js"></script> <script src="~/lib/bootstrap/dist/js/bootstrap.js"></script>
مرحلهی پنجم(اختیاری): جایگزین کردن متدهای Html helper با ساختار Tag
Helper
یکی از ویژگیهای جالب و مفید MVC 6 ساختار TagHalper ها هستند که در واقع جایگزینی برای متدهای HtmlHelper و عملکردی مشابه به آنها دارند. البته استفاده از این ویژگی اجباری نیست ولی اگر تعداد ویوهای شما زیاد نیست و خواهان استفادهی از این قابلیت در پروژهی خود هستید، تنها کاری که باید انجام دهید، پیدا کردن HtmlHelperها و جایگزینی آنها به صورت زیر میباشد:
@Html.TextBoxFor(model => model.Name, new { style = "width: 100px" })
<input asp-for="Name" style="width: 100px" />
نتیجه گیری
همان طور ملاحظه نمودید انتقال پروژه از ASP.NET MVC 5 به ASP.NET MVC 6 شامل انجام چند مرحله است و دشواری خاصی ندارد. عمدهی این تغییرات و پیچیدگیها هم مربوط به انتقال فایلهای client-side و نحوهی کار با ابزارهای مدیریت پکیج میشود و البته تنظیماتی که در این بین باید انجام شوند. البته قسمتهای دیگری مانند تنظیمات bundling و connection string نیز با MVC 5 تفاوت هایی دارد و کار با آنها نیز بسیار ساده میباشد.
منابع اصلی Ember.js
پیش از شروع به بحث نیاز است با تعدادی از سایتهای اصلی مرتبط با Ember.js آشنا شد:
سایت اصلی: http://emberjs.com
مخزن کدهای آن: https://github.com/emberjs
انجمن اختصاصی پرسش و پاسخ: http://discuss.emberjs.com
موتور قالبهای آن: http://handlebarsjs.com
لیست منابع مطالعاتی مرتبط مانند ویدیوهای آموزشی و لیست مقالات موجود: http://emberwatch.com
و بستهی نیوگت آن: https://www.nuget.org/packages/EmberJS
مفاهیم پایهای Ember.js
شیء Application
App = Ember.Application.create();
مسیر یابی
با مرور قسمتهای مختلف برنامه توسط کاربر، نیاز است حالات برنامه را مدیریت کرد؛ اینجا است که کار قسمت مسیریابی شروع میشود. مسیریابی، منابع مورد نیاز جهت آدرسهای مشخصی را تامین میکند.
App.Router.map(function() { this.resource('accounts'); // takes us to /accounts this.resource('gallery'); // takes us to /gallery });
به این ترتیب مسیرهای accounts/ و gallery/ قابل پردازش خواهند شد.
این مسیرها، تو در تو نیز میتوانند باشند. برای مثال:
App.Router.map(function() { this.resource('news', function() { this.resource('images', function () { // takes us to /news/images this.route('add');// takes us to /news/images/add }); }); });
مدلها
مدلها همان اشیایی هستند که برنامه مورد استفاده قرار میدهد و میتوانند یک آرایهی ساده و یا اشیاء JSON دریافتی از وب سرور باشند.
حداقل به دو روش میتوان مدلها را تعریف کرد:
الف) با استفاده از افزونهی Ember Data
ب) با کمک شیء Ember.Object
App.SiteLink = Ember.Object.extend({}); App.SiteLink.reopenClass({ findAll: function() { var links = []; //… $.getJSON … return links; } });
در ادامه متد دلخواهی را ایجاد کرده و برای مثال آرایهای از اشیاء دلخواه جاوا اسکریپتی را بازگشت خواهیم داد.
پس از تعریف مدل، نیاز است آنرا به سیستم مسیریابی معرفی کرد:
App.GalleryRoute = Ember.Route.extend({ model: function() { return App.SiteLink.findAll(); } });
کنترلرها
کنترلرها جهت ارائهی اطلاعات مدلها به View و قالب برنامه تعریف میشوند. در اینجا همیشه باید بخاطر داشت که model تامین کنندهی اطلاعات است. کنترلر جهت در معرض دید قرار دادن این اطلاعات، به View برنامه کاربرد دارد و مدلها هیچ اطلاعی از وجود کنترلرها ندارند.
کنترلرها علاوه بر اطلاعات model، میتوانند حاوی یک سری خواص و اشیاء صرفا نمایشی که قرار نیست در بانک اطلاعاتی ذخیره شوند نیز باشند.
در Ember.js قالبها (templates) اطلاعات خود را از کنترلر دریافت میکنند. کنترلرها اطلاعات مدل را به همراه سایر خواص نمایشی مورد نیاز در اختیار View و قالبهای برنامه قرار میدهند.
برای تعریف یک کنترلر میتوان درون شیء مسیریابی، با تعریف متد setupController شروع کرد:
App.GalleryRoute = Ember.Route.extend({ setupController: function(controller) { controller.set('content', ['red', 'yellow', 'blue']); } });
روش دوم تعریف کنترلرها با ایجاد یک زیر کلاس از شیء Ember.Controller انجام میشود:
App.GalleryController = Ember.Controller.extend({ search: '', content: ['red', 'yellow', 'blue'], query: function() { var data = this.get('search'); this.transitionToRoute('search', { query: data }); } });
قالبها یا templates
قالبها قسمتهای اصلی رابط کاربری را تشکیل خواهند داد. در اینجا از کتابخانهای به نام handlebars برای تهیه قالبهای سمت کاربر کمک گرفته میشود.
<script type="text/x-handlebars" data-template-name="sayhello"> Hello, <strong>{{firstName}} {{lastName}}</strong>! </script>
<script type="text/x-handlebars" data-template-name="sayhello"> Hello, <strong>{{firstName}} {{lastName}}</strong>! {{#if person}} Welcome back, <strong>{{person.firstName}} {{person.lastName}}</strong>! {{/if}} <ul> {{#each friend in friends}} <li> {{friend.name}} </li> {{/each}} </ul> <img {{bindAttr src="link.url" }} /> {{#linkTo ''about}}About{{/linkTo}} </script>
بهترین مرجع آشنایی با ریز جزئیات کتابخانهی handlebars، مراجعه به سایت اصلی آن است.
قواعد پیش فرض نامگذاری در Ember.js
اگر به مثالهای فوق دقت کرده باشید، خواصی مانند GalleryController و یا GalleryRoute به شیء App اضافه شدهاند. این نوع نامگذاریها در ember.js بر اساس روش convention over configuration کار میکنند. برای نمونه اگر مسیریابی خاصی را به نحو ذیل تعریف کردید:
this.resource('employees');
کنترلر آن App.EmployeesController
مدل آن App.Employee
View آن App.EmployeesView
و قالب آن employees
بهتر است تعریف شوند. به عبارتی اگر اینگونه تعریف شوند، به صورت خودکار توسط Ember.js یافت شده و هر کدام با مسئولیتهای خاص مرتبط با آنها پردازش میشوند و همچنین ارتباطات بین آنها به صورت خودکار برقرار خواهد شد. به این ترتیب برنامه نظم بهتری خواهد یافت. با یک نگاه میتوان قسمتهای مختلف را تشخیص داد و همچنین کدنویسی پردازش و اتصال قسمتهای مختلف برنامه نیز به شدت کاهش مییابد.
تهیهی اولین برنامهی Ember.js
تا اینجا نگاهی مقدماتی داشتیم به اجزای تشکیل دهندهی هستهی Ember.js. در ادامه مثال سادهای را جهت نمایش ساختار ابتدایی یک برنامهی Ember.js، بررسی خواهیم کرد.
بستهی Ember.js را همانطور که در قسمت منابع اصلی آن در ابتدای بحث عنوان شد، میتوانید از سایت و یا مخزن کد آن دریافت کنید و یا اگر از VS.NET استفاده میکنید، تنها کافی است دستور ذیل را صادر نمائید:
PM> Install-Package EmberJS
در این حالت ترتیب تعریف اسکریپتهای مورد نیاز صفحه به صورت ذیل خواهند بود:
<script src="Scripts/jquery-2.1.1.js" type="text/javascript"></script> <script src="Scripts/handlebars.js" type="text/javascript"></script> <script src="Scripts/ember.js" type="text/javascript"></script> <script src="Scripts/app.js" type="text/javascript"></script>
App = Ember.Application.create(); App.IndexRoute = Ember.Route.extend({ setupController:function(controller) { controller.set('content', ['red', 'yellow', 'blue']); } });
App.Router.map(function() { this.resource('application'); this.resource('index'); });
<!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title></title> <script src="Scripts/jquery-2.1.1.js" type="text/javascript"></script> <script src="Scripts/handlebars.js" type="text/javascript"></script> <script src="Scripts/ember.js" type="text/javascript"></script> <script src="Scripts/app.js" type="text/javascript"></script> </head> <body> <script type="text/x-handlebars" data-template-name="index"> Hello, <strong>Welcome to Ember.js</strong>! <ul> {{#each item in content}} <li> {{item}} </li> {{/each}} </ul> </script> </body> </html>
مقدار data-template-name در اینجا مهم است. اگر آنرا به هر نام دیگری بجز index تنظیم کنید، منبع دریافت اطلاعات آن مشخص نخواهد بود. نام index در اینجا به معنای اتصال این قالب به اطلاعات ارائه شده توسط کنترلر index است.
تا همینجا اگر برنامه را اجرا کنید، به خوبی کار خواهد کرد. نکتهی دیگری که در مورد قالبهای Ember.js قابل توجه هستند، قالب پیش فرض application است. با تعریف Ember.Application.create یک چنین قالبی نیز به ابتدای هر صفحه به صورت خودکار اضافه خواهد شد:
<body> <script type="text/x-handlebars" data-template-name="application"> <h1>Header</h1> {{outlet}} </script>
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید:
EmberJS01.zip
string data = null; var result = data ?? "value";
if (data == null) { data = "value"; } var result = data;
برای مثال بسیاری از نتایج بازگشتی از متدها، چند سطحی هستند:
class Response { public string Result { set; get; } public int Code { set; get; } } class WebRequest { public Response GetDataFromWeb(string url) { // ... return new Response { Result = null }; } }
var webData = new WebRequest().GetDataFromWeb("https://www.dntips.ir/"); if (webData != null && webData.Result != null) { Console.WriteLine(webData.Result); }
در این حالت اگر اشارهگر را به محل && انتقال دهیم، افزونهی ReSharper پیشنهاد یکی کردن این بررسیها را ارائه میدهد:
به این ترتیب تمام چند سطح بررسی نال، به یک عبارت بررسی .? دار، خلاصه خواهد شد:
if (webData?.Result != null) { Console.WriteLine(webData.Result); }
البته باید دقت داشت که برای تمام سطوح باید از .? استفاده کرد (برای مثال response?.Results?.Status)؛ در غیر اینصورت همانند سابق در صورت استفادهی از دات معمولی، به یک null reference exception میرسیم.
کار با متدها و Delegates
این عملگر جدید مقایسهی با نال را بر روی متدها (علاوه بر خواص و فیلدها) نیز میتوان بکار برد. برای مثال خلاصه شدهی فراخوانی ذیل:
if (x != null) { x.Dispose(); }
x?.Dispose();
و یا بکار گیری آن بر روی delegates (روش قدیمی):
var copy = OnMyEvent; if (copy != null) { copy(this, new EventArgs()); }
OnMyEvent?.Invoke(this, new EventArgs());
استفاده از Null Conditional Operator بر روی Value types
الف) مقایسه با نال
کد ذیل را درنظر بگیرید:
var code = webData?.Code;
if (webData?.Code > 0) { }
ب) بازگشت مقدار پیش فرض دیگری بجای نال
اگر نیاز بود بجای null مقدار پیش فرض دیگری را بازگشت دهیم، میتوان از null-coalescing operator سابق استفاده کرد:
int count = response?.Results?.Count ?? 0;
ج) دسترسی به مقدار Value یک متغیر nullable
نمونهی دیگر آن قطعه کد ذیل است:
int? x = 10; //var value = x?.Value; // invalid Console.WriteLine(x?.ToString());
کار با indexer property و بررسی نال
اگر به عنوان بحث دقت کرده باشید، یک s جمع در انتهای Null-conditional operators ذکر شدهاست. به این معنا که این عملگر مقایسهی با نال، صرفا یک شکل و فرم .? را ندارد. مثال ذیل در حین کار با آرایهها و لیستها بسیار مشاهده میشود:
if (response != null && response.Results != null && response.Results.Addresses != null && response.Results.Addresses[0] != null && response.Results.Addresses[0].Zip == "63368") { }
if(response?.Results?.Addresses?[0]?.Zip == "63368") { }
موارد استفادهی ناصحیح از عملگرهای مقایسهی با نال
خوب، عملگر .? کار مقایسهی با نال را خصوصا در دسترسیهای چند سطحی به خواص و متدها بسیار ساده میکند. اما آیا باید در همه جا از آن استفاده کرد؟ آیا باید از این پس کلا استفاده از دات را فراموش کرد و بجای آن از .? در همه جا استفاده کرد؟
مثال ذیل را درنظر بگیرید:
public void DoSomething(Customer customer) { string address = customer?.Employees ?.SingleOrDefault(x => x.IsAdmin)?.Address?.ToString(); SendPackage(address); }
روش بهتر انجام اینکار، بررسی وضعیت customer و انتقال مابقی زنجیرهی LINQ به یک متد مجزای دیگر است:
public void DoSomething(Customer customer) { Contract.Requires(customer != null); string address = customer.GetAdminAddress(); SendPackage(address); }
- بررسی و طبقه بندی سیستمهای محاسبات ابری | Mohammad Shams | blog.mshams.ir
- فراخوانی متد ها به شکل یکطرفه (One-Way) در سرویس های WCF | www.30sharp.com
- BExplorer (Better Explorer) | bexplorer.codeplex.com
- Git Source Control Provider | gitscc.codeplex.com
- خاطراتی از برگزاری CSM course در ایران | blog.crisp.se
- دسترسی به GPU در دات نت به کمک C++ AMP | www.danielmoth.com
- طراحی جدید سایت ASP.NET | weblogs.asp.net
در این حالت هش کردن کلمات عبور ایدهی بهتر است. هشها روشهایی یک طرفه هستند که با داشتن نتیجهی نهایی آنها، نمیتوان به اصل کلمهی عبور مورد استفاده دسترسی پیدا کرد. برای بهبود امنیت هشهای تولیدی، میتوان از مفهومی به نام Salt نیز استفاده نمود. Salt در اصل یک رشتهی تصادفی است که پیش از هش شدن نهایی کلمهی عبور، به آن اضافه شده و سپس حاصل این جمع، هش خواهد شد. اهمیت این مساله در بالا بردن زمان یافتن کلمهی عبور اصلی از روی هش نهایی است (توسط روشهایی مانند brute force یا امتحان کردن بازهی وسیعی از عبارات قابل تصور).
اما واقعیت این است که حتی استفاده از یک Salt نیز نمیتواند امنیت بازیابی کلمات عبور هش شده را تضمین کند. برای مثال نرم افزارهایی موجود هستند که با استفاده از پرداش موازی قادرند بیش از 60 میلیارد هش را در یک ثانیه آزمایش کنند و البته این کارآیی، برای کار با هشهای متداولی مانند MD5 و SHA1 بهینه سازی شدهاست.
روش هش کردن کلمات عبور در ASP.NET Identity
ASP.NET Identity 2.x که در حال حاضر آخرین نگارش تکامل یافتهی روشهای امنیتی توصیه شدهی توسط مایکروسافت، برای برنامههای وب است، از استانداردی به نام RFC 2898 و الگوریتم PKDBF2 برای هش کردن کلمات عبور استفاده میکند. مهمترین مزیت این روش خاص، کندتر شدن الگوریتم آن با بالا رفتن تعداد سعیهای ممکن است؛ برخلاف الگوریتمهایی مانند MD5 یا SHA1 که اساسا برای رسیدن به نتیجه، در کمترین زمان ممکن طراحی شدهاند.
PBKDF2 یا password-based key derivation function جزئی از استاندارد RSA نیز هست (PKCS #5 version 2.0). در این الگوریتم، تعداد بار تکرار، یک Salt و یک کلمهی عبور تصادفی جهت بالا بردن انتروپی (بینظمی) کلمهی عبور اصلی، به آن اضافه میشوند. از تعداد بار تکرار برای تکرار الگوریتم هش کردن اطلاعات، به تعداد باری که مشخص شدهاست، استفاده میگردد. همین تکرار است که سبب کندشدن محاسبهی هش میگردد. عدد معمولی که برای این حالت توصیه شدهاست، 50 هزار است.
این استاندارد در دات نت توسط کلاس Rfc2898DeriveBytes پیاده سازی شدهاست که در ذیل مثالی را در مورد نحوهی استفادهی عمومی از آن، مشاهده میکنید:
using System; using System.Diagnostics; using System.Security.Cryptography; using System.Text; namespace IdentityHash { public static class PBKDF2 { public static byte[] GenerateSalt() { using (var randomNumberGenerator = new RNGCryptoServiceProvider()) { var randomNumber = new byte[32]; randomNumberGenerator.GetBytes(randomNumber); return randomNumber; } } public static byte[] HashPassword(byte[] toBeHashed, byte[] salt, int numberOfRounds) { using (var rfc2898 = new Rfc2898DeriveBytes(toBeHashed, salt, numberOfRounds)) { return rfc2898.GetBytes(32); } } } class Program { static void Main(string[] args) { var passwordToHash = "VeryComplexPassword"; hashPassword(passwordToHash, 50000); Console.ReadLine(); } private static void hashPassword(string passwordToHash, int numberOfRounds) { var sw = new Stopwatch(); sw.Start(); var hashedPassword = PBKDF2.HashPassword( Encoding.UTF8.GetBytes(passwordToHash), PBKDF2.GenerateSalt(), numberOfRounds); sw.Stop(); Console.WriteLine(); Console.WriteLine("Password to hash : {0}", passwordToHash); Console.WriteLine("Hashed Password : {0}", Convert.ToBase64String(hashedPassword)); Console.WriteLine("Iterations <{0}> Elapsed Time : {1}ms", numberOfRounds, sw.ElapsedMilliseconds); } } }
پیش فرضهای پیاده سازی Rfc2898DeriveBytes استفاده از الگوریتم SHA1 با 1000 بار تکرار است؛ چیزی که دقیقا در ASP.NET Identity 2.x بکار رفتهاست.
تفاوتهای الگوریتمهای هش کردن اطلاعات در نگارشهای مختلف ASP.NET Identity
اگر به سورس نگارش سوم ASP.NET Identity مراجعه کنیم، یک چنین کامنتی در ابتدای آن قابل مشاهده است:
/* ======================= * HASHED PASSWORD FORMATS * ======================= * * Version 2: * PBKDF2 with HMAC-SHA1, 128-bit salt, 256-bit subkey, 1000 iterations. * (See also: SDL crypto guidelines v5.1, Part III) * Format: { 0x00, salt, subkey } * * Version 3: * PBKDF2 with HMAC-SHA256, 128-bit salt, 256-bit subkey, 10000 iterations. * Format: { 0x01, prf (UInt32), iter count (UInt32), salt length (UInt32), salt, subkey } * (All UInt32s are stored big-endian.) */
در یک چنین حالتی بانک اطلاعاتی ASP.NET Identity 2.x شما با نگارش بعدی سازگار نخواهد بود و تمام کلمات عبور آن باید مجددا ریست شده و مطابق فرمت جدید هش شوند. بنابراین امکان انتخاب الگوریتم هش کردن را نیز پیش بینی کردهاند.
در نگارش دوم ASP.NET Identity، متد هش کردن یک کلمهی عبور، چنین شکلی را دارد:
public static string HashPassword(string password, int numberOfRounds = 1000) { if (password == null) throw new ArgumentNullException("password"); byte[] saltBytes; byte[] hashedPasswordBytes; using (var rfc2898DeriveBytes = new Rfc2898DeriveBytes(password, 16, numberOfRounds)) { saltBytes = rfc2898DeriveBytes.Salt; hashedPasswordBytes = rfc2898DeriveBytes.GetBytes(32); } var outArray = new byte[49]; Buffer.BlockCopy(saltBytes, 0, outArray, 1, 16); Buffer.BlockCopy(hashedPasswordBytes, 0, outArray, 17, 32); return Convert.ToBase64String(outArray); }
پیاده سازی ساده Google Recaptcha در ASP.NET MVC
- یک چنین سطری در برنامههای ASP.NET نباید وجود داشته باشد:
if (!Task.Run(() => client.IsAcceptAsync(response, secretkey)).Result)
اگر در نگارش 5x از Task.Run استفاده کنید، سبب بروز این مشکلات خواهید شد:
- تداخل با thread pool خود ASP.NET که سبب کاهش کارآیی برنامه با مصرف تردی اضافی میشود.
- سبب اجرای قطعه کد قرار گرفتهی درون آن، خارج از request context جاری میشود.
یعنی در اینجا یک ترد جدید را ایجاد کردید و همچنین با استفاده از Result اجرای غیرهمزمان کدهای داخل آنرا سد کردید. این یک سطر باز هم غیرهمزمان اجرا میشود. بنابراین نیازی به Task.Run ندارد؛ چون با مصرف کردن یک ترد اضافی، جلوی پاسخدهی برنامه را به یک درخواست ممکن میگیرد.
همچنین بجای استفادهی از Result هم به این صورت عمل کنید:
if (!client.IsAcceptAsync(response, secretkey).GetAwaiter().GetResult())
- از قطعه کد زیر استفاده نکنید. اطلاعات بیشتر
using (var client = new HttpClient())
یک response از سه قسمت هدر، status code و بدنهی آن تشکیل میشود. بنابراین هر سه قسمت را باید آزمایش کرد تا بتوان توسط آن عملکرد یک Web API را بررسی نمود.
برای مثال فرض کنید که میخواهید برای متد Put، آزمایش بنویسید. این آزمایش باید شامل موارد زیر باشد:
بررسی موفقیت آمیز بودن عملیات
- آیا هدرهای درستی در response درج شدهاند؟
- آیا status code دریافتی از سرور برای مثال 200 یا 204 است؟
- آیا عملیات به روز رسانی، موجودیت مشخص و مورد انتظاری را به روز رسانی کردهاست یا خیر؟
- آیا تمام فیلدها به درستی به روز رسانی شدهاند؟
- آیا فیلدهایی که در درخواست ارسالی قید نشدهاند، با مقدار پیشفرض خود مقدار دهی شدهاند؟
بررسی شکست عملیات
- آیا به روز رسانی موجودیتی که وجود ندارد، خروجی 404 را به همراه دارد یا خیر؟
- آیا اگر هدر content-type ذکر نشود، شاهد status code=415 unsupported media type خواهیم بود؟
- آیا اگر هدر content-type نامربوطی ذکر شود، شاهد status code=415 unsupported media type خواهیم بود؟
- آیا اگر بدنهی درخواست خالی را ارسال کنیم، خروجی 400 bad request صادر میشود؟
- آیا اگر فیلدها را طوری تنظیم کنیم که سبب مشکلات اعتبارسنجی شوند، خروجی 422 unprocessable entity صادر میشود؟
بنابراین در حالت کلی:
- هر دو وضعیت موفقیت آمیز بودن و شکست عملیات باید بررسی شوند.
- مشکلات اعتبارسنجی ورودیها باید بررسی شوند.
- ورودیهای مورد انتظار را کم و زیاد کنید. اگر درخواستی قرار است کوئری استرینگی را بپذیرد، آنرا قید نکنید یا برعکس.
EF Core چیست؟
EF Core یک ORM یا object-relational mapper چندسکویی است که امکان کار با بانکهای اطلاعاتی مختلف را از طریق اشیاء دات نتی میسر میکند. توسط آن قسمت عمدهی کدهای مستقیم کار با بانکهای اطلاعاتی حذف شده و تبدیل به کدهای دات نتی میشوند. مزیت این لایهی Abstraction اضافی (لایهای بر روی کدهای مستقیم لایه ADO.NET زیرین)، امکان تعویض بانک اطلاعاتی مورد استفاده، تنها با تغییر کدهای آغازین برنامهاست؛ بدون نیاز به تغییری در سایر قسمتهای برنامه. همچنین کار با اشیاء دات نتی و LINQ، مزایایی مانند تحت نظر قرار گرفتن کدها توسط کامپایلر و برخورداری از ابزارهای Refactoring پیشرفته را میسر میکنند. به علاوه SQL خودکار تولیدی توسط آن نیز همواره پارامتری بوده و مشکلات حملات تزریق SQL در این حالت تقریبا به صفر میرسند (اگر مستقیما SQL نویسی نکنید و صرفا از LINQ استفاده کنید). مزیت دیگر همواره پارامتری بودن کوئریها، رفتار بسیاری از بانکهای اطلاعاتی با آنها همانند رویههای ذخیره شده است که به عدم تولید Query planهای مجزایی به ازای هر کوئری رسیده منجر میشود که در نهایت سبب بالا رفتن سرعت اجرای کوئریها و مصرف حافظهی کمتری در سمت سرور بانک اطلاعاتی میگردد.
تفاوت EF Core با نگارشهای دیگر Entity framework در چیست؟
سورس باز بودن
EF از نگارشهای آخر آن بود که سورس باز شد؛ اما EF Core از زمان نگارشهای پیش نمایش آن به صورت سورس باز در GitHub قابل دسترسی است.
چند سکویی بودن
EF Core برخلاف EF 6.x (آخرین نگارش مبتنی بر Full Framework آن)، نه تنها چندسکویی است و قابلیت اجرای بر روی Mac و لینوکس را نیز دارا است، به علاوه امکان استفادهی از آن در انواع و اقسام برنامههای دات نتی مانند UWP یا Universal Windows Platform و Windows phone که پیشتر با EF 6.x میسر نبود، وجود دارد. لیست این نوع سکوها و برنامههای مختلف به شرح زیر است:
• All .NET application (Console, ASP.NET 4, WinForms, WPF) • Mac and Linux applications (Mono) • UWP (Universal Windows Platform) • ASP.NET Core applications • Can use EF Core in Windows phone and Windows store app
افزایش تعداد بانکهای اطلاعاتی پشتیبانی شده
در EF Full یا EF 6.x، هدف اصلی، تنها کار با بانکهای اطلاعاتی رابطهای بود و همچنین مایکروسافت صرفا نگارشهای مختلف SQL Server را به صورت رسمی پشتیبانی میکرد و برای سایر بانکهای اطلاعاتی دیگر باید از پروایدرهای ثالث استفاده کرد.
در EF Core علاوه بر افزایش تعداد پروایدرهای رسمی بانکهای اطلاعاتی رابطهای، پشتیبانی از بانکهای اطلاعاتی NoSQL هم اضافه شدهاست؛ به همراه پروایدر ویژهای به نام In Memory جهت انجام سادهتر Unit testing. کاری که با نگارشهای پیشین EF به سادگی و از روز اول پشتیبانی نمیشد.
حذف و یا عدم پیاده سازی تعدادی از قابلیتهای EF 6.x
اگر موارد فوق جزو مهمترین مزایای کار با EF Core باشند، باید درنظر داشت که به علت حذف و یا تقلیل یافتن یک سری از ویژگیها در NET Core.، مانند Reflection (جهت پشتیبانی از دات نت در سکوهای مختلف کاری و خصوصا پشتیبانی از حالتی که کامپایلر مخصوص برنامههای UWP نیاز دارد تمام نوعها را همانند زبانهای C و ++C، در زمان کامپایل بداند)، یک سری از قابلیتهای EF 6.x مانند Lazy loading هنوز در EF Core پشتیبانی نمیشوند. لیست کامل و به روز شدهی این موارد را در اینجا میتوانید مطالعه کنید.
بنابراین امکان انتقال برنامههای EF 6.x به EF Core 1.0 عموما وجود نداشته و نیاز به بازنویسی کامل دارند. هرچند بسیاری از مفاهیم آن با EF Code First یکی است.
برپایی تنظیمات اولیهی EF Core 1.0 در یک برنامهی ASP.NET Core 1.0
برای نصب تنظیمات اولیهی EF Core 1.0 در یک برنامهی ASP.NET Core 1.0، جهت کار با مشتقات SQL Server (و SQL LocalDB) نیاز است سه بستهی ذیل را نصب کرد (از طریق منوی Tools -> NuGet Package Manager -> Package Manager Console):
PM> Install-Package Microsoft.EntityFrameworkCore.SqlServer PM> Install-Package Microsoft.EntityFrameworkCore.Tools -Pre PM> Install-Package Microsoft.EntityFrameworkCore.SqlServer.Design
پس از اجرای سه دستور فوق، تغییرات مداخل فایل project.json برنامه به صورت ذیل خواهند بود:
{ "dependencies": { // same as before "Microsoft.EntityFrameworkCore.SqlServer": "1.0.0", "Microsoft.EntityFrameworkCore.Tools": "1.0.0-preview2-final", "Microsoft.EntityFrameworkCore.SqlServer.Design": "1.0.0" } }
{ "dependencies": { // same as before "Microsoft.EntityFrameworkCore.SqlServer": "1.0.0", "Microsoft.EntityFrameworkCore.Tools": { "version": "1.0.0-preview2-final", "type": "build" }, "Microsoft.EntityFrameworkCore.SqlServer.Design": { "version": "1.0.0", "type": "build" } }, "tools": { // same as before "Microsoft.EntityFrameworkCore.Tools": { "version": "1.0.0-preview2-final", "imports": [ "portable-net45+win8" ] } } }
بنابراین از همین ابتدای کار، بدون مراجعهی به Package Manager Console، چهار تغییر فوق را به فایل project.json اعمال کرده و آنرا ذخیره کنید؛ تا کار به روز رسانی و نصب بستهها، به صورت خودکار و همچنین صحیحی انجام شود.
فعال سازی صفحات مخصوص توسعه دهندههای EF Core 1.0
در مطلب «ارتقاء به ASP.NET Core 1.0 - قسمت 5 - فعال سازی صفحات مخصوص توسعه دهندهها» با تعدادی از اینگونه صفحات آشنا شدیم. برای EF Core نیز بستهی مخصوصی به نام Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore وجود دارد که امکان فعال سازی صفحهی نمایش خطاهای بانک اطلاعاتی را میسر میکند. بنابراین ابتدا به فایل project.json مراجعه کرده و این بسته را اضافه کنید:
{ "dependencies": { // same as before "Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore": "1.0.0" } }
public void Configure(IApplicationBuilder app, IHostingEnvironment env) { if (env.IsDevelopment()) { app.UseDatabaseErrorPage(); }
تعریف اولین Context برنامه و مشخص سازی رشتهی اتصالی آن
در این تصویر، زیر ساخت نگاشتهای EF Core را مشاهده میکنید. در سمت چپ، ظرفی را داریم به نام DB Context که در برگیرندهی Db Setها است. در سمت راست که بیانگر ساختار کلی یک بانک اطلاعاتی است، معادل اینها را مشاهده میکنیم. هر Db Set به یک جدول بانک اطلاعاتی نگاشت خواهد شد و متشکل است از کلاسی به همراه یک سری خواص که اینها نیز به فیلدها و ستونهای آن جدول در سمت بانک اطلاعاتی نگاشت میشوند.
بنابراین برای شروع کار، پوشهای را به نام Entities به پروژه اضافه کرده و سپس کلاس ذیل را به آن اضافه میکنیم:
namespace Core1RtmEmptyTest.Entities { public class Person { public int PersonId { get; set; } public string FirstName { get; set; } public string LastName { get; set; } } }
using Microsoft.EntityFrameworkCore; namespace Core1RtmEmptyTest.Entities { public class ApplicationDbContext : DbContext { public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options) : base(options) { } public DbSet<Person> Persons { get; set; } } }
سازندهی این کلاس نیز به نحو خاصی تعریف شدهاست. اگر به سورسهای EF Core مراجعه کنیم، کلاس پایهی DbContext دارای دو سازندهی با و بدون پارامتر است:
protected DbContext() : this((DbContextOptions) new DbContextOptions<DbContext>()) { } public DbContext([NotNull] DbContextOptions options) { // … }
using Microsoft.EntityFrameworkCore; namespace Core1RtmEmptyTest.Entities { public class ApplicationDbContext : DbContext { public DbSet<Person> Persons { get; set; } protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { optionsBuilder.UseSqlServer(@"... connection string ..."); } } }
اما چون در یک برنامهی ASP.NET Core، کار ثبت سرویس مربوط به EF Core، در کلاس آغازین برنامه انجام میشود و در آنجا به سادگی میتوان به خاصیت Configuration برنامه دسترسی یافت و توسط آن رشتهی اتصالی را دریافت کرد، مرسوم است از سازندهی با پارامتر DbContext به نحوی که در ابتدا عنوان شد، استفاده شود.
بنابراین در ادامه، پس از مطالعهی مطلب «ارتقاء به ASP.NET Core 1.0 - قسمت 7 - کار با فایلهای config» به فایل appsettings.json مراجعه کرده و تنظیمات رشتهی اتصالی برنامه را به صورت ذیل در آن مشخص میکنیم:
{ "ConnectionStrings": { "ApplicationDbContextConnection": "Data Source=(local);Initial Catalog=TestDbCore2016;Integrated Security = true" } }
در اینجا به وهلهی پیش فرض SQL Server اشاره شدهاست؛ از حالت اعتبارسنجی ویندوزی SQL Server استفاده میشود و بانک اطلاعاتی جدیدی به نام TestDbCore2016 در آن مشخص گردیدهاست.
پس از تعریف رشتهی اتصالی، متد OnConfiguring را از کلاس ApplicationDbContext حذف کرده و از همان نگارش دارای سازندهی با پارامتر آن استفاده میکنیم. برای اینکار به کلاس آغازین برنامه مراجعه کرده و توسط متد AddDbContext این Context را به سرویسهای ASP.NET Core معرفی میکنیم:
public class Startup { public IConfigurationRoot Configuration { set; get; } public Startup(IHostingEnvironment env) { var builder = new ConfigurationBuilder() .SetBasePath(env.ContentRootPath) .AddJsonFile("appsettings.json", reloadOnChange: true, optional: false) .AddJsonFile($"appsettings.{env}.json", optional: true); Configuration = builder.Build(); } public void ConfigureServices(IServiceCollection services) { services.AddSingleton<IConfigurationRoot>(provider => { return Configuration; }); services.AddDbContext<ApplicationDbContext>(options => { options.UseSqlServer(Configuration["ConnectionStrings:ApplicationDbContextConnection"]); });
بنابراین قسمت options.UseSqlServer را یا در اینجا مقدار دهی میکنید و یا از طریق بازنویسی متد OnConfiguring کلاس Context برنامه.
یک نکته: امکان تزریق IConfigurationRoot به کلاس Context برنامه وجود دارد
با توجه به اینکه Context برنامه را به صورت یک سرویس به ASP.NET Core معرفی کردیم، امکان تزریق وابستگیها نیز در آن وجود دارد. یعنی بجای روش فوق، میتوان IConfigurationRoot را به سازندهی کلاس Context برنامه نیز تزریق کرد:
using Microsoft.EntityFrameworkCore; using Microsoft.Extensions.Configuration; namespace Core1RtmEmptyTest.Entities { public class ApplicationDbContext : DbContext { private readonly IConfigurationRoot _configuration; public ApplicationDbContext(IConfigurationRoot configuration) { _configuration = configuration; } //public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options) : base(options) //{ //} public DbSet<Person> Persons { get; set; } protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { optionsBuilder.UseSqlServer(_configuration["ConnectionStrings:ApplicationDbContextConnection"]); } } }
در این حالت متد ConfigureServices کلاس آغازین برنامه، چنین شکلی را پیدا میکند و ساده میشود:
public void ConfigureServices(IServiceCollection services) { services.AddDbContext<ApplicationDbContext>();
یک نکته: امکان تزریق ApplicationDbContext به تمام کلاسهای برنامه وجود دارد
همینقدر که ApplicationDbContext را به عنوان سرویسی در ConfigureServices تعریف کردیم، امکان تزریق آن در اجزای مختلف یک برنامهی ASP.NET Core نیز وجود دارد:
using System.Linq; using Core1RtmEmptyTest.Entities; using Microsoft.AspNetCore.Mvc; namespace Core1RtmEmptyTest.Controllers { public class TestDBController : Controller { private readonly ApplicationDbContext _ctx; public TestDBController(ApplicationDbContext ctx) { _ctx = ctx; } public IActionResult Index() { var name = _ctx.Persons.First().FirstName; return Json(new { firstName = name }); } } }
در این حالت پس از اجرای برنامه، خطای ذیل را مشاهده خواهیم کرد:
علت اینجا است که هنوز این بانک اطلاعاتی ایجاد نشدهاست و همچنین ساختار جداول را به آن منتقل نکردهایم که این موارد را در قسمتهای بعدی مرور خواهیم کرد.