نظرات مطالب
YVD
خوب! همین امروز گوگل سیستم نمایشی یوتیوب رو عوض کرده ... و برنامه نگارش یک دهم ما هم از کار افتاد!
نگارش جدید را بر اساس تغییرات جدید گوگل از آدرس زیر دریافت کنید:
http://rapidshare.com/files/370653065/YVD_0.2_setup.exe
نظرات مطالب
آشنایی با NHibernate - قسمت پنجم
در کامنت‌های فوق توضیح دادم. این توضیحات مربوط به نگارش 2 بود. الان نگارش 3 را که دریافت کنید LINQ با آن یکپارچه است و نیازی به دریافت پروایدر کمکی نیست و پروایدر قدیمی هم منسوخ شده و دیگر ادامه نخواهد یافت.
نظرات مطالب
5 دلیل برای استفاده از یک ابزار ORM
نگارش جدید EF (نگارش 4 و یک) یک ماهی هست که منتشر شده. مقایسه‌ای از اون رو با NH می‌تونید اینجا مطالعه کنید:
http://jfromaniello.blogspot.com/2011/03/entityframework-41-rc-code-first-review.html
مطالب
سرنوشت اعتبارسنجی درخواست‌ها در ASP.NET Core
Request Validation یا اعتبارسنجی درخواست‌ها چیست؟


اگر با وب فرم‌ها کار کرده باشید، حتما با تنظیم زیر در فایل web.config برنامه‌های وب آشنا هستید:
<pages validaterequest="false"></pages>
که در آن اعتبارسنجی درخواست رسیده جهت امکان ورود برای مثال اطلاعات HTML ای، به طور کامل خاموش شده‌است (به صورت سراسری در کل برنامه) و یا اگر از MVC 5.x استفاده می‌کنید، ویژگی [ValidateInput(false)] و یا [AllowHtml] نیز یک چنین کاری را انجام می‌دهند.
Request Validation قابلیتی است که از زمان ASP.NET 1.1 وجود داشته‌است و توسط آن اگر اطلاعات دریافتی از کاربر به همراه تگ‌های HTML و یا کدهای JavaScript ای باشد، خطرناک تشخیص داده شده و با ارائه‌ی پیام خطایی (مانند تصویر فوق)، پردازش درخواست متوقف می‌شود. این اعتبارسنجی بر روی هدرها، کوئری استرینگ‌ها، بدنه‌ی درخواست و کوکی‌ها صورت می‌گیرد. هدف آن نیز به حداقل رساندن امکان حملات Cross-Site Scripting و یا XSS است.


محدودیت‌های اعتبارسنجی درخواست‌ها

هر چند Request validation یک ویژگی و امکان جالب است، اما ... در عمل راه‌حل جامعی نیست و تنها اگر کاربر تگ‌های HTML ای را ارسال کند، متوجه وجود یک خطر احتمالی می‌شود. برای مثال اگر این اطلاعات خطرناک به نحو دیگری در قسمت‌های مختلفی مانند attributeها، CSSها و غیره نیز تزریق شوند، عکس العملی را نشان نخواهد داد. به علاوه اگر این نوع حملات به همراه ترکیب آن‌ها با روش‌های Unicode نیز باشد، می‌توان این اعتبارسنجی را دور زد.


اعتبارسنجی خودکار درخواست‌ها و حس کاذب امنیت

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


پایان اعتبارسنجی درخواست‌ها در ASP.NET Core

طراحان ASP.NET Core تصمیم گرفته‌اند که یک چنین قابلیتی را به طور کامل از ASP.NET Core حذف کنند؛ چون به این نتیجه رسیده‌اند که ... ایده‌ی خوبی نبوده و در اکثر مواقع برنامه نویس‌ها کاملا آن‌را خاموش می‌کنند (مانند مثال‌های وب فرم و MVC فوق). اعتبارسنجی درخواست‌ها مشکل یک برنامه است و مراحل و سطوح آن از هر برنامه، به برنامه‌ی دیگری بر اساس نیازمندی‌های آن متفاوت است. به همین جهت تعیین اجباری اعتبارسنجی درخواست‌ها در نگارش‌های قبلی ASP.NET سبب شده‌است که عملا برنامه نویس‌ها با آن کار نکنند. بنابراین در اینجا دیگر خبری از ویژگی‌های ValidateInput و یا AllowHtml و یا مانند وب فرم‌ها و HTTP Module مخصوص آن، به همراه یک میان‌افزار تعیین اعتبار درخواست‌ها نیست.


اکنون برای مقابله با حملات XSS در کدهای سمت سرور برنامه‌های ASP.NET Core چه باید کرد؟

در ASP.NET Core، کار مقابله‌ی با حملات XSS، از فریم‌ورک، به خود برنامه واگذار شده‌است و در اینجا شما بر اساس نیازمندی‌های خود تصمیم خواهید گرفت که تا چه حدی و چه مسایلی را کنترل کنید. برای این منظور در سمت سرور، استفاده‌ی ترکیبی از سه روش زیر توصیه می‌شود:
الف) تمیز کردن اطلاعات ورودی رسیده‌ی از کاربران توسط کتابخانه‌هایی مانند HtmlSanitizer
ب) محدود کردن بازه‌ی اطلاعات قابل قبول ارسالی توسط کاربران
[Required]
[StringLength(50)]
[RegularExpression(@"^[a-zA-Z0-9 -']*$")]
public string Name {get;set;}
در اینجا با مشخص کردن طول رشته، امکان انشاء نوشتن از کاربر گرفته شده‌است و همچنین توسط عبارات باقاعده، تنها ورود حروف و اعداد انگلیسی، به همراه یک فاصله و - مجاز شمرده شده‌اند.
ج) استفاده‌ی اجباری از Content Security Policy Headers و تعدیل تنظیمات آن‌ها بر اساس نیازمندی‌های برنامه‌ی خود
مطالب
خواندنی‌های 2 مرداد

