پاسخ به بازخورد‌های پروژه‌ها
طراحی ماژولار با MVC و EF

با سلام و خسته نباشین
ما یک پروژه داریم تحت عنوان ModuleCore , که در یک سولوشن جداگانه است(که از نوع MVC Application است) و قصد داریم این Application رو توسعه بدیم که این ماژول کور شامل فرم‌های نصب ماژول, ایجاد صفحات بصورت مجازی و انتخاب بلوک‌ها بعنوان اجزای صفحات مجازی(بلوک‌ها همان اکشن‌ها و کنترلر‌های هر ماژول می‌باشد) است .
ماژول‌های این پروژه, هرکدام در سولوشن‌های جداگانه هستند.حالا در حال ساخت یک ماژول, بعنوان مثال ماژول نظرسنجی هستیم.ما یک سولوشن جداگانه برای این ماژول ایجاد کردیم (PoolModule). ما یک کنترلی با نام PolController ایجاد کرده ایم و یک اکشنی با نام AddPoll جهت افزودن نظرسنجی توسط مدیریت ایجاد کرده ایم.حال ما پروژه PoolModule را بیلد کرده ایم و ما   فایل دی ال ال PolModule و تمام وابستگی هایش و اسمبلی‌های پیش فرض MVC را در اختیار داریم و تمام ویو‌های مربوط به پروژه PolModule  و تمامی اسکریپت‌ها و استایل‌ها و ... را نیز دارا می‌باشد که مجموع اینها را بسته نصبی ماژول نظرسنجی می‌گوییم .
اطلاعات مربوط به نصب این ماژول را در یک فایل xml ثبت کرده ایم. حال جهت نصب این ماژول در اپلیکیشن(ماژول) ModuleCore فایل xml را به فرم نصبی پاس می‌دهیم(فرم نصبی, شامل یک کنترل فایل آپلود می‌باشد که از طریق آن ما تمام اسمبلی‌ها و فایل‌های مربوط به ماژول نظرسنجی را که در یک فایل فشرده قرار داده ایم را آپلود میکنیم). پس از آپلود فایل xml را خوانده و در یک مسیر مشخص(پوشه Modules/ModuleName/Bin  در پروژه ModuleCore ) ذخیره میکنیم. حال می‌خواهیم در RunTime از اسمبلی PoolModule  در پروژه ModuleCore استفاده کنیم .
چگونه باید اسمبلی‌های ماژول نظرسنجی را به ModuleCore بشناسونیم(می خواهیم به کنترلر‌ها و اکشن‌های ماژول نظرسنجی دسترسی داشته باشیم) بطوریکه اسمبلی‌های هر ماژول(مثلا ماژول نظرسنجی) در bin پروژه ModuleCore  نباشد و اسمبلی‌های هر ماژول در پوشه مخصوص خود ( پوشه Modules/ModuleName/Bin در پروژه ModuleCore ) باشد ؟

ممنون میشم راهنمایی کنین یا اگه لینک منابعی رو معرفی کنین. با تشکر 

مطالب
Asp.Net Identity #2
پیشتر در اینجا در مورد تاریخچه‌ی سیستم Identity مطالبی را عنوان کردیم. در این مقاله می‌خواهیم نحوه‌ی برپایی سیستم Identity را بحث کنیم.
ASP.NET Identity مانند ASP.NET Membership به اسکیمای SQL Server وابسته نیست؛ اما Relational Storage همچنان واحد ذخیره سازی پیش فرض و آسانی می‌باشد. بدین جهت که تقریبا بین همه‌ی توسعه دهندگان جا افتاده است. ما در این نوشتار از LocalDB جهت ذخیره سازی جداول استفاده می‌کنیم. ذکر این نکته ضروری است که سیستم Identity از Entity Framework Code First جهت ساخت اسکیما استفاده می‌کند.
پیش از هر چیز، ابتدا یک پروژه‌ی وب را ایجاد کنید؛ مانند شکل زیر:

در مرحله‌ی بعد سه پکیج زیر را باید نصب کنیم :

- Microsoft.AspNet.Identity.EntityFramework

-   Microsoft.AspNet.Identity.OWIN

-  Microsoft.Owin.Host.SystemWeb

بعد از اینکه پکیج‌های بالا را نصب کردیم، باید فایل Web.config را بروز کنیم. اولین مورد، تعریف یک Connection String می‌باشد:
<connectionStrings>
 <add name="IdentityDb" 
      providerName="System.Data.SqlClient"
      connectionString="Data Source=(localdb)\v11.0;Initial Catalog=IdentityDb;Integrated Security=True;Connect Timeout=15;Encrypt=False;TrustServerCertificate=False;MultipleActiveResultSets=True"/>
 </connectionStrings>
بعد از آن، تعریف یک کلید در قسمت AppSettings تحت عنوان Owin:AppStartup است:
<appSettings>
 <add key="webpages:Version" value="3.0.0.0" />
 <add key="webpages:Enabled" value="false" />
 <add key="ClientValidationEnabled" value="true" />
 <add key="UnobtrusiveJavaScriptEnabled" value="true" />
 <add key="owin:AppStartup" value="Users.IdentityConfig" />
 </appSettings>
Owin مدل شروع برنامه (Application Startup Model) خودش را تعریف می‌کند که از کلاس کلی برنامه (منظور Global.asax) جداست. AppSetting تعریف شده با نام owin:Startup شناخته می‌شود و مشخص کننده کلاسی است که Owin وهله سازی خواهد کرد. وقتی برنامه شروع به کار می‌کند، تنظیمات خودش را از این کلاس دریافت خواهد کرد (در این نوشتار کلاس IdentityConfig می‌باشد).

ساخت کلاس User
مرحله‌ی بعد ساخت کلاس User می‌باشد. این کلاس بیانگر یک کاربر می‌باشد. کلاس User باید از کلاس IdentityUser ارث بری کند که این کلاس در فضای نام Microsoft.AspNet.Identity.EntityFramework قرار دارد. کلاس IdentityUser فراهم کننده‌ی یک کاربر عمومی و ابتدایی است. اگر بخواهیم اطلاعات اضافی مربوط به کاربر را ذخیره کنیم باید آنها در کلاسی که از کلاس IdentityUser ارث بری می‌کند قرار دهیم. کلاس ما در اینجا AppUser نام دارد.
using System;
using Microsoft.AspNet.Identity.EntityFramework;
namespace Users.Models 
{
   public class AppUser : IdentityUser 
  {
      // پروپرتی‌های اضافی در اینجا
  }
}

ساخت کلاس Database Context برنامه
مرحله‌ی بعد ساخت کلاس DbContext برنامه می‌باشد که بر روی کلاس AppUser عمل میکند. کلاس Context برنامه که ما در اینجا آن را AppIdentityDbContext تعریف کرده‌ایم، از کلاس <IdentityDbContext<T ارث بری می‌کند که T همان کلاس User می‌باشد (در مثال ما AppUser) .
using System.Data.Entity;
using Microsoft.AspNet.Identity.EntityFramework;
using Users.Models;
namespace Users.Infrastructure {
 public class AppIdentityDbContext : IdentityDbContext<AppUser> 
{
   public AppIdentityDbContext() 
              : base("IdentityDb") { }

  static AppIdentityDbContext() 
 {
    Database.SetInitializer<AppIdentityDbContext>(new IdentityDbInit());
  }
 public static AppIdentityDbContext Create() {
 return new AppIdentityDbContext();
 }
 }
public class IdentityDbInit
 : DropCreateDatabaseIfModelChanges<AppIdentityDbContext> {
 protected override void Seed(AppIdentityDbContext context) {
 PerformInitialSetup(context);
 base.Seed(context);
 }
 public void PerformInitialSetup(AppIdentityDbContext context) {
 // initial configuration will go here
 }
 }
}

ساخت کلاس User Manager
یکی از مهمترین کلاسهای Identity کلاس User Manager (مدیر کاربر) می‌باشد که نمونه‌هایی از کلاس User را مدیریت می‌کند. کلاسی را که تعریف می‌کنیم، باید از کلاس <UserManager<T ارث بری کند که T همان کلاس User می‌باشد. کلاس UserManager خاص EF نمی‌باشد و ویژگی‌های عمومی بیشتری برای ساخت و انجام عملیات بر روی داده‌های کاربر را فراهم می‌نماید.

کلاس UserManager حاوی متدهای بالا است. اگر دقت کنید، می‌بینید که تمامی متدهای بالا به کلمه‌ی Async ختم می‌شوند. زیرا Asp.Net Identity تقریبا کل ویژگیهای برنامه نویسی Async را پیاده سازی کرده است و این بدین معنی است که عملیات میتوانند به صورت غیر همزمان اجرا شده و دیگر فعالیت‌ها را بلوکه نکنند.

using Microsoft.AspNet.Identity;
using Microsoft.AspNet.Identity.EntityFramework;
using Microsoft.AspNet.Identity.Owin;
using Microsoft.Owin;
using Users.Models;

namespace Users.Infrastructure 
{
 public class AppUserManager : UserManager<AppUser> 
{

 public AppUserManager(IUserStore<AppUser> store)
 : base(store) {
 }
 public static AppUserManager Create( IdentityFactoryOptions<AppUserManager> options, IOwinContext context) 
{
 AppIdentityDbContext db = context.Get<AppIdentityDbContext>();
 AppUserManager manager = new AppUserManager(new UserStore<AppUser>(db));
 return manager;
 }
 }
}

زمانی که Identity نیاز به وهله‌ای از کلاس AppUserManager داشته باشد، متد استاتیک Create را صدا خواهد زد. این عمل زمانی اتفاق می‌افتد که عملیاتی بر روی داده‌های کاربر انجام گیرد. برای ساخت وهله‌ای از کلاس AppUserManager نیاز به کلاس <UserStor<AppUser دارد. کلاس <UserStore<T یک پیاده سازی از رابط <IUserStore<T  توسط  EF میباشد که وظیفه‌ی آن فراهم کننده‌ی پیاده سازی Storage-Specific متدهای تعریف شده در کلاس User Manager (که در اینجا AppUserManager ) می‌باشد. برای ساخت <UserStore<T نیاز به وهله‌ای از کلاس AppIdentityDbContext می‌باشد که از طریق Owin به صورت زیر قابل دریافت است:

AppIdentityDbContext db = context.Get<AppIdentityDbContext>();

یک پیاده سازی از رابط IOwinContext، به عنوان پارامتر به متد Create پاس داده می‌شود. در این پیاده سازی، یک تابع جنریک به نام Get تعریف شده که اقدام به برگشت وهله ای از اشیای ثبت شده‌ی در کلاس شروع Owin می‌نماید.


ساخت کلاس شروع Owin

اگر خاطرتان باشد یک کلید در قسمت AppSettings فایل Web.config به صورت زیر تعریف کردیم:

<add key="owin:AppStartup" value="Users.IdentityConfig" />

قسمت Value کلید بالا از دو قسمت تشکیل شده است: Users بیانگر فضای نام برنامه‌ی شماست و IdentityConfig بیانگر کلاس شروع می‌باشد. (البته شما می‌توانید هر نام دلخواهی را برای کلاس شروع بگذارید. فقط دقت داشته باشید که نام کلاس شروع و مقدار، با کلیدی که تعریف می‌کنید یکی باشد)

Owin مستقل از ASP.NET اعلام شده است و قراردادهای خاص خودش را دارد. یکی از این قراردادها تعریف یک کلاس و وهله سازی آن به منظور بارگذاری و پیکربندی میان افزار و انجام دیگر کارهای پیکربندی که نیاز است، می‌باشد. به طور پیش فرض این کلاس Start نام دارد و در پوشه‌ی App_Start تعریف می‌شود. این کلاس حاوی یک متد به نام Configuration می‌باشد که بوسیله زیرساخت Owin فراخوانی می‌شود و یک پیاده سازی از رابط Owin.IAppBuilder به عنوان آرگومان به آن پاس داده می‌شود که کار پشتیبانی از Setup میان افزار مورد نیاز برنامه را برعهده دارد.

using Microsoft.AspNet.Identity;
using Microsoft.Owin;
using Microsoft.Owin.Security.Cookies;
using Owin;
using Users.Infrastructure;
namespace Users 
{
 public class IdentityConfig 
{
 public void Configuration(IAppBuilder app) 
{
 app.CreatePerOwinContext<AppIdentityDbContext>(AppIdentityDbContext.Create);
 app.CreatePerOwinContext<AppUserManager>(AppUserManager.Create);
 app.UseCookieAuthentication(new CookieAuthenticationOptions {
 AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
 LoginPath = new PathString("/Account/Login"),
 });
 }
 }
}

رابط IAppBuilder بوسیله تعدادی متد الحاقی که در کلاسهایی که در فضای نام Owin تعریف شده‌اند، تکمیل شده است. متد CreatePerOwinContext کار ساخت وهله‌ای از کلاس AppUserManager و کلاس AppIdentityDbContext را برای هر درخواست بر عهده دارد. این مورد تضمین می‌کند که هر درخواست، به یک داده‌ی تمیز از Asp.Net Identity دسترسی خواهد داشت و نگران اعمال همزمانی و یا کش ضعیف داده نخواهد بود. متد UseCookieAuthentication به Asp.Net Identity می‌گوید که چگونه از کوکی‌ها برای تصدیق هویت کاربران استفاده کند که Optionهای آن از طریق کلاس CookieAuthenticationOptions مشخص می‌شود. مهمترین قسمت در اینجا پروپرتی LoginPath می‌باشد و مشخص می‌کند که کلاینت‌های تصدیق هویت نشده، هنگام دسترسی به یک منبع محافظت شده، به کدام URL هدایت شوند که توسط یک رشته به متد PathString پاس داده می‌شود.

خوب دوستان برپایی سیستم Identity به پایان رسید. انشالله در قسمت بعدی به چگونگی استفاده‌ی از این سیستم خواهیم پرداخت.

مطالب
بیرون نگاه داشتن پکیج های NuGet از سورس کنترل Git
ابزار NuGet بسیار کار آمد و مفید است. یکی از مشکلات رایج هنگامی پیش می‌آید که پروژه را بهمراه بسته‌های نصب شده به سورس کنترل push می‌کنید. با این کار حجم زیادی از فایل‌ها را به مخزن سورس کنترل آپلود می‌کنید و هنگام clone کردن پروژه توسط هر شخصی، این اطلاعات باید دریافت شوند. بد‌تر از این هنگامی است که برخی از بسته‌ها از سورس حذف می‌شوند و باید به اعضای تیم پروژه اطلاع دهید که چه بسته‌هایی باید دریافت و نصب شوند.

برای رفع این موارد به NuGet Package Restore وارد شوید.


به ویژوال استودیو اجازه دهید بسته‌های NuGet را در صورت لزوم احیا کند
پیش از آنکه بتوانیم از قابلیت Package Restore استفاده کنیم باید آن را روی ماشین خود فعال کنیم. این کار روی هر ماشین باید انجام شود (per-machine requirement). بدین منظور به منوی Tools -> Options -> Package Manager بروید.

در دیالوگ باز شده تنظیمات مربوطه را مانند تصویر زیر بروز رسانی کنید.

حال که ماشین ما برای بازیابی خودکار بسته‌های NuGet پیکربندی شده است، باید این قابلیت را برای Solution مورد نظر هم فعال کنیم.


فعال سازی NuGet Package Restore برای پروژه‌ها

بدین منظور روی Solution کلیک راست کنید و گزینه Enable Package Restore را انتخاب نمایید.

این کار ممکن است چند ثانیه زمان ببرد. پس از آنکه ویژوال استودیو پردازش‌های لازم را انجام داد، می‌توانید ببینید که پوشه جدیدی در مسیر ریشه پروژه ایجاد شده است.

همانطور که می‌بینید فایلی با نام NuGet.exe در این پوشه قرار دارد که باید به سورس کنترل آپلود شود. هنگامیکه شخصی پروژه شما را از سورس کنترل دریافت کند و بخواهد پروژه را Build کند، بسته‌های مورد نیاز توسط این ابزار بصورت خودکار دریافت و نصب خواهند شد.

مرحله بعد حذف کردن تمام بسته‌های NuGet از سورس کنترل است. برای اینکار باید فایل gitignore. را ویرایش کنید. فرض بر این است که سورس کنترل شما Git است، اما قواعد ذکر شده برای دیگر فریم ورک‌ها نیز صادق است. تنها کاری که باید انجام دهید این است که به سورس کنترل خود بگویید چه چیز هایی را در بر گیرد و از چه چیزهایی صرفنظر کند.

ویرایش فایل gitignore. برای حذف بسته‌ها و شامل کردن NuGet.exe

یک پروژه معمولی ASP.NET MVC 5 که توسط قالب استاندارد VS 2013 ایجاد می‌شود شامل 161 فایل از بسته‌های مختلف می‌شود (در زمان تالیف این پست). این مقدار قابل توجهی است که حجم زیادی از اطلاعات غیر ضروری را به مخزن سورس کنترل اضافه می‌کند. با استفاده از نسخه پیش فرض فایل gitignore. (یا فایل‌های مشابه دیگر برای سورس کنترل‌های مختلف مثل TFS) تعداد فایل هایی که در کل به مخزن سورس کنترل ارسال می‌شوند بیش از 200 آیتم خواهد بود. قابل ذکر است که این تعداد فایل شامل فایل‌های اجرایی (binary) و متعلق به ویژوال استودیو نیست. به بیان دیگر نزدیک به 75% از فایل‌های یک پروژه معمولی ASP.NET MVC 5 که توسط VS 2013 ساخته می‌شود را بسته‌های NuGet تشکیل می‌دهد، که حالا می‌توانند بجای ارسال شدن به مخزن سورس کنترل، بصورت خودکار بازیابی و نصب شوند.

برای حذف این فایل‌ها از سورس کنترل، فایل gitignore. را ویرایش می‌کنیم. اگر از سورس کنترل‌های دیگری استفاده میکنید نام این فایل hgignore. یا tfsignore. یا غیره خواهد بود. محتوای فایل شما ممکن است با لیست زیر متفاوت باشد اما جای نگرانی نیست. تنها تغییرات اندکی بوجود خواهیم آورد و مابقی محتویات فایل مهم نیستند.

چشم پوشی از پوشه Packages

فایل gitignore. را باز کنید و برای نادیده گرفتن پوشه بسته‌های NuGet در سورس، خط زیر را به آن اضافه کنید.

packages*/

استثنایی برای در نظر گرفتن NuGet.exe ایجاد کنید
به احتمال زیاد فایل gitignore. شما از فایل هایی با فرمت .exe چشم پوشی می‌کند. برای اینکه بسته‌های NuGet بتوانند بصورت خودکار دریافت شوند باید استثنایی تعریف کنیم. فایل gitignore. خود را باز کنید و به دنبال خط زیر بگردید.
*.exe
سپس خط زیر را بعد از آن اضافه کنید. دقت داشته باشید که ترتیب قرارگیری این دستوارت مهم است.
*.exe
!NuGet.exe
دستورات بالا به Git می‌گوید که فایل‌های .exe را نادیده بگیرد؛ اما برای فایل NuGet.exe استثناء قائل شود.
انجام مرحله بالا انتخابی (optional) است. اگر کسی که پروژه را از مخزن سورس کنترل دریافت می‌کند قابلیت Package Restore را روی Solution فعال کند ابزار NuGet.exe دریافت می‌شود. اما با انجام این مراحل دیگر نیازی به این فعالسازی نخواهد بود، پس در کار اعضای تیم هم صرفه جویی کرده اید.

اطلاع رسانی به اعضای تیم و مشتریان بالقوه
دیگر نیاز نیست بسته‌های NuGet را به مخزن سورس کنترل ارسال کنیم. اما باید به مخاطبین خود اطلاع دهید تا پیکربندی‌های لازم برای استفاده از قابلیت Package Restore را انجام دهند (مثلا در فایل README.txt پروژه).
مطالب
آپلود فایل ها با استفاده از PlUpload در Asp.Net Mvc
امروزه بازار برنامه‌های تماما ajax و بدون Postback  شدن صفحه بسیار داغ میباشد که از این موارد میتوان به برنامه‌های تحت وب گوگل اشاره کرد. (gmail  ، googlePlus  ، Google Reader)
در این میان یکی از دغدغه‌های توسعه دهندگان وب ، آپلود فایل‌ها به صورت آنی (مثل attach files گوگل) میباشد. برای حل این مسئله ، ابزارها و پلاگین‌های متعددی وجود دارد که در اینجا به 10 تا از پلاگین‌های Jquery  اشاره شده است.
به شخصه با پلاگین Uploadify کار کرده ام و از استفاده از آن راضی هستم ولی همین دیشب برای قسمتی از یک پروژه نیاز
به ابزاری جهت آپلود فایل‌ها با امکانات مورد نظرم داشتم که به PlUpload برخورد کردم. 

از امکاناتی که این ابزار در اختیار شما قرار میدهد :
- یک اینترفیس زیبا جهت آپلود و افزودن فایل ها
- پشتیبانی از زبان‌های مختلف و همین طور زبان فارسی
- امکان استفاده از قالب Jquery UI
- Drag&Drop  برای مرورگرهایی که از Html5  پشتیبانی میکنند

حال که با امکانات این ابزار بیشتر آشنا شدید بریم سراغ استفاده از این ابزار در asp.net mvc  :)
ابتدا پروژه را از اینجا دانلود کنید. سپس یک پروژه‌ی جدید  mvc 3  بسازید (از نوع Internet Application و با نام دلخواه). سپس پوشه‌ی plupload  را در قسمت سلوشن برنامه کپی کنید.
حال در فایل Views->Shared->_Layout.cshtml  ، تگ head  را جهت افزودن امکانات پلاگین این گونه تغییر دهید :

    <title>@ViewBag.Title</title>

    <link href="@Url.Content("~/Content/Site.css")" rel="stylesheet" type="text/css" />
    <link href="../../plupload/js/jquery.plupload.queue/css/jquery.plupload.queue.css" rel="stylesheet" />
    <script src="@Url.Content("~/Scripts/jquery-1.7.1.min.js")" type="text/javascript"></script>
    <script type="text/javascript" src="http://bp.yahooapis.com/2.4.21/browserplus-min.js"></script>

    <script src="../../plupload/js/plupload.full.js"></script>
    <script src="../../plupload/js/jquery.plupload.queue/jquery.plupload.queue.js"></script>
    <script src="../../plupload/js/i18n/fa.js"></script>

نکته : فایل fa.js  که جهت استفاده از زبان فارسی در اینترفیس آپلود فایل‌ها میباشد، که وجود آن در آدرس واضح میباشد.
سپس به فایل Views->Home->Index.cshtml بروید و آن را این گونه دوباره نویسی کنید :
 @{
    ViewBag.Title = "Uploading Files using PlUpload";
}
<h2>@ViewBag.Message</h2>

@using (Html.BeginForm("Post", "home", FormMethod.Post,
    new { enctype = "multipart/form-data" }))
{
    <div id="uploader">
        <p>You browser doesn't have Flash, Silverlight, Gears, BrowserPlus or HTML5 support.</p>
    </div>
}

<script>
    $(function () {

        $("#uploader").pluploadQueue({
            // General settings
            runtimes: 'html5,gears,flash,silverlight,browserplus,html4',
            url: '@Url.Action("Upload" , "Home")',
            max_file_size: '10mb',
            chunk_size: '1mb',
            unique_names: true,

            // Resize images on clientside if we can
            resize: { width: 320, height: 240, quality: 90 },

            // Specify what files to browse for
            filters: [
                { title: "Image files", extensions: "jpg,gif,png" },
                { title: "Zip files", extensions: "zip" }
            ],

            // Flash settings
            flash_swf_url: '/plupload/js/plupload.flash.swf',

            // Silverlight settings
            silverlight_xap_url: '/plupload/js/plupload.silverlight.xap'
        });
    });
</script>
توضیحات و نکات :
- جهت آپلود فایل‌ها تگ enctype = "multipart/form-data" را فراموش نکنید.
- در قسمت مقداردهی به ویژگی‌های Plupload  ، قسمت runtime  به صورت ترتیبی کار میکند لذا اگر اولی پشتیبانی نشود سراغ دومی میرود و اگر دومی نشود سومی و ... در صفحه‌ی اول سایت PlUpload ، موارد پشتیبانی شده توسط تکنولوژی‌ها آورده شده است لذا این ترتیب را ترتیب مناسبی میبینم و اگر اولین مورد html5 باشد امکان Drag&Drop وجود خواهد داشت.
خود سایت PlUpload  داکیومنت خیلی خوبی جهت توضیح موارد مختلف دارد لذا توضیح دوباره لازم نیست.
همان طور که در ویژگی url  مشاهده میکنید به کنترلر Home  و اکشن متود Upload اشاره شده است که طرز کار به این گونه است که هر بار که یک فایل آپلود میشود درخواستی به این آدرس و محتوای فایل در قسمت Request.Files ارسال میشود و همین طور نام فایل که unique ارسال میشود و chunk که تیکه‌های فایل است(پست میشود).
پس اکشنی با نام Upload  در کنترلر HomeController بسازید :
        [HttpPost]
        public ActionResult Upload(int? chunk, string name)
        {
            var fileUpload = Request.Files[0];
            var uploadPath = Server.MapPath("~/App_Data");
            chunk = chunk ?? 0;
            using (var fs = new FileStream(Path.Combine(uploadPath, name), chunk == 0 ? FileMode.Create : FileMode.Append))
            {
                if (fileUpload != null)
                {
                    var buffer = new byte[fileUpload.InputStream.Length];
                    fileUpload.InputStream.Read(buffer, 0, buffer.Length);
                    fs.Write(buffer, 0, buffer.Length);
                }
            }
            return Content("chunk uploaded", "text/plain");
        } 
توضیحات : ابتدا فایل مورد نظر از قسمت Request.Files واکشی میشود و سپس فایل را در پوشه App_Data ذخیره میکند. (یکی از چندین روش ذخیره سازی که مطالعه در این قسمت به خواننده واگذار میشود.)

حال برنامه را اجرا کنید و از این ابزار لذت ببرید:) 
نکته : قسمت فارسی ساز اونو تغییر دادم چون که ترجمه‌ی فارسی خودش یه سری نقایصی داشت که گویا از کار با google translate به وجود اومده بود!
مطالب
MIME Sniffing و استاندارد OWASP

 یکی از نکات امنیتی که استاندارد  Owasp  بررسی مینماید هدر X-Content-Type-Options است که جهت جلوگیری از حملات از طریق فایل‌های نامرتبط میباشد. در این رخنه ممکن است فایلی که مرورگر دریافت میکند با آنچه که وب سایت ما آن را میشناسد متفاوت باشد. به عنوان مثال یک فایل اسکریپت که به عنوان یک فایل استایل معرفی میگردد ولی  قابلیت اجرای کدهای آن در مرورگر امکان پذیر است؛ به این نوع حملات MIME Sniffing میگویند. در یکی از سایت‌هایی که در حال حاضر در حال توسعه آن هستیم بخشی از گزارش‌ها با استفاده از ابزار FastReport  ایجاد شده بود و با توجه به اینکه در این ابزار از فایل‌های axd استفاده می‌گردید و مرورگر نوع دیتای برگشتی و MimeType معرفی شده را همخوان نمیدانست، از نمایش و بارگذاری آن ممانعت به عمل آورده و در نتیجه فایل گزارش دیده نمیشد. در این مقاله قصد داریم به معرفی این نوع حمله، روش جلوگیری از آن و همچنین رفع محدودیت پیش آمده را بررسی کرده تا در موارد مشابه از آن استفاده نماییم.


Mime Sniffing

زمانیکه مرورگر در هدر(پاسخ) Response، نوع محتوای ارسال شده، Content-Type را دریافت نکند، یا مرورگر متوجه مغایرتی در آن شود، این نوع رفتار را Mime Sniffing شناسایی میکند. نحوه این شناسایی‌ها در هر مرورگری میتواند متفاوت باشد؛ ولی عموما بر اساس type ارسالی و پسوند مورد نظر میباشد. در بعضی از موارد نیز خواندن بایت‌های ابتدایی یک فایل نیز میتواند نشان دهد که محتوای ارسالی واقعا چیست. به عنوان مثال برای فایل‌هایی با پسوند Gif، الگوی بایت‌های ابتدایی شامل  47 49 46 38 39 میباشد؛ ولی از آنجا که در همه فایل‌ها، بایت‌های ابتدایی الگوی یکسانی ندارند، پس نمی‌توان به این روش نیز بسنده کرد.


روش اینکه به مروگر بگوییم جلوی این نوع حملات را بگیرد و در صورت شناسایی Sniffing از اجرای آن سر باز بزند، استفاده از هدر X-Content-Type-Options میباشد که نحوه افزودن آن در فایل web.config  به شکل زیر است:

 <httpProtocol>
      <customHeaders>
  ...
        <remove name="X-Content-Type-Options"/>
        <add name="X-Content-Type-Options" value="nosniff" />
        ..
      </customHeaders>
    </httpProtocol>

در پروژه ما به دلیل اینکه بخشی از گزارش‌ها با استفاده از FastReport طراحی شده بود این مورد برای ما ایجاد مشکل می‌کرد و در گزارش نمایش داده نمی‌شد و در کنسول پیام‌هایی به شکل زیر دریافت میکردیم:

Refused to execute script from 'https://localhost:44377/WebResource.axd?d=xxx' because its MIME type ('text/js') is not executable, and strict MIME type checking is enabled.

با نگاهی به Response  دریافتی نیز میتوان بازگشت هدر امنیتی X-Content-Type-Options را نیز مشاهده نمود:

 پس باید این هدر را برای بعضی از آدرس‌ها که میتوانند دچار مشکلات اجرایی گردند حذف کرده و برای مابقی بخش‌ها همچنان این هدر فعال باشد؛ پس با افزودن کد زیر به web.config، هدر مورد نظر را برای این نوع فایل حذف میکنیم:

  <location path="WebResource.axd" >
    <system.webServer>
      <httpProtocol>
        <customHeaders>
          <remove name="X-Content-Type-Options" />
        </customHeaders>
      </httpProtocol>
    </system.webServer>
  </location>

 نتیجه آن را میتوانید در صفحه ذیل برای همان درخواست و پاسخ قبلی نیز مشاهده نمایید:

 
مطالب
آموزش WAF (مشاهده تغییرات خواص ViewModel در Controller)
قصد داریم در مثال پست قبلی برای Command مورد نظر، عملیات اعتبارسنجی را فعال کنیم. اگر با الگوی MVVM آشنایی داشته باشید می‌دانید که می‌توان برای Command‌ها اکشنی به عنوان CanExecute تعریف کرد و در آن عملیات اعتبارسنجی را انجام داد. اما از آن جا که پیاده سازی این روش زمانی مسیر است که تغییرات خواص ViewModel در دسترس باشد در نتیجه در WAF مکانیزمی جهت ردیابی تغییرات خواص ViewModel در کنترلر فراهم شده است. در نسخه‌های قبلی WAF (قبل از نسخه 3) هر کنترلر از کلاس پایه ای به نام Controller ارث می‌برد که متد هایی جهت ردیابی تغییرات در آن در نظر گرفته شده بود به صورت زیر:
public class MyController : Controller
    {
        [ImportingConstructor]
        public MyController(MyViewModel viewModel)
        {
            ViewModelCore = viewModel;
        }

        public MyViewModel ViewModelCore 
        {
            get; 
            private set; 
        }

        public void Run()
        {
            AddWeakEventListener(ViewModelCore , ViewModelCoreChanged)
        }

        private void ViewModelCoreChanged(object sender , PropertyChangedEventArgs e)
        {
            if(e.PropertyName=="CurrentItem")
            {
                
            }
        }
    }
همان طور که مشاهده می‌کنید با استفاده از متد AddWeakEventListener توانستیم تمامی تغییرات خواص ViewModel مورد نظر را از طریق متد ViewModelCoreChanged ردیابی کنیم. این متد بر مبنای الگوی WeakEvent پیاده سازی شده است. البته این تغییرات فقط زمانی قابل ردیابی هستند که  در ViewModel متد RaisePropertyChanged برای متد set خاصیت فراخوانی شده باشد.
از آنجا که در دات نت 4.5 یک پیاده سازی خاص از الگوی WeakEvent در کلاس PropertyChangedEventManager موجود در اسمبلی WindowsBase و فضای نام System.ComponentModel انجام شده است در نتیجه توسعه دهندگان این کتابخانه نیز تصمیم به استفاده از این روش گرفتند که نتیجه آن  Obsolete شدن کلاس پایه کنترلر در نسخه‌های 3 به بعد آن است. در روش جدید کافیست به صورت زیر عمل نمایید:
 [Export]
    public class BookController
    {
        [ImportingConstructor]
        public BookController(BookViewModel viewModel)
        {
            ViewModelCore = viewModel;
        }
        
        public BookViewModel ViewModelCore
        {
            get;
            private set;
        }

        public DelegateCommand RemoveItemCommand 
        { 
            get; 
            private set;
        }

        private void ExecuteRemoveItemCommand()
        {
            ViewModelCore.Books.Remove(ViewModelCore.CurrentItem);
        }

        private bool CanExecuteRemoveItemCommand()
        {
            return ViewModelCore.CurrentItem != null;
        }
        private void Initialize()
        {
            RemoveItemCommand = new DelegateCommand(ExecuteRemoveItemCommand , CanExecuteRemoveItemCommand);
            ViewModelCore.RemoveItemCommand = RemoveItemCommand;
        }

        public void Run()
        {
            var result = new List<Book>();
            result.Add(new Book { Code = 1, Title = "Book1" });
            result.Add(new Book { Code = 2, Title = "Book2" });
            result.Add(new Book { Code = 3, Title = "Book3" });

            Initialize();
            ViewModelCore.Books = new ObservableCollection<Models.Book>(result);

            PropertyChangedEventManager.AddHandler(ViewModelCore, ViewModelChanged, "CurrentItem");
            
            (ViewModelCore.View as IBookView).Show();
        }

        private void ViewModelChanged(object sender,PropertyChangedEventArgs e)
        {
            if(e.PropertyName == "CurrentItem")
            {
                RemoveItemCommand.RaiseCanExecuteChanged();
            }
        }
    }
تغییرات:
»ابتدا متدی به نام CanExecuteRemoveItemCommand ایجاد کردیم و کد‌های اعتبارسنجی را در آن قرار دادیم؛
»هنگام تعریف Command مربوطه متد بالا را به DelegateCommand رجیستر کردیم:
  RemoveItemCommand = new DelegateCommand(ExecuteRemoveItemCommand , CanExecuteRemoveItemCommand);
در این حالت بعد از اجرای برنامه همواره دکمه RemoveItem غیر فعال خواهد بود. دلیل آن این است که بعد از انتخاب آیتم مورد نظر از لیست باید کنترلر را متوجه تغییر در مقدار خاصیت CurrentItem نماییم. بدین منظور کد زیر را به متد Run اضافه کردم:
     PropertyChangedEventManager.AddHandler(ViewModelCore, ViewModelChanged, "CurrentItem");
دستور بالا دقیقا معادل دستور AddWeakEventListener موجود در نسخه‌های قدیمی WAF است. سپس در صورتی که نام خاصیت مورد نظر CurrentItem بود با استفاده از دستور RaiseCanExecuteChanged در کلاس DelegateCommand کنترلر را ملزم به اجرای دوباره متد CanExecuteRemoveItemCommand می‌کنیم.
اجرای برنامه:
ابتدا دکمه RemoveItem غیر فعال است:

بعد از انتخاب یکی از گزینه و فراخوانی مجدد متد CanExecuteRemoveItemCommand دکمه مورد نظر فعال می‌شود:

و در نهایت دکمه RemoveItem فعال خواهد شد:


دانلود سورس پروژه
اشتراک‌ها
معرفی فریمورک متن باز رابط کاربری HandyControl برای WPF

یک سالی میشود که روی یک فریمورک رابط کاربری بصورت متن باز به اسم HandyControl مشارکت دارم، این فریمورک در درجه اول مخصوص برنامه نویس‌های چین طراحی شده بود اما با بازخوردهایی که دریافت کرد، جامعه انگلیسی زبان را هم پشتیبانی میکند. بدلیل اینکه هدف این فریمورک ارائه کنترل‌های ساده و بدور از پیچیدگی هست، Nabian با اضافه کردن کنترل‌های پیچیده مخالف هست. به همین دلیل تصمیم گرفتم تا شاخه جدایی از این پروژه را ایجاد کنم و کنترل‌ها و ویژگی‌های مختلفی که سازگار با برنامه نویس‌های ایرانی باشد را اضافه کنم. درحال حاضر تقویم شمسی، ساعت_تقویم شمسی، پشتیبانی از کد ملی، حروف فارسی در نوع ورودی TextBox ،استایل‌های جدید بارگذاری، کنترل BusyIndicator، کنترل سرعت شمار (SpeedoMeter) و چندین کلاس هلپر جهت کار با رجیستری، رمزنگاری و... را به پروژه اضافه کردم.(لیست ویژگی‌های اضافه شده را میتوانید از این قسمت مشاهده کنید) (جهت مشاهده کنترل‌ها و ویژگی‌های اضافه شده در نسخه شخصی سازی شده بعد از اجرای دمو از بخش Controls بخش PersianToolkit را انتخاب کنید)

صفحات پروژه اصلی===> سورس برنامه | صفحه ناگت | صفحه مارکت پلیس مستندات چینی | مستندات انگلیسی | مستندات ویکی

 اگر پیشنهادی برای اضافه کردن کدهای کاربردی یا کنترل‌های کاربردی دارید لطفا در نظرات اعلام کنید و یا اگر خودتان توانایی آن را دارید در گیتهاب PR ارسال کنید.
 

معرفی فریمورک متن باز رابط کاربری HandyControl برای WPF
نظرات مطالب
استفاده از مسیرهای مطلق در حین import ماژول‌ها در برنامه‌های مبتنی بر TypeScript
خیلی ممنون فکر میکنم حق با شما بود مسیر‌ها رو تغییر دادم و چندین حالت رو امتحان کردم بالاخره کامپایل شد.
ضمن اینکه اینجا یک سری موارد رو میگم شاید بدرد بقیه دوستان هم بخوره اگه به این مشکلات بر خوردن.

اگر پروژه شما به جز فایل tsconfig.json اصلی که در ریشه پروژه هست، دارای فایل‌های tsconfig.app.json و tsconfig.spec.json هم هست، باید مسیرها رو به این صورت تنظیم کنید:
مقدار baseUrl در فایل tsconfig.json برابر با src
مقدار baseUrl در فایل‌های tsconfig.app.json و tsconfig.spec.json برابر با : /.

مورد دیگه ای که بهش برخوردم خطای circular dependency بود که مربوط به ارجاع دادن مسیرهای مطلق به همدیگر هست.
اگر در پروژه از فایل‌های index.ts جهت کوتاه کردن آدرس‌ها استفاده میکنید، نباید در داخل خود فایل هایی که در index.ts معرفی شدند، از مسیر مطلق استفاده کنید.
برای مثال:
شما یک پوشه به اسم common دارید که داخل آن یک پوشه دیگر به اسم utilities که برای مثال کلاسی به اسم DateTime را در آن تعریف کردید. و حال شما میخواهید کلاس DateTime را با آدرس مطلق app/common@ در سراسر پروژه استفاده کنید.
به همین دلیل شما در داخل پوشه common فایل index.ts رو ایجاد میکنید و دستور زیر را قرار میدید:
 export * from './utilities/DateTime'
حال، اگر در هر یک از فایل هایی که داخل پوشه common که فایل index.ts را قبلا در آن تعریف کردیم، بخواهید از DateTime استفاده کنید، اگر آن را با مسیر مطلق مانند:
 import { DateTime } from '@app/common'
 استفاده کنید به خطای circular dependency بر میخورید.
به همین خاطر باید از مسیر نسبی استفاده کنید مانند:
 import { DateTime } from './utilities/DateTime'
ولی در خارج از پوشه common میتوانید از مسیر مطلق استفاده کنید.
امیدوارم تونسته باشم منظور رو برسونم.
مطالب
جلوگیری از Brute Force Attack
یکی از حملات رایج که توسعه دهندگان با آن روبرو هستند، Brute-Force Attack میباشد. در این حملات برای کشف رمزعبور کاربران، هر ترکیب احتمالی از حروف، اعداد و نمادها را استفاده میکنند تا یک ترکیب صحیح را بدست آورند. اگر وب سایت شما نیاز به احراز هویت دارد، شما یک هدف مناسب برای حملات Brute-Force هستید! یک هکر میتواند رمزعبور را از این طریق بدست آورد؛ اما یافتن آن شاید سالها طول بکشد که بستگی به طول رمز و پیچیدگی آن، ممکن است چندین سال طول بکشد. اما یک حمله Brute-Force میتواند سریع‌تر انجام شود، میتواند از فرهنگ لغت استفاده کند و یا کلمات فرهنگ لغت را کمی تغییر دهد، زیرا بیشتر افراد بجای یک کلمه‌ی عبور تصادفی و پیچیده، از آن کلمات استفاده میکنند. به این حملات dictionary attacks یا hybrid brute-force attacks نیز گفته میشود. این حملات حساب‌های کاربران را در معرض خطر قرار میدهد و باعث افزایش ترافیک غیرضروری سایت شما میشود.

هکرها از ابزارهای گسترده‌ای که لیست کلمات و قواعد هوشمندانه‌ای را دارند استفاده میکنند تا به طور هوشمندانه و به طور خودکار، کلمه‌های عبور کاربران را حدس بزنند. اگرچه شناسایی چنین حملاتی آسان است، اما جلوگیری از آن کار آسانی نیست. به طور مثال برخی از ابزارهای HTTP brute-force میتوانند درخواست‌ها را از طریق پروکسی‌های باز سرور انجام دهند و از آنجا که هر درخواست از یک IP متفاوت میرسد، نمیتوانید با مسدود کردن IP، حملات را مسدود کنید. حتی برخی از ابزارها برای هر بار درخواست، یک نام کاربری و یک کلمه عبور را امتحان میکنند و شما نمیتوانید هر حساب کاربری را برای یک بار عملیات ناموفق مسدود کنید.


مسدود کردن حساب‌ها

بدیهی‌ترین راه برای جلوگیری از این حملات، مسدود کردن حساب‌ها پس از تعداد مشخصی تلاش ناموفق است. مسدود شدن حساب‌ها میتواند مدت زمان خاصی داشته باشد و یا اینکه حساب‌ها باید توسط ادمین سایت فعال شوند. با این وجود، مسدود کردن حساب‌ها همیشه بهترین راه برای جلوگیری از این حملات نیست؛ زیرا شخصی میتواند به راحتی از قوانین سوء استفاده کرده و تعداد زیادی از حساب‌ها را مسدود کند. برخی از مشکلات مربوط به این راه عبارت اند از:
  • یک مهاجم میتواند تعداد زیادی از حساب‌ها را مسدود کند.
  • به دلیل اینکه شما نمیتوانید حسابی را که وجود ندارد، مسدود کنید و فقط حساب‌های معتبر قفل میشوند، یک مهاجم با استفاده از پاسخ خطای مربوط به مسدود شدن حساب کاربری میتواند از اینکار برای برداشتن نام کاربری استفاده کند.
  • یک مهاجم میتواند با مسدود کردن تعداد زیادی از حساب‌ها و جاری شدن تماس‌های پشتیبانی برای بازیابی حساب، باعث انحراف آنها شود.
  • یک مهاجم میتواند به طور مداوم یک حساب کاربری را مسدود کند، حتی چند ثانیه بعد از آنکه ادمین سایت آن حساب را فعال کند، مجددا به مسدود کردن آن اقدام کند.
  • مسدود کردن حساب‌ها برای حملاتی که کند هستند و هر ساعت فقط چند رمز عبور را امتحان میکنند، بی تاثیر است.
  • مسدود کردن حساب‌ها در برابر حملاتی که یک رمز عبور را در برابر لیستی از نام کاربری امتحان میکنند، بی تاثیر است
  • مسدود کردن حساب‌ها در برابر حملاتی که از لیستی از کلمه عبور/نام کاربری استفاده میکنند و در اولین بار به طور صحیح حدس میزنند بی تاثیر است.

مسدود کردن حساب‌ها  گاهی اوقات تاثیرگذار است؛ اما در محیط‌های کنترل شده. با این حال در بیشتر موارد مسدود کردن حساب‌ها برای متوقف کردن حملات brute-force کافی نیست. به عنوان مثال یک سایت حراجی را در نظر بگیرید که چندین داوطلب برای یک کالا در حال مسابقه هستند. اگر وبسایت حراجی حساب‌ها را مسدود کند، یک پیشنهاد دهنده میتواند در لحظات آخر نسبت به مسدود کردن حساب‌های دیگران اقدام کند و مانع از ارائه هرگونه پیشنهادی شود و خود برنده شود. یک مهاجم میتواند از همین تکنیک برای مسدود کردن معاملات حساس مالی و ... اقدام کند.


اقدامات متقابل

همانطور که توضیخ داده شد، مسدود کردن حساب‌ها یک راه کامل برای مقابله با این حملات نیست. اما ترفندهای دیگری نیز برای مقابله با این حملات وجود دارند. از آنجا که موفقیت این حملات به زمان بستگی دارد، یک راه حل آسان، تزریق مکث‌های تصادفی هنگام چک کردن رمز عبور است. افزودن مکث حتی چند ثانیه‌ای میتواند یک حمله را بسیار کند نماید؛ اما بیشتر کاربران را هنگام ورود به سایت، ناراحت نمیکند. توجه داشته باشید اگرچه اضافه کردن تاخیر میتواند یک حمله single-thread را کند، کند اما اگر مهاجم چندین درخواست را همزمان ارسال کند، کمتر موثر است.

راه حل دیگر مسدود کردن یک IP با چند عملیات ناموفق است. اما مشکل این راه حل آن است که شما سهوا گروه‌هایی از کاربران را بلاک میکنید؛ مانند بلاک کردن یک پراکسی سرور که توسط یک ISP استفاده میشود. مشکل دیگر این راه حل استفاده‌ی بسیاری از ابزارها از لیستی از پراکسی‌ها است و با هر IP، دو یا سه درخواست را ارسال میکنند و سپس به دنبال بعدی می‌روند. یک مهاجم میتواند به این طریق به راحتی فرآیند مسدود کردن IP را دور بزند. بیشتر سایت‌ها حساب‌ها را بعد از یک عملیات ناموفق، مسدود نخواهند کرد؛ به همین دلیل یک مهاجم میتواند از هر پراکسی، دو یا سه درخواست را امتحان کند. یک هکر با داشتن لیستی از 1000 پراکسی میتواند 2000 یا 3000  کلمه عبور را امتحان کند؛ بدون مسدود شدن حساب‌ها.

 یک راه حل ساده در عین حال موثر آن است که رفتار وب سایت خود را برای پاسخ به عملیات ناموفق ورود به سایت، درست طراحی نکنید. برای مثال اکثر وب سایت‌ها کد "HTTP 401 error" را برای کلمه عبور اشتباه میفرستند. اگرچه بعضی وب سایت‌ها کد "HTTP 200 SUCCESS" را برمیگردانند، اما کاربر را به صفحه‌ای هدایت میکند و توضیح میدهد که رمز عبور را اشتباه وارد کرده است، این کار برخی سیستم‌ها را فریب می‌دهد اما دور زدن آن نیز راحت است. یک راه حل بهتر آن است که هر بار از پیام‌های خطای مختلفی استفاده کنید و یا گاهی به کاربر اجازه رفتن به یک صفحه را بدهید و دوباره کاربر را وادار به وارد کردن رمز عبور نمایید.

بعضی از ابزارها این امکان را دارند تا مهاجم یک رشته را وارد کند تا به دنبال آن باشند که نشان میدهد عملیات ورود ناموفق بوده است. به عنوان مثال اگر صفحه‌ای شامل عبارت "Bad username or password" باشد، به معنای آن است که عملیات ناموفق بوده است و نام کاربری و یا کلمه‌ی عبور بعدی را امتحان میکند. یک راه ساده برای مقابله با این راه این است که از عبارت‌هایی استفاده کنیم که در هنگام ورود موفق استفاده میشوند.

بعد از دو یا چند تلاش ناموفق، کاربر را وادار به پاسخ دادن به یک سؤال مخفی کنید. این کار نه تنها باعث اختلال در حملات خودکار میشود بلکه از دسترسی فرد مهاجم جلوگیری میکند؛ حتی اگر نام کاربری و رمز عبور را درست وارد کرده باشد.

سایر تکنیک هایی که میتوانید در نظر بگیرید عبارتند از:
  • برای کاربران مهم که میخواهند از حساب خود در مقابل این نوع حملات جلوگیری کنند، به آنها این امکان را  بدهید که بتوانند فقط از IP خاصی وارد سیستم شوند.
  • برای جلوگیری از حملات خودکار، از captcha استفاده کنید.
  • بجای قفل کردن حساب کاربری، آنرا در حالت قفل با دسترسی محدود قرار دهید.

هکرها اغلب میتوانند بسیاری از تکنیک‌ها را به تنهایی دور بزنند. اما با ترکیب چندین حالت میتوانید این حملات را به میزان قابل توجهی کاهش دهید. اگرچه جلوگیری کامل از این حملات سخت است، اما تشخیص آن آسان است؛ زیرا با هربار ورود ناموفق، یک رکورد با کد HTTP 401 در لاگ‌های سرور ثبت میشود. این مهم است که لاگ‌های سرور خود را برای این نوع حملات نظارت کنید در شرایط خاص. کد 200 به آن معناست که مهاجم یک رمز عبور معتبر را پیدا کرده است.

شرایطی که میتوانند حملات brute-force یا سوء استفاده از یک حساب را نشان دهند:
  • تعداد زیادی ورود ناموفق از یک IP
  • تلاش برای ورود به سایت با چند نام کاربری از طرف یک IP
  • تلاش برای ورود به یک حساب کاربری از طرف چندین IP
  • تلاش برای ورود، با وارد کردن نام کاربری و کلمه‌ی عبور، به ترتیب حروف الفبا
  • تلاش برای ورود، با نام کاربری یا کلمات عبوری مانند ownsyou,washere,zealots ,hacksyou یا مشابه آنها که هکرها معمولا از آنها استفاده میکنند

متوقف کردن این حملات دشوار است؛ اما با طراحی دقیق و اقدامات متقابل متعدد، می‌توانید میزان قرار گرفتن در معرض این حملات را محدود کنید. درنهایت، بهترین راه جلوگیری این است که کاربران از قوانین اصلی رمزهای عبور قوی استفاده کنند؛ برای مثال از رمزهای عبور طولانی غیرقابل پیش بینی، اجتناب از کلمات فرهنگ لغت، جلوگیری از استفاده مجدد از گذرواژه‌ها و تغییر گذرواژه‌ها به طور منظم.   
مطالب
ساختار پروژه های Angular
با توجه به پست‌ها منتشر شده قبلی درباره AngularJs به احتمال قوی شما نیز به این نتیجه رسیده اید که این فریم ورک برای انواع پروژه‌ها به ویژه پروژه هایی با مقیاس بزرگ بسیار مناسب است. منظور از ساختار پروژه Angular این است که به چه سبکی فایل‌های پروژه را سازمان دهی کنیم طوری که در هنگام توسعه و تغییرات با مشکل مواجه نشویم. عموما کد‌های مربوط به بخش frontend پروژه دارای ساختار قوی نمی‌باشند در نتیجه developer‌ها بیشتر سلیقه ای کد‌های مربوطه را می‌نویسند که با گذر زمان این مورد باعث بروز مشکل در امر توسعه نرم افزار می‌شود (نمونه بارز آن کدهای نوشته شده Jquery در صفحات است). AngularJs نیز همانند سایر کتابخانه‌ها و فریم ورک‌های جاوااسکریپتی دیگر از این امر مستثنی نیست و فایل‌های آن باید طبق روشی مناسب پیاده سازی و مدیریت شوند. انتخاب ساختار و روش سازمان دهی فایل‌ها وابستگی مستقیم به مقیاس پروژه دارد. ساختار پروژه‌های کوچک می‌تواند کاملا متفاوت با ساختار پروژه‌های بزرگ باشد. در این پست به بررسی چند روش در این زمینه خواهم پرداخت.
پروژه‌های کوچک عموما دارای ساختاری مشابه تصویر ذیل می‌باشند:

این مورد، روش پیشنهادی در Angular Seed است و بدین صورت است که تعاریف ماژول‌ها در فایل app.js انجام می‌گیرد. تعاریف و پیاده سازی تمام کنترلر‌ها در فایل controller.js است. و همچنین دایرکتیوها و فیلترها و سرویس‌ها هر کدام در فایل‌ها جداگانه تعریف و پیاده سازی می‌شوند. این روش راه حلی سریع برای پروژه‌های کوچک با تعداد developer‌های کم است. برای مثال زمانی که یک developer در حال ویرایش فایل controller.js است، از آن جا که فایل مورد نظر checkout خواهد شد در نتیجه سایر developer‌ها امکان تغییر در فایل مورد نظر را نخواهند داشت. سورس فایل‌ها به مرور زیاد خواهد شد و در نتیجه debug آن سخت می‌شود. 

روش دوم

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

دایرکتیو‌ها و فیلتر‌ها عموما در یک فایل قرار داده خواهند شد تا بنابر نیاز در جای مناسب رفرنس داده شوند. این روش ساختار مناسب‌تری نسبه به روش قبلی دارد اما دارای معایبی هم چون موارد زیر است:
»وابستگی بین فایل‌ها مشخص نیست در نتیجه بدون استفاده از کتابخانه هایی نظیر requireJs  با مشکل مواجه خواهید شد.
»refactoring کد‌ها تا حدودی سخت است.

روش سوم
این ساختار مناسب برای پیاده سازی پروژه‌ها به صورت ماژولار است و برای پروژه‌های بزرگ نیز بسیار مناسب است. در این حالت شما فایل‌های مربوط به هر ماژول را در دایرکتوری خاص آن قرار خواهید داد. به صورت زیر:

همان طور که ملاحظه می‌کنید سرویس ها، کنترلر‌ها و حتی مدل‌های مربوط به هر بخش در یک مسیر جداگانه قرار می‌گیرند. علاوه بر آن فایل هایی که قابلیت اشتراکی دارند در مسیری به نام common وجود دارند تا بتوان در جای مناسب برای استفاده از آن‌ها رفرنس داده شود. حتی اگر در پروژه خود فقط یک ماژول دارید باز سعی کنید از این روش برای مدیریت فایل‌های خود استفاده نمایید. اگر با ngStart آشنایی داشته باشید به احتمال زیاد با این روش بیگانه نیستید.
بررسی چند نکته درباره کد‌های مشترک
در اکثر پروژه‌های بزرگ، فایل‌ها و کد هایی وجود خواهد داشت که حالت اشتراکی بین ماژول‌ها دارند. در این روش این فایل‌ها در مسیری به نام common یا shared ذخیره می‌شوند. علاوه بر آن در Angular تکنیک هایی برای به اشتراک گذاشتن این اطلاعات وجود دارد.
»اگر ماژول‌ها وابستگی شدیدی به فایل‌ها و سورس‌های مشترک دارند باید اطمینان حاصل نمایید که این ماژولها فقط به اطلاعات مورد نیاز دسترسی دارند. این اصل interface segregation principle اصول SOLID است.
»توابعی که کاربرد زیادی دارند و اصطلاحا به عنوان Utility شناخته می‌شوند باید به rootScope$ اضافه شوند تا scope‌های وابسته نیز به آن‌ها دسترسی داشته باشند. این مورد به ویژه باعث کاهش تکرار وابستگی‌های مربوط به هر کنترلر می‌شود.
»برای جداسازی وابستگی‌های بین دو component بهتر از event‌ها استفاده نمایید. AngularJs این امکان را با استفاده از سرویس‌های on$ و emit$ و broadcast$ به راحتی میسر کرده است.