نظرات مطالب
شروع به کار با AngularJS 2.0 و TypeScript - قسمت یازدهم - کار با فرم‌ها - قسمت دوم
- نگارش فعلی RC5 هست. بهتر است کدهای خودتان را به این نگارش ارتقاء دهید. پروژه‌ی این سری هم به نگارش RC5 ارتقاء داده شد (با این تغییرات)
- خطایی را که ارسال کردید در اینجا مفصل بحث شده‌است. علت اصلی آن هم عدم رعایت مراحل و جزئیات ارتقاء به نگارش‌های جدید است. من در ذیل هر مطلب، تغییرات جهت ارتقاء به نگارش‌های جدیدتر را عنوان کرده‌ام. خلاصه‌ی آن‌ها هم در اینجا است. باید تک تک آن‌ها را بررسی کنید (از تغییرات NgModule تا مسیریابی تا فرم‌ها و غیره که تمام آن‌ها را در ذیل هر مطلب مستند کردم).
- لیستی برای ارتقاء مرحله به مرحله (از نگارش‌های بتا تا نگارش فعلی). توضیحات آن‌ها در ذیل هر مطلب این سری مستند شده‌است.

چند مطلب تکمیلی (خلاصه مواردی را که برای ارتقاء از نگارش‌های beta به RC5 نیاز دارید)
نظرات مطالب
ارتقاء به ASP.NET Core 1.0 - قسمت 13 - معرفی View Components
ExtCore - Free, open source and cross-platform framework for creating modular and extendable web applications based on ASP.NET Core
SimplCommerce - A super simple, cross platform, modularized ecommerce system built on .NET Core
Modular Web Application with ASP.NET Core
Orchard vNext - Orchard 2 is a re-implementation of Orchard CMS in ASP.NET Core
مطالب
لینک‌های هفته دوم دی

وبلاگ‌ها ، سایت‌ها و مقالات ایرانی (داخل و خارج از ایران)


ASP. Net


طراحی و توسعه وب


PHP


اس‌کیوال سرور


سی شارپ


SharePoint

عمومی دات نت


ویندوز


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


متفرقه


نظرات مطالب
آشنایی با Refactoring - قسمت 9
برای اینکه احتمالا ASP.NET Webforms page life cycle رو رعایت نکردید و الان ViewState صفحه چیزی از وجود کنترل‌های پویای شما نمی‌دونه. مثلا می‌تونید از DynamicControlsPlaceholder استفاده کنید. اگر جزئیات بیشتری نیاز داشتید این مطالب مفید هستند:
How To Perpetuate Dynamic Controls Between Page Views in ASP.NET
Dynamic Web Controls, Postbacks, and View State
Creating Dynamic Data Entry User Interfaces
ASP.Net Dynamic Controls (Part 1)
ASP.Net Dynamic Controls (Part 2)
ASP.Net Dynamic Controls (Part 3)
ASP.Net Dynamic Controls (Part 4)
مطالب
سرنوشت اعتبارسنجی درخواست‌ها در 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 و تعدیل تنظیمات آن‌ها بر اساس نیازمندی‌های برنامه‌ی خود
اشتراک‌ها
سری کار با Web API

My road for the series is as follows,

    RESTful Day #1: Enterprise level application architecture with Web APIs using Entity Framework, Generic Repository pattern and Unit of Work.
    RESTful Day #2: Inversion of control using dependency injection in Web APIs using Unity Container and Bootstrapper.
    RESTful Day #3: Resolve dependency of dependencies using Inversion of Control and dependency injection in Asp.net Web APIs with Unity Container and Managed Extensibility Framework (MEF).
    RESTful Day #4: Custom URL Re-Writing/Routing using Attribute Routes in MVC 4 Web APIs.
    RESTful Day #5: Basic Authentication and Token based custom Authorization in Web APIs using Action Filters.
    RESTful Day #6: Request logging and Exception handing/logging in Web APIs using Action Filters, Exception Filters and nLog.
    RESTful Day #7: Unit testing ASP.NET Web APIs controllers using nUnit.
    RESTful Day #8: Extending OData support in ASP.NET Web APIs.

سری کار با Web API
نظرات اشتراک‌ها
معرفی کتابخانه‌ی DNTCaptcha.Core
سلام
میخواستم بدونم روشی هست که این مکانیزم Captcha رو روی یک api بزاریم و این api رو هم توی وب و هم توی اپ موبایل استفاده کنیم؟
نظرات مطالب
Blazor 5x - قسمت 30 - برنامه‌ی Blazor WASM - افزودن پرداخت آنلاین توسط درگاه مجازی پرباد
مشکل حل شد ، ایراد این بود که ارسال به سمت api را با httpclient انجام داده بودم ، باید با  navigationmanager آدرس api را صدا می‌زدم . همانطور که توضیح داده بودید
نظرات مطالب
مستند سازی ASP.NET Core 2x API توسط OpenAPI Swagger - قسمت اول - معرفی
با سلام؛ آیا امکان مستندسازی Api‌ها بصورت جدا وجود داره؟ با فرض اینکه دوتا api داریم و هر دو را داره با هم مستند میکنه. یا اینکه کلا راهی برای تفکیک و نمایش ندادن بعضی از api ‌ها وجود داره؟
نظرات مطالب
ObservableCollection در Entity Framework
- Tracking API فقط داخل یک Context مفهوم پیدا می‌کند نه مجزای آن.
- همچنین این API دارای متد DetectChanges هم هست که می‌شود به صورت دستی جهت اطمینان بیشتر آن‌را در هر زمانی (مثلا داخل بررسی HasChanges) فراخوانی کرد.