اس کیوال سرور

الگوهای طراحی برنامه نویسی شیءگرا

امنیت

توسعه وب

دات نت فریم ورک

دبلیو اف

سی و مشتقات

کتاب‌های رایگان

لینوکس

متفرقه

محیط‌های مجتمع توسعه

مسایل انسانی، اجتماعی و مدیریتی برنامه نویسی

ویندوز

نظرات مطالب
بررسی فرمت کوکی‌های ASP.NET Identity
سؤال: چرا به روز رسانی اطلاعات کاربر، سبب logout او می‌شود؟
در ASP.NET Identity‌، جدول کاربران دارای فیلد SecurityStamp است و با مقایسه‌ی مقدار آن با مقدار موجود در کوکی کاربر، مشخص می‌کند آیا اطلاعات کاربری در سمت سرور تغییر کرده‌است یا خیر؟ اگر بله، این کاربر مجبور به لاگین مجدد خواهد شد.
 OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, User>(
            validateInterval: TimeSpan.FromMinutes(0),
            regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager))
اینکه چه زمانی بررسی مجدد SecurityStamp موجود در کوکی کاربر صورت می‌گیرد، توسط پارامتر validateInterval مشخص می‌شود. در اینجا این پارامتر به صفر تنظیم شده‌است. یعنی اطلاعات کاربر در درخواست بعدی، مجددا تعیین اعتبار می‌شود.
تغییر اطلاعات فیلد SecurityStamp یا با فراخوانی مستقیم userService.UpdateSecurityStampAsync انجام می‌شود یا متدهای ذیل هم به صورت توکار شامل این فراخوانی در پشت صحنه هستند:
UserManager.CreateAsync
UserManager.RemovePasswordAsync
UserManager.UpdatePassword
UserManager.RemoveLoginAsync
UserManager.ChangePhoneNumberAsync/SetPhoneNumberAsync
UserManager.SetTwoFactorEnabledAsync
UserManager.SetEmailAsync
یعنی هر نوع تغییری در اطلاعات کاربر، سبب logout او خواهد شد.
نظرات مطالب
ASP.NET Web API - قسمت اول
REST بیشتر برای مواقعی هست که شما عملیات CRUD انجام میدید. در حالی که با Web API می‌تونید علاوه بر CRUD، کارهای بسیار بیشتری انجام بدید. مفاهیم و قابلیت‌های موجود در ASP.NET MVC مانند فیلترها به خوبی در Web API پشتیبانی و به راحتی قابل استفاده هستند. ضمن اینکه با Web API می‌تونید معماری REST رو با تغییر کوچکی در route پیش فرض به دست بیارید و بدین شکل، مهاجرت از REST به Web API بسیار راحت هست. در اوایل معرفی Web API، از پروتوکل OData نیز پشتیبانی اولیه میشد که متاسفانه مایکروسافت در نسخه‌ی RC این پشتیبانی رو حذف کرد. شاید در نسخه‌های بعدی این قابلیت نیز اضافه بشه که به قدرتمندتر شدن Web API کمک می‌کنه.
ضمناً، پشتیبانی مایکروسافت از WCF REST API نیز به اتمام رسیده و پیشنهاد شده که از Web API استفاده کنید.
http://aspnet.codeplex.com/wikipage?title=WCF%20REST 
مطالب
‫نکات نصب برنامه‌های ASP.NET 4.0 بر روی IIS 6

سه نکته مهم حین توزیع برنامه‌های ASP.NET 4.0 بر روی IIS 6.0 نسبت به سایر نگارش‌های قبلی وجود دارند که باید در نظر گرفته شوند:

الف) پس از اتقای برنامه از نگارش‌های قبلی به دات نت 4 (با فرض اینکه دات نت 4 بر روی سرور نصب است)، پیغام 404 یا به عبارتی فایل مورد نظر بر روی سرور یافت نشد را دریافت می‌کنید (با تمام فایل‌های موجود):
در کنسول IIS ، ذیل قسمت Web Services Extensions ، باید دو مورد از حالت prohibited خارج شوند:
  • All unknown ISAPI extensions
  • ASP.NET 4.0

ب) پس از اجرای برنامه پیغام غیر معتبر بودن تگ‌های جدید فایل Web.Config را ملاحظه می‌کنید:
- در برگه‌ی خواص سایت در IIS 6.0 ، اکنون امکان انتخاب ASP.NET 4.0 هم میسر است که حتما باید این مورد انتخاب گردد (تا دات نت سه و نیم این نام تنها ASP.NET 2.0 بود). در غیر اینصورت تگ‌های جدید فایل Web.Config شناخته نخواهند شد.

ج) بلافاصله پس از اجرای برنامه، پیغام Server Application Unavailable قابل مشاهده است:
نکته‌ی مهم دیگری که به همراه برنامه‌های دات نت 4 باید به آن توجه داشت، ضرورت اجرای آن‌ها در یک پروسه جدید است. پروسه جدید در IIS 6.0 به معنای یک Application pool جدید است. به عبارتی اگر هم اکنون بر روی IIS 6.0 شما برای مثال 2 برنامه‌ی دات نت سه و دات نت 4 قصد استفاده از یک Application pool را داشته باشند، پیغام Server Application Unavailable ظاهر خواهد شد، زیرا نمی‌توان این دو نگارش را تحت یک پروسه اجرا کرد. برای حل این مشکل باید یک Application pool جدید و اختصاصی را جهت برنامه‌ی ASP.Net 4.0 خود تعریف و انتساب دهید.