وحید نصیری وحید نصیری
مطالب
مشکل همزمانی خواندن و به روز رسانی اطلاعات در برنامه‌های وب
فرض کنید در برنامه‌ی خود «کیف پولی» را طراحی کرده‌اید که بر اساس آن، کاربر می‌تواند خرید کند. این کیف پول، از Id کاربر و موجودی فعلی او تشکیل می‌شود:
CREATE TABLE accounts (
user_id INTEGER PRIMARY KEY,
balance INTEGER NOT NULL
);
و برای مثال موجودی فعلی کاربر 1، مقدار 300 است:
INSERT INTO accounts(user_id, balance)
VALUES (1, 300);
اکنون کوئری‌های متداول زیر را که از یک read و سپس update تشکیل شده‌اند، درنظر بگیرید:
DECLARE @amount INT;

SET @amount = (
SELECT balance
FROM accounts
WHERE user_id = 1
);

SELECT @amount as 'balance'

UPDATE accounts
SET balance =  @amount - 100
WHERE user_id = 1;

SELECT balance as 'balance after shopping'
FROM accounts
WHERE user_id = 1
- دو عمل read و سپس update صورت گرفته‌ی فوق، مربوط به یک درخواست خرید است.
- در اینجا مقدار متغیر amount در ابتدای کار، مساوی 300 است که مربوط به همان insert ابتدایی است.
- سپس از این مقدار در کوئری دومی (برای مثال حاصل از خرید شماره یک)، 100 واحد کم می‌شود (برای مثال قیمت کل خرید است).
- در این حالت نتیجه‌ی آن یا همان موجودی جدید کاربر، 200 خواهد بود.

معادل این عملیات در EF-Core چنین دستورات متداولی است:
var account1 =  context.Accounts.First(x => x.UserId == 1);
account1.Balance -= 100;
context.SaveChanges();

سؤال: اگر کوئری‌های فوق را در یک برنامه‌ی ذاتا چند ریسمانی وب، دوبار به صورت همزمان اجرا کنیم، یعنی دو عمل خرید موازی را شبیه سازی کنیم، چه اتفاقی رخ می‌دهد؟ آیا موجودی نهایی اینبار برای مثال 100 می‌شود (با فرض 300 بودن موجودی ابتدایی)؟
پاسخ خیر است! و آن‌را می‌توانید در تصویر زیر مشاهده کنید:



در اینجا برای شبیه سازی اجرای موازی دو کوئری، از دستور WAITFOR TIME استفاده شده‌است که برای برای آزمایش آن می‌توانید مقدار آن‌را به یک دقیقه بعد تنظیم کرده و سپس آن‌را در دو پنجره‌ی SQL server management studio اجرا کنید.
همانطور که مشاهده می‌کنید، با اجرای موازی این دو کوئری، یعنی دوبار خرید کردن همزمان، 100 واحد گم شده‌است ! به این مشکل همزمانی read و سپس update رخ داده، یک «race condition» گفته می‌شود و این روزها که مطالب منتشر شده‌ی از آسیب پذیری‌های برنامه‌های وب ایرانی را بررسی می‌کنم، این مورد در صدر آن‌ها قرار دارد!
علت اینجا است که عموما برنامه نویس‌ها، برنامه‌های وب را در یک تک سشن باز شده‌ی توسط مرورگر خود آزمایش می‌کنند و در این حالت، همه چیز خوب است و اعمال آن به ترتیب پیش می‌روند. اما فراموش می‌کنند که می‌توان قسمت‌های مختلف برنامه‌های وب را به صورت همزمان، موازی و چندباره نیز اجرا کرد؛ حتی اگر آن قسمت متعلق به یک کاربر باشد.


سؤال: آیا استفاده تراکنش‌ها این مشکل را حل نمی‌کنند؟!

عموما برنامه نویس‌ها تصور می‌کنند که می‌توانند تمام اینگونه مشکلات را با تراکنش‌ها حل کنند:



همانطور که مشاهده می‌کنید، اینبار هرچند هر دو عملیات خرید داخل BEGIN TRAN و COMMIT TRAN قرار گرفته‌اند، اما ... مشکل همزمانی هنوز پابرجا است! چون نوع پیش‌فرض تراکنش مورد استفاده، READ COMMITTED isolation level است و عدم دقت به آن ممکن است این تصور را ایجاد کند که با تعریف تراکنش‌ها، تمام مشکلات همزمانی برطرف می‌شوند.


راه‌حل‌های پیشنهادی جهت حل مشکل همزمانی عملیات read/update

برای حل مشکلات مرتبط با race condition و همزمانی درخواست‌های read/update، می‌توان از یکی از روش‌های زیر استفاده کرد:
الف) بجای اینکه یکبار کوئری read و یکبار کوئری update به صورت جداگانه صادر شوند، فقط یکبار کوئری update داشته باشیم.
ب) پیاده سازی Row level locking؛ در صورت پشتیبانی بانک اطلاعاتی مورد استفاده از آن
ج) استفاده از تراکنش‌هایی از نوع SERIALIZABLE
د) پیاده سازی optimistic locking

این موارد را در ادامه با توضیحات بیشتری بررسی می‌کنیم.


الف) پرهیز از خواندن و به روز رسانی جداگانه

بجای اینکه مانند اعمال فوق، یکبار select داشته باشیم و یکبار  update، بهتر است فقط یک دستور update بکارگرفته شود:
UPDATE accounts
SET balance =  balance - 100
WHERE user_id = 1;


اینبار با خلاصه شدن دو دستور select و update به یک دستور update، دیگر پس از دو خرید همزمان، 100 واحد گم شده مشاهده نمی‌شود (!) و موجودی نهایی صحیح است.


ب) پیاده سازی Row level locking

همیشه امکان تغییر عملیات مورد نیاز، به سادگی حالت الف نیست. در یک چنین حالت‌هایی جهت حداقل شدن تغییرات مورد نیاز، می‌توان از row level locking استفاده کرد:
WAITFOR TIME '13:47:00';

SET NOCOUNT, XACT_ABORT ON;

BEGIN TRAN;

DECLARE @amount INT;

SET @amount = (
 SELECT balance
 FROM accounts WITH (UPDLOCK, HOLDLOCK)
 WHERE user_id = 1
 );

SELECT @amount as 'initial user''s balance'

UPDATE accounts
SET balance =  @amount - 100
WHERE user_id = 1;

SELECT balance as 'user''s balance after shopping 1'
FROM accounts
WHERE user_id = 1;

COMMIT TRAN;



در اینجا اضافه شدن WITH (UPDLOCK, HOLDLOCK) را به Select تعریف شده، مشاهده می‌کنید که به آن‌ها locking hints هم گفته می‌شود و داخل BEGIN TRAN و COMMIT TRAN عمل می‌کنند (که نوع پیش‌فرض آن READ COMMITTED isolation level است). کار UPDLOCK، تبدیل shared lock پیش‌فرض، به update lock است و کار HOLDLOCK، نگه داشتن قفل صورت گرفته تا پایان کار تراکنش تعریف شده‌است.
با این تغییرات، هر تراکنش همزمان دیگری، تا زمانیکه قفل صورت گرفته‌ی بر روی ردیف select، رها نشود (یعنی تا زمانیکه تراکنش قفل کننده، به COMMIT TRAN برسد)، نمی‌تواند آن‌را تغییر دهد. به همین جهت است که در تصویر فوق، هرچند هر دو عملیات همزمان اجرا شده‌اند، اما یکی موجودی ابتدایی 300 را می‌بیند و دیگری پس از صبر کردن تا پایان تراکنش و رها شدن قفل، موجودی تغییر یافته‌ی جدیدی را مشاهده کرده و از آن استفاده می‌کند. به این ترتیب دیگر 100 واحدی که در اولین تصویر این مطلب مشاهده کردید، گم نشده‌است.


ج) استفاده از تراکنش‌هایی از نوع SERIALIZABLE

بجای استفاده از روش row level locking یاد شده، روش دیگری را که می‌توان استفاده کرد، تغییر نوع پیش‌فرض تراکنش مورد استفاده‌است. برای مثال اگر از یک SERIALIZABLE transaction استفاده کنیم؛ یعنی SET TRANSACTION ISOLATION LEVEL SERIALIZABLE  را در ابتدای کار ذکر کنیم و برای مثال دو تراکنش همزمان را اجرا کنیم، اگر در تراکنش اول اطلاعاتی خوانده شود، در هیچ تراکنش دیگری نمی‌توان این اطلاعات خوانده شده را تا پایان کار تراکنش اول، تغییر داد:




د) پیاده سازی optimistic locking

پیاده سازی optimistic locking و یا Optimistic concurrency control عموما در سمت برنامه رخ می‌دهد و توسط ORMها زیاد مورد استفاده قرار می‌گیرد؛ مانند اضافه کردن ستون اضافی version و یا timestamp به جداول تعریف شده. در این حالت تمام updateها به همراه یک where اضافی هستند تا بررسی کنند که آیا version دریافتی در حین خواندن ردیف در حال به روز رسانی، تغییر کرده‌است یا خیر؟ اگر تغییر کرده‌است، تراکنش را با خطایی خاتمه خواهند داد. این روش برخلاف حالت‌های ب و ج، حتی خارج از یک تراکنش نیز کار می‌کند و مشکلات قفل کردن طولانی مدت رکوردها توسط آن‌ها را به همراه ندارد.
‫۲ سال و ۱ ماه قبل، دوشنبه ۳۱ مرداد ۱۴۰۱، ساعت ۱۹:۴۵
آرش خوشبخت آرش خوشبخت
مطالب
WatIn - Web Application Testing in .Net
معرفی:
امروزه تست کردن کدها به دلیل وجود ابزارهای مختلف زیادی، کار آسانی شده است. اما بعضی‌ها در web application ها، یکی از تست‌هایی را که خیلی هم مهم است را فراموش می‌کنند که آن هم تست UI است. شما را در این مقاله با یکی از روش‌های خوب تست UI آشنا خواهم کرد. ابزارهای زیادی برای تست UI وجود دارد که کار کردن با آنها نه تنها زمان بر بلکه بسیار خسته کننده می‌باشند و به خاطر همین خیلی‌ها از انجام تست UI صرف نظر می‌کنند.
WatIn چیست؟
WatIn مخفف Web Application Testing in .Net می‌باشد؛ که یک فریم ورک تست web application‌ها است. WatIn این اجازه را به شما می‌دهد که با استفاده از IE ویا FireFox عناصر داخل صفحات را مقدار دهی کنید و یا حتی رویدادی را برای عناصر فراخوانی کنید.
شروع کار با WatIn:
در زیر یک نمونه از کار با WatIn را می‌توانید مشاهده کنید:
[TestMethod] 
public void SearchForWatiNOnGoogle()
{
  using (var browser = new IE("http://www.google.com"))
  {
    browser.TextField(Find.ByName("q")).TypeText("WatiN");
    browser.Button(Find.ByName("btnG")).Click();
    Assert.IsTrue(browser.ContainsText("WatiN"));
  }
}
WatIn یک فریم ورک کاربر پسند است و در ادامه متوجه می‌شوید که استفاده از این فریم ورک چه مزایایی دارد. برای نصب، WatIn را می‌توانید از اینجا دانلود کنید ویا اگر خواستید می‌توانید با NuGet هم این فریم ورک را دانلود کرده و نصب نمایید. برای شروع کار با Watin باید reference هایی را به پروژه تان اضافه کنید که یکی از این reference‌ها WatiN.Core.dll می‌باشد و برای استفاده از IE ویا FireFox باید فضای نام Watin.Core را اضافه کنیم. Watin چند فضای نام دیگری را هم به همراه دارد که در زیر به توضیح مختصری از آن‌ها می‌پردازیم:

1- Watin.Core.DialogHandlers: این فضای نام این امکان را به شما می‌دهد تا دیالوگ هایی را که مرورگر می‌تواند به کاربر نمایش دهد، مدیریت کنید. از handler‌های این فضای نام AlertDialogHandler، ConfirmDialogHandler، FileUploadDialogHandler، PrintDialogHandler و LoginDialogHandler می‌باشد.
2- Watin.Core.Exceptions: این فضای نام دارای یک سری exception می‌باشد و این امکان را به ما می‌دهد تا یک سری رفتارهای ناخواسته را کنترل کنیم. بعضی از این exception‌ها ElementNotFoundException، IENotFoundException، TimeoutException و WatinException می‌باشد.
3- Watin.Core.Logging: این فضای نام کلاس هایی را در اختیار ما می‌گذارد تا بتوانیم عملیاتی را که در کدمان انجام می‌دهیم log کنیم.

مثالی از watin که در بالا نشان دادیم به این صورت عمل می‌کند که مرورگر IE را باز کرده و به سایت google خواهد رفت. در این صفحه جعبه متنی یا TextBox با نام "q" را پیدا کرده و عبارت "Watin" را در آن تایپ می‌کند و همچنین Buttonی با نام "btnG" پیدا کرده و آن را کلیک می‌نماید و در آخر بررسی می‌کند که در مرورگر متنی شامل WatIn وجود دارد یا خیر.
مشاهده کردید که به همین سادگی یک تست UI نوشتیم. به نظر شما جالب نبود؟ فرض کنید که اگر می‌خواستید با مثلا Microsoft Test Manager این کار را انجام دهید چه دردسرهایی را باید تحمل می‌کردید. حالا تست UI برای همه برنامه نویس‌ها جذاب خواهد شد.
به جای مثال بالا می‌توانیم به صورت زیر هم عمل کنیم:
[TestMethod] 
public void SearchForWatiNOnGoogle()
{
  using (var browser = new IE("http://www.google.com"))
  {
    browser.TextField(Find.ByName("q")).Value="WatiN";
    browser.Button(Find.ByName("btnG")).ClickNoWait();
    Thread.Sleep(3000);
    Assert.IsTrue(browser.ContainsText("WatiN"));
  }
}
تفاوت کد دوم با کد اول این است چون در کد اول از متد TypeText استفاده کردیم یک مقدار سرعت تست را پایین می‌آورد ولی اگر از Value ویا از SetAttribute استفاده کنیم دیگر عمل تایپ را انجام نداده و مقدار را مستقیما در مقدار TextField قرار می‌دهد. شاید بپرسید چرا بعد از متد ClickNoWait چند ثانیه صبر می‌کنم؟ چون صفحه برای اینکه بارگذاری شود و نتیجه جستجو را نشان دهد کمی طول کشیده و Assert.IsTrue شما Failed می‌شود. البته به جای Thread.Sleep می‌توانیم از متدهای مربوط به Watin هم استفاده کنیم مانند WaitUntilComplete ویا از WaitUntilContainsText.
‫۱۱ سال و ۷ ماه قبل، یکشنبه ۲۵ فروردین ۱۳۹۲، ساعت ۰۱:۳۵
وحید نصیری وحید نصیری
مطالب
کش کردن اطلاعات غیر پویا در ASP.Net - قسمت دوم

قسمت قبل به IIS7‌ اختصاص داشت که شاید برای خیلی‌ها کاربرد نداشته باشد خصوصا اینکه برنامه نویس‌ها ترجیح می‌دهند به روش‌هایی روی بیاورند که کمتر نیاز به دخالت مدیر سرور داشته باشد؛ یا زمانیکه سایت شما بر روی یک هاست اینترنتی قرار گرفته است عملا شاید دسترسی خاصی به تنظیمات IIS نداشته باشید (مگر اینکه یک هاست اختصاصی را تهیه کنید).
برای IIS6 و ماقبل از آن و حتی بعد از آن!، حداقل دو روش برای کش کردن اطلاعات استاتیک وجود دارد:

الف) استفاده از web resources معرفی شده در ASP.Net 2.0 به بعد
در مورد نحوه‌ی تعریف و بکارگیری web resources می‌توان به مقاله "تبدیل پلاگین‌های jQuery‌ به کنترل‌های ASP.Net" رجوع کرد.


همانطور که در شکل فوق نیز ملاحظه می‌کنید، هدر مربوط به مدت زمان منقضی شدن کش سمت کلاینت یک web resource توسط موتور ASP.Net به صورت خودکار به سال 2010 تنظیم شده است و این مقدار خالی نیست.

ب) افزودن این هدر به صورت دستی

برای این منظور باید در نحوه‌ی ارائه فایل‌های استاتیک دخالت کنیم و این‌کار را با استفاده از یک generic handler می‌توان انجام داد.


کد این generic handler می‌تواند به صورت زیر باشد:

using System;
using System.IO;
using System.Web;
using System.Web.Services;
using System.Reflection;

namespace test1
{
   [WebService(Namespace = "http://tempuri.org/")]
   [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
   public class cache : IHttpHandler
   {

       private static void cacheIt(TimeSpan duration)
       {
           HttpCachePolicy cache = HttpContext.Current.Response.Cache;

           FieldInfo maxAgeField = cache.GetType().GetField("_maxAge", BindingFlags.Instance | BindingFlags.NonPublic);
           maxAgeField.SetValue(cache, duration);

           cache.SetCacheability(HttpCacheability.Public);
           cache.SetExpires(DateTime.Now.Add(duration));
           cache.SetMaxAge(duration);
           cache.AppendCacheExtension("must-revalidate, proxy-revalidate");
       }

       public void ProcessRequest(HttpContext context)
       {
           string file = context.Request.QueryString["file"];
           if (string.IsNullOrEmpty(file))
           {
               return;
           }

           string contetType = context.Request.QueryString["contetType"];
           if (string.IsNullOrEmpty(contetType))
           {
               return;
           }
          
           context.Response.Write(File.ReadAllText(context.Server.MapPath(file)));

           //Set the content type
           context.Response.ContentType = contetType;

           // Cache the resource for 30 Days
           cacheIt(TimeSpan.FromDays(30));
       }

       public bool IsReusable
       {
           get
           {
               return false;
           }
       }
   }
}
توضیحات:
این generic handler دو کوئری استرینگ را دریافت می‌کند؛ file جهت دریافت نام فایل و contetType جهت مشخص سازی نوع محتوایی که باید سرو شود؛ مثلا جاوا اسکریپت یا استایل شیت و امثال آن. سپس زمانیکه محتوا را Response.Write می‌کند، هدر مربوط به کش شدن آن‌را نیز به 30 روز تنظیم می‌نماید.
تابع مربوط به کش کردن اطلاعات از مقاله ASP.NET Ajax Under-the-hood Secrets استخراج شد.

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

<link type="text/css" href="cache.ashx?v=1&file=site.css&contetType=text/css" rel="Stylesheet" />
هر زمانیکه که فایل site.css درخواست می‌شود، باید از فیلتر ما عبور کند و سپس ارائه گردد. در این حین، هدر مربوط به مدت زمان کش شدن سمت کلاینت به آن اضافه می‌شود. از کوئری استرینگ مربوط v هم جهت به روز رسانی‌های بعدی استفاده می‌شود تا اگر تغییری را اعمال کردیم، کلاینت حتما با توجه به آدرس جدید، محتویات جدید را یکبار دیگر دریافت کند. (مرورگر آدرس‌های مشابه را در صورتیکه هدر مربوط به کش شدن آن‌ها تنظیم شده باشد، از کش خواهد خواند و کاری به آخرین تغییرات شما در سرور ندارد)

روش استفاده در مورد فایل‌های JS
<script type="text/javascript" src="cache.ashx?v=1&file=js/jquery-1.3.2.min.js&contetType=application/x-javascript"></script>
اکنون اگر سایت را مجددا با افزونه YSlow بررسی کنیم، می‌توان این هدر جدید را مشاهده کرد:



‫۱۵ سال و ۷ ماه قبل، یکشنبه ۶ اردیبهشت ۱۳۸۸، ساعت ۲۳:۵۲
وحید نصیری وحید نصیری
مطالب
توصیه‌هایی در مورد overloading متدها

مطلب زیر چکیده‌ای است از کتاب Framework Design Guidelines در مورد سربارگذاری توابع

الف) از یک نوع خروجی استفاده کنید

مثال زیر را در نظر بگیرید:

public User[] GetGroupMembers(int groupId)
public List<User> GetGroupMembers(string groupName)

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

ب) نام‌های آرگومان‌های توابع سربارگذاری شده شما باید یکسان باشند

در مثال زیر، از اولین آرگومان جهت دریافت شناسه‌ی یک گروه استفاده می‌شود:

public List<User> GetGroupMembers(int groupId)
public List<User> GetGroupMembers(int id, int pageIndex, int pageSize)

اما همانطور که ملاحظه می‌کنید در یکی از groupId استفاده شده و در دیگری از نام id . این روش مزموم است! از آن پرهیز کنید! (هر دو یا باید groupId باشند و یا id . این هماهنگی و یکسان بودن باید در توابع سربارگذاری شده‌ی شما حفظ شود)

ج) ترتیب آرگومان‌ها را در توابع سربارگذاری شده حفظ و رعایت نمائید

لطفا به مثال زیر دقت کنید:

public List<User> GetGroupMembers(int groupId)
public List<User> GetGroupMembers(int pageIndex, int pageSize, int groupId)

در اینجا شناسه‌ی گروه یکبار به عنوان آرگومان اول معرفی شده و بار دیگر به عنوان آرگومان سوم. این کار نیز مزموم است، زیرا برنامه نویس‌ها از روی عادت به اولین آرگومان توابع سربارگذاری شده‌ی شما، همان شناسه‌ی گروه را ارسال خواهند کرد و این مورد سبب بروز باگ‌هایی خواهد شد که ردیابی آن مشکل است. بنابراین اگر شناسه‌ی گروه به عنوان اولین آرگومان معرفی شده، در تمامی overload های این تابع نیز اولین آرگومان باید همان شناسه‌ی گروه باشد.

د) از call forwarding استفاده کنید

جهت توضیح بهتر call forwarding به مثال زیر دقت نمائید:
public List<User> GetGroupMembers(int groupId)
{
   return GetGroupMembers(groupId, 0, 10);
}

public List<User> GetGroupMembers(int groupId, int pageIndex, int pageSize)
{
   return GetGroupMembers(groupId, pageIndex, pageSize, SortOrder.Ascending);
}

public List<User> GetGroupMembers(int groupId, int pageIndex, int pageSize, SortOrder sortOrder)
{
   var query = new GroupQuery();
   query.GroupID = groupId;
   query.PageIndex = pageIndex;
   query.PageSize = pageSize;
   query.SortOrder = sortOrder;

   return GetGroupMembers(query);
}

public List<User> GetGroupMembers(GroupQuery groupQuery)
{
   // Actual implementation to get group members goes here
}

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

ه) زیاده‌ روی نکنید!

آخرین موردی که توصیه شده این است که در تهیه توابع سربارگذاری شده زیاده روی نکنید. در این نوع موارد باید قانون 80/20 را در نظر گرفت. 2 تا 3 تابع سربارگذاری شده ارائه دهید که 80 درصد کار را انجام می‌دهند و سپس یک تابع سربارگذاری شده‌ی دیگر ارائه دهید که 20 درصد باقیمانده را پوشش دهد.


پ.ن.
در سی شارپ 4 ، با معرفی optional parameters ، شاید کمتر به سربارگذاری نیاز باشد.

‫۱۵ سال و ۹ ماه قبل، یکشنبه ۲۷ بهمن ۱۳۸۷، ساعت ۲۱:۰۵
وحید نصیری وحید نصیری
مطالب
غیرمعتبر شدن کوکی‌های برنامه‌های ASP.NET Core هاست شده‌ی در IIS پس از ری‌استارت آن
ASP.NET Core از مکانیزم «Data protection» برای تولید کلیدهای رمزنگاری اطلاعات موقتی خود استفاده می‌کند. این روش در دو حالت هاست برنامه‌ها توسط IIS و یا عدم تنظیمات ذخیره سازی آن‌ها به صورت دائمی، اطلاعات خود را در حافظه نگه‌داری می‌کند و با ری‌استارت شدن سرور و یا IIS، این کلیدها از دست رفته و مجددا تولید می‌شوند. به این ترتیب کاربران شاهد این مشکلات خواهند بود:
الف) چون کوکی‌ها و یا توکن‌های آن‌ها دیگر قابل رمزگشایی نیستند (به علت باز تولید کلیدهای رمزنگاری و رمزگشایی اطلاعات)، مجبور به لاگین مجدد خواهند شد (تا کوکی‌های جدیدی برای آن‌ها تولید شوند). همچنین آنتی‌فورجری توکن‌های آن‌ها نیز مجددا باید تولید شوند.
ب) تمام اطلاعات محافظت شده‌ی توسط Data protection API قابل رمزگشایی نخواهند بود.


تنظیم Data protection API مخصوص برنامه‌های هاست شده‌ی توسط IIS

برای اینکه کلیدهای رمزنگاری اطلاعات برنامه‌های وب به صورت دائمی ذخیره شوند و با ری‌استارت سرور از دست نروند، یکی از سه روش ذیل را می‌توان بکار گرفت:

1) اسکریپت پاور شل ذیل را اجرا کنید:
نحوه‌ی اجرای آن نیز به صورت ذیل است و پس از آن، نام Application pool مخصوص برنامه ذکر می‌شود:
 .\Provision-AutoGenKeys.ps1 DefaultAppPool
در این حالت کلیدهای رمزنگاری اطلاعات به صورت دائمی به رجیستری ویندوز اضافه می‌شوند. این کلیدها به صورت خودکار توسط مکانیزم DPAPI ویندوز، رمزنگاری می‌شوند.

2) به تنظیمات پیشرفته‌ی Application pool برنامه در IIS مراجعه کرده و خاصیت Load user profile آن‌را true کنید.


در این حالت کلیدها به صورت دائمی در پوشه‌ی پروفایل کاربر مخصوص Application pool برنامه، به صورت رمزنگاری شده‌ی توسط مکانیزم DPAPI ویندوز، ذخیره خواهند شد.

3) یک SSL Certificate معتبر را تهیه کنید و یا اگر از یک self signed certificate استفاده می‌کنید باید آن‌‌را در Trusted Root store ویندوز قرار دهید. سپس از روش PersistKeysToFileSystem استفاده کنید.
public void ConfigureServices(IServiceCollection services)
{
   services.AddDataProtection()
    .PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"))
    .ProtectKeysWithCertificate("thumbprint");
}

اگر از یک web farm استفاده می‌کنید، روش سوم ذکر شده، تنها روشی است که از آن می‌توانید استفاده کنید. یک پوشه‌ی اشتراکی قابل دسترسی بین سرورها را ایجاد کنید که دربرگیرنده‌ی X509 certificate شما باشد. سپس این پوشه و مجوز موجود در آن‌را توسط روش فوق به برنامه معرفی کنید.
‫۷ سال و ۲ ماه قبل، سه‌شنبه ۱۰ مرداد ۱۳۹۶، ساعت ۱۵:۱۵
وحید نصیری وحید نصیری
نظرات مطالب
بررسی خطاهای ممکن در حین راه اندازی اولیه برنامه‌های ASP.NET Core در IIS
علت بروز خطای «An assembly specified in the application dependencies manifest (deps.json) was not found» بر روی هاست

پس از ASP.NET Core 2.0 مفهوم متاپکیج «Microsoft.AspNetCore.All» و در 2.1 «Microsoft.AspNetCore.App» معرفی شد. هدف این بسته‌ها کاهش تعداد مداخل بسته‌های تعریف شده‌ی در فایل csproj و همچنین کاهش حجم نهایی برنامه‌ی تهیه شده‌است و محل خوانده شدن آن‌ها نیز از محل نصب بسته‌ی SDK و dotnet\store آن است. بنابراین اگر متاپکیج شما به نگارش 2.0.3 اشاره می‌کند:
 <PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.3" />
 و بر روی هاست SDK مخصوص 2.0.1 نصب است، اجرای برنامه با مشکل مواجه شده و خطای یاد شده را مشاهده خواهید کرد. برای رفع آن باید شماره نگارش متاپکیج استفاده شده، با شماره نگارش SDK نصب شده‌ی بر روی سرور یکی باشد.
‫۶ سال و ۵ ماه قبل، دوشنبه ۲۴ اردیبهشت ۱۳۹۷، ساعت ۱۴:۰۰
وحید نصیری وحید نصیری
نظرات مطالب
پالایش درخواست ها در IIS
میان افزاری برای شبیه سازی قسمتی از این امکانات در برنامه‌های ASP.NET Core

ابتدا بسته‌ی نیوگت DNTCommon.Web.Core را نصب کنید: 
PM> Install-Package DNTCommon.Web.Core
سپس میان افزار AntiDos آن‌را به صورت زیر می‌توانید استفاده و تنظیم کنید:
الف) آن‌را پیش از هر میان‌افزار دیگری ثبت کنید:
public void Configure(IApplicationBuilder app)
{
  app.UseAntiDos();
ب) تنظیمات مخصوص آن‌را به فایل appsettings.json اضافه کنید.
ج) این تنظیمات را به صورت زیر به برنامه معرفی کنید:
public void ConfigureServices(IServiceCollection services)
{
   services.Configure<AntiDosConfig>(options => Configuration.GetSection("AntiDosConfig").Bind(options));
این میان‌افزار هم یک فایروال است که می‌تواند یک رنج‌آی‌پی را ببندد و هم می‌تواند کلاینت‌ها را بر اساس user agent و همچنین هدرهای خاصی فیلتر کند. به علاوه در آن می‌توانید تنظیم کنید که یک کاربر در هر دقیقه چندبار می‌تواند درخواستی را به سمت سایت ارسال کند و پس از آن تا مدتی دسترسی آن به سایت قطع شود. 
‫۶ سال و ۵ ماه قبل، دوشنبه ۱۰ اردیبهشت ۱۳۹۷، ساعت ۱۳:۵۲
وحید نصیری وحید نصیری
نظرات مطالب
طراحی یک ماژول IpBlocker در ASP.NET MVC
معادل این مطلب در برنامه‌های ASP.NET Core

ابتدا بسته‌ی نیوگت DNTCommon.Web.Core را نصب کنید: 
PM> Install-Package DNTCommon.Web.Core
سپس میان افزار AntiDos آن‌را به صورت زیر می‌توانید استفاده و تنظیم کنید:
الف) آن‌را پیش از هر میان‌افزار دیگری ثبت کنید:
public void Configure(IApplicationBuilder app)
{
  app.UseAntiDos();
ب) تنظیمات مخصوص آن‌را به فایل appsettings.json اضافه کنید.
ج) این تنظیمات را به صورت زیر به برنامه معرفی کنید:
public void ConfigureServices(IServiceCollection services)
{
   services.Configure<AntiDosConfig>(options => Configuration.GetSection("AntiDosConfig").Bind(options));
این میان‌افزار هم یک فایروال است که می‌تواند یک رنج‌آی‌پی را ببندد و هم می‌تواند کلاینت‌ها را بر اساس user agent و همچنین هدرهای خاصی فیلتر کند. به علاوه در آن می‌توانید تنظیم کنید که یک کاربر در هر دقیقه چندبار می‌تواند درخواستی را به سمت سایت ارسال کند و پس از آن تا مدتی دسترسی آن به سایت قطع شود. 
‫۶ سال و ۵ ماه قبل، دوشنبه ۱۰ اردیبهشت ۱۳۹۷، ساعت ۱۳:۴۹
وحید نصیری وحید نصیری
نظرات مطالب
مسدود کردن آدرس IP با استفاده از IHttpModule در Asp.Net
معادل این مطلب در برنامه‌های ASP.NET Core

ابتدا بسته‌ی نیوگت DNTCommon.Web.Core را نصب کنید: 
PM> Install-Package DNTCommon.Web.Core
سپس میان افزار AntiDos آن‌را به صورت زیر می‌توانید استفاده و تنظیم کنید:
الف) آن‌را پیش از هر میان‌افزار دیگری ثبت کنید:
public void Configure(IApplicationBuilder app)
{
  app.UseAntiDos();
ب) تنظیمات مخصوص آن‌را به فایل appsettings.json اضافه کنید.
ج) این تنظیمات را به صورت زیر به برنامه معرفی کنید:
public void ConfigureServices(IServiceCollection services)
{
   services.Configure<AntiDosConfig>(options => Configuration.GetSection("AntiDosConfig").Bind(options));
این میان‌افزار هم یک فایروال است که می‌تواند یک رنج‌آی‌پی را ببندد و هم می‌تواند کلاینت‌ها را بر اساس user agent و همچنین هدرهای خاصی فیلتر کند. به علاوه در آن می‌توانید تنظیم کنید که یک کاربر در هر دقیقه چندبار می‌تواند درخواستی را به سمت سایت ارسال کند و پس از آن تا مدتی دسترسی آن به سایت قطع شود.
‫۶ سال و ۵ ماه قبل، دوشنبه ۱۰ اردیبهشت ۱۳۹۷، ساعت ۱۳:۴۷
وحید نصیری وحید نصیری
نظرات مطالب
نحوه‌ی بستن یک بازه‌ی IP در IIS
معادل این مطلب در برنامه‌های ASP.NET Core

ابتدا بسته‌ی نیوگت DNTCommon.Web.Core را نصب کنید: 
PM> Install-Package DNTCommon.Web.Core
سپس میان افزار AntiDos آن‌را به صورت زیر می‌توانید استفاده و تنظیم کنید:
الف) آن‌را پیش از هر میان‌افزار دیگری ثبت کنید:
public void Configure(IApplicationBuilder app)
{
  app.UseAntiDos();
ب) تنظیمات مخصوص آن‌را به فایل appsettings.json اضافه کنید.
ج) این تنظیمات را به صورت زیر به برنامه معرفی کنید:
public void ConfigureServices(IServiceCollection services)
{
   services.Configure<AntiDosConfig>(options => Configuration.GetSection("AntiDosConfig").Bind(options));
این میان‌افزار هم یک فایروال است که می‌تواند یک رنج‌آی‌پی را ببندد و هم می‌تواند کلاینت‌ها را بر اساس user agent و همچنین هدرهای خاصی فیلتر کند. به علاوه در آن می‌توانید تنظیم کنید که یک کاربر در هر دقیقه چندبار می‌تواند درخواستی را به سمت سایت ارسال کند و پس از آن تا مدتی دسترسی آن به سایت قطع شود. 
‫۶ سال و ۵ ماه قبل، دوشنبه ۱۰ اردیبهشت ۱۳۹۷، ساعت ۱۳:۵۱