سورس نگارش کامل دات نت
The referencesource repository contains sources from Microsoft .NET Reference Source that represent a subset of the .NET Framework. This subset contains similar functionality to the class libraries that are being developed in .NET Core. We intend to consult the referencesource repository as we develop .NET Core. It is also for the community to leverage to enable more scenarios for .NET developers.
معرفی JSON Web Token
دو روش کلی و پرکاربرد اعتبارسنجی سمت سرور، برای برنامههای سمت کاربر وب وجود دارند:
الف) Cookie-Based Authentication که پرکاربردترین روش بوده و در این حالت به ازای هر درخواست، یک کوکی جهت اعتبارسنجی کاربر به سمت سرور ارسال میشود (و برعکس).
ب) Token-Based Authentication که بر مبنای ارسال یک توکن امضاء شده به سرور، به ازای هر درخواست است.
مزیتهای استفادهی از روش مبتنی بر توکن چیست؟
• Cross-domain / CORS: کوکیها و CORS آنچنان با هم سازگاری ندارند؛ چون صدور یک کوکی وابستهاست به دومین مرتبط به آن و استفادهی از آن در سایر دومینها عموما پذیرفته شده نیست. اما روش مبتنی بر توکن، وابستگی به دومین صدور آنرا ندارد و اصالت آن بر اساس روشهای رمزنگاری تصدیق میشود.
• بدون حالت بودن و مقیاس پذیری سمت سرور: در حین کار با توکنها، نیازی به ذخیرهی اطلاعات، داخل سشن سمت سرور نیست و توکن موجودیتی است خود شمول (self-contained). به این معنا که حاوی تمام اطلاعات مرتبط با کاربر بوده و محل ذخیرهی آن در local storage و یا کوکی سمت کاربر میباشد.
• توزیع برنامه با CDN: حین استفاده از روش مبتنی بر توکن، امکان توزیع تمام فایلهای برنامه (جاوا اسکریپت، تصاویر و غیره) توسط CDN وجود دارد و در این حالت کدهای سمت سرور، تنها یک API ساده خواهد بود.
• عدم در هم تنیدگی کدهای سمت سرور و کلاینت: در حالت استفادهی از توکن، این توکن میتواند از هرجایی و هر برنامهای صادر شود و در این حالت نیازی نیست تا وابستگی ویژهای بین کدهای سمت کلاینت و سرور وجود داشته باشد.
• سازگاری بهتر با سیستمهای موبایل: در حین توسعهی برنامههای بومی پلتفرمهای مختلف موبایل، کوکیها روش مطلوبی جهت کار با APIهای سمت سرور نیستند. تطابق یافتن با روشهای مبتنی بر توکن در این حالت سادهتر است.
• CSRF: از آنجائیکه دیگر از کوکی استفاده نمیشود، نیازی به نگرانی در مورد حملات CSRF نیست. چون دیگر برای مثال امکان سوء استفادهی از کوکی فعلی اعتبارسنجی شده، جهت صدور درخواستهایی با سطح دسترسی شخص لاگین شده وجود ندارد؛ چون این روش کوکی را به سمت سرور ارسال نمیکند.
• کارآیی بهتر: حین استفادهی از توکنها، به علت ماهیت خود شمول آنها، رفت و برگشت کمتری به بانک اطلاعاتی صورت گرفته و سرعت بالاتری را شاهد خواهیم بود.
• امکان نوشتن آزمونهای یکپارچگی سادهتر: در حالت استفادهی از توکنها، آزمودن یکپارچگی برنامه، نیازی به رد شدن از صفحهی لاگین را ندارد و پیاده سازی این نوع آزمونها سادهتر از قبل است.
• استاندارد بودن: امروزه همینقدر که استاندارد JSON Web Token را پیاده سازی کرده باشید، امکان کار با انواع و اقسام پلتفرمها و کتابخانهها را خواهید یافت.
اما JWT یا JSON Web Token چیست؟
JSON Web Token یا JWT یک استاندارد وب است (RFC 7519) که روشی فشرده و خود شمول (self-contained) را جهت انتقال امن اطلاعات، بین مقاصد مختلف را توسط یک شیء JSON، تعریف میکند. این اطلاعات، قابل تصدیق و اطمینان هستند؛ از اینرو که به صورت دیجیتال امضاء میشوند. JWTها توسط یک کلید مخفی (با استفاده از الگوریتم HMAC) و یا یک جفت کلید خصوصی و عمومی (توسط الگوریتم RSA) قابل امضاء شدن هستند.
در این تعریف، واژههایی مانند «فشرده» و «خود شمول» بکار رفتهاند:
- «فشرده بودن»: اندازهی شیء JSON یک توکن در این حالت کوچک بوده و به سادگی از طریق یک URL و یا پارامترهای POST و یا داخل یک HTTP Header قابل ارسال است و به دلیل کوچک بودن این اندازه، انتقال آن نیز سریع است.
- «خود شمول»: بار مفید (payload) این توکن، شامل تمام اطلاعات مورد نیاز جهت اعتبارسنجی یک کاربر است؛ تا دیگر نیازی به کوئری گرفتن هر بارهی از بانک اطلاعاتی نباشد (در این روش مرسوم است که فقط یکبار از بانک اطلاعاتی کوئری گرفته شده و اطلاعات مرتبط با کاربر را امضای دیجیتال کرده و به سمت کاربر ارسال میکنند).
چه زمانی بهتر است از JWT استفاده کرد؟
اعتبارسنجی: اعتبارسنجی یک سناریوی متداول استفادهی از JWT است. زمانیکه کاربر به سیستم لاگین کرد، هر درخواست بعدی او شامل JWT خواهد بود که سبب میشود کاربر بتواند امکان دسترسی به مسیرها، صفحات و منابع مختلف سیستم را بر اساس توکن دریافتی، پیدا کند. برای مثال روشهای «Single Sign On» خود را با JWT انطباق دادهاند؛ از این جهت که سربار کمی را داشته و همچنین به سادگی توسط دومینهای مختلفی قابل استفاده هستند.
انتقال اطلاعات: توکنهای با فرمت JWT، روش مناسبی جهت انتقال اطلاعات امن بین مقاصد مختلف هستند؛ زیرا قابل امضاء بوده و میتوان اطمینان حاصل کرد که فرستنده دقیقا همانی است که ادعا میکند و محتوای ارسالی دست نخوردهاست.
ساختار یک JWT به چه صورتی است؟
JWTها دارای سه قسمت جدا شدهی با نقطه هستند؛ مانند xxxxx.yyyyy.zzzzz و شامل header، payload و signature میباشند.
الف) Header
Header عموما دارای دو قسمت است که نوع توکن و الگوریتم مورد استفادهی توسط آن را مشخص میکند:
{ "alg": "HS256", "typ": "JWT" }
ب) payload
payload یا «بار مفید» توکن، شامل claims است. منظور از claims، اطلاعاتی است در مورد موجودیت مدنظر (عموما کاربر) و یک سری متادیتای اضافی. سه نوع claim وجود دارند:
Reserved claims: یک سری اطلاعات مفید و از پیش تعیین شدهی غیراجباری هستند؛ مانند:
iss یا صادر کنند (issuer)، exp یا تاریخ انقضاء، sub یا عنوان (subject) و aud یا مخاطب (audience)
Public claims: میتواند شامل اطلاعاتی باشد که توسط IANA JSON Web Token Registry پیشتر ثبت شدهاست و فضاهای نام آنها تداخلی نداشته باشند.
Private claims: ادعای سفارشی هستند که جهت انتقال دادهها بین مقاصد مختلف مورد استفاده قرار میگیرند.
یک نمونهی payload را در اینجا ملاحظه میکنید:
{ "sub": "1234567890", "name": "John Doe", "admin": true }
ج) signature
یک نمونه فرمول محاسبهی امضای دیجیتال پیام JWT به صورت ذیل است:
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
یک نمونه مثال تولید این نوع توکنها را در آدرس https://jwt.io میتوانید بررسی کنید.
در این سایت اگر به قسمت دیباگر آن مراجعه کنید، برای نمونه قسمت payload آن قابل ویرایش است و تغییرات را بلافاصله در سمت چپ، به صورت انکد شده نمایش میدهد.
یک نکتهی مهم: توکنها امضاء شدهاند؛ نه رمزنگاری شده
همانطور که عنوان شد، توکنها از سه قسمت هدر، بار مفید و امضاء تشکیل میشوند (header.payload.signature). اگر از الگوریتم HMACSHA256 و کلید مخفی shhhh برای امضای بار مفید ذیل استفاده کنیم:
{ "sub": "1234567890", "name": "Ado Kukic", "admin": true }
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFkbyBLdWtpYyIsImFkbWluIjp0cnVlLCJpYXQiOjE0NjQyOTc4ODV9.Y47kJvnHzU9qeJIN48_bVna6O0EDFiMiQ9LpNVDFymM
البته امکان رمزنگاری توسط JSON Web Encryption نیز پیش بینی شدهاست (JWE).
از JWT در برنامهها چگونه استفاده میشود؟
زمانیکه کاربر، لاگین موفقی را به سیستم انجام میدهد، یک توکن امن توسط سرور صادر شده و با فرمت JWT به سمت کلاینت ارسال میشود. این توکن باید به صورت محلی در سمت کاربر ذخیره شود. عموما از local storage برای ذخیرهی این توکن استفاده میشود؛ اما استفادهی از کوکیها نیز منعی ندارد. بنابراین دیگر در اینجا سشنی در سمت سرور به ازای هر کاربر ایجاد نمیشود و کوکی سمت سروری به سمت کلاینت ارسال نمیگردد.
سپس هر زمانیکه کاربری قصد داشت به یک صفحه یا محتوای محافظت شده دسترسی پیدا کند، باید توکن خود را به سمت سرور ارسال نماید. عموما اینکار توسط یک header سفارشی Authorization به همراه Bearer schema صورت میگیرد و یک چنین شکلی را دارد:
Authorization: Bearer <token>
نگاهی به محل ذخیره سازی JWT و نکات مرتبط با آن
محل متداول ذخیرهی JWT ها، در local storage مرورگرها است و در اغلب سناریوها نیز به خوبی کار میکند. فقط باید دقت داشت که local storage یک sandbox است و محدود به دومین جاری برنامه و از طریق برای مثال زیر دامنههای آن قابل دسترسی نیست. در این حالت میتوان JWT را در کوکیهای ایجاد شدهی در سمت کاربر نیز ذخیره کرد که چنین محدودیتی را ندارند. اما باید دقت داشت که حداکثر اندازهی حجم کوکیها 4 کیلوبایت است و با افزایش claims ذخیره شدهی در یک JWT و انکد شدن آن، این حجم ممکن است از 4 کیلوبایت بیشتر شود. بنابراین باید به این نکات دقت داشت.
امکان ذخیره سازی توکنها در session storage مرورگرها نیز وجود دارد. session storage بسیار شبیه است به local storage اما به محض بسته شدن مرورگر، پاک میشود.
اگر از local storage استفاده میکنید، حملات Cross Site Request Forgery در اینجا دیگر مؤثر نخواهند بود. اما اگر به حالت استفادهی از کوکیها برای ذخیرهی توکنها سوئیچ کنید، این مساله همانند قبل خواهد بود و مسیر است. در این حالت بهتر است طول عمر توکنها را تاحد ممکن کوتاه تعریف کنید تا اگر اطلاعات آنها فاش شد، به زودی بیمصرف شوند.
انقضاء و صدور مجدد توکنها به چه صورتی است؟
توکنهای بدون حالت، صرفا بر اساس بررسی امضای پیام رسیده کار میکنند. به این معنا که یک توکن میتواند تا ابد معتبر باقی بماند. برای رفع این مشکل باید exp یا تاریخ انقضای متناسبی را به توکن اضافه کرد. برای برنامههای حساس این عدد میتواند 15 دقیقه باشد و برای برنامههای کمتر حساس، چندین ماه.
اما اگر در این بین قرار به ابطال سریع توکنی بود چه باید کرد؟ (مثلا کاربری را در همین لحظه غیرفعال کردهاید)
یک راه حل آن، ثبت رکوردهای تمام توکنهای صادر شده در بانک اطلاعاتی است. برای این منظور میتوان یک فیلد id مانند را به توکن اضافه کرد و آنرا صادر نمود. این idها را نیز در بانک اطلاعاتی ذخیره میکنیم. به این ترتیب میتوان بین توکنهای صادر شده و کاربران و اطلاعات به روز آنها ارتباط برقرار کرد. در این حالت برنامه علاوه بر بررسی امضای توکن، میتواند به لیست idهای صادر شده و ذخیره شدهی در دیتابیس نیز مراجعه کرده و اعتبارسنجی اضافهتری را جهت باطل کردن سریع توکنها انجام دهد. هرچند این روش دیگر آنچنان stateless نیست، اما با دنیای واقعی سازگاری بیشتری دارد.
حداکثر امنیت JWTها را چگونه میتوان تامین کرد؟
- تمام توکنهای خود را با یک کلید قوی، امضاء کنید و این کلید تنها باید بر روی سرور ذخیره شده باشد. هر زمانیکه سرور توکنی را از کاربر دریافت میکند، این سرور است که باید کار بررسی اعتبار امضای پیام رسیده را بر اساس کلید قوی خود انجام دهد.
- اگر اطلاعات حساسی را در توکنها قرار میدهید، باید از JWE یا JSON Web Encryption استفاده کنید؛ زیرا JWTها صرفا دارای امضای دیجیتال هستند و نه اینکه رمزنگاری شده باشند.
- بهتر است توکنها را از طریق ارتباطات غیر HTTPS، ارسال نکرد.
- اگر از کوکیها برای ذخیره سازی آنها استفاده میکنید، از HTTPS-only cookies استفاده کنید تا از Cross-Site Scripting XSS attacks در امان باشید.
- مدت اعتبار توکنهای صادر شده را منطقی انتخاب کنید.
On 16th November 2016, Nat Friedman and James Montemagno introduced Visual Studio for Mac, the newest member of the Visual Studio family at Connect(); 2016 event. I thought let's give it a try so I installed the same and went through the project templates available in it. This blog is kind of a getting started guide to install Visual Studio For Mac.
الف) مثالهای کدپلکس
ب) مثال نیوگت
در ادامه قصد داریم مثال نیوگت آنرا که مثال کاملی است از نحوهی استفاده از ASP.NET Identity در ASP.NET MVC، جهت اعمال الگوی واحد کار و تزریق وابستگیها، بازنویسی کنیم.
پیشنیازها
- برای درک مطلب جاری نیاز است ابتدا دورهی مرتبطی را در سایت مطالعه کنید و همچنین با نحوهی پیاده سازی الگوی واحد کار در EF Code First آشنا باشید.
- به علاوه فرض بر این است که یک پروژهی خالی ASP.NET MVC 5 را نیز آغاز کردهاید و توسط کنسول پاور شل نیوگت، فایلهای مثال Microsoft.AspNet.Identity.Samples را به آن افزودهاید:
PM> Install-Package Microsoft.AspNet.Identity.Samples -Pre
ساختار پروژهی تکمیلی
همانند مطلب پیاده سازی الگوی واحد کار در EF Code First، این پروژهی جدید را با چهار اسمبلی class library دیگر به نامهای
AspNetIdentityDependencyInjectionSample.DataLayer
AspNetIdentityDependencyInjectionSample.DomainClasses
AspNetIdentityDependencyInjectionSample.IocConfig
AspNetIdentityDependencyInjectionSample.ServiceLayer
تکمیل میکنیم.
ساختار پروژهی AspNetIdentityDependencyInjectionSample.DomainClasses
مثال Microsoft.AspNet.Identity.Samples بر مبنای primary key از نوع string است. برای نمونه کلاس کاربران آنرا به نام ApplicationUser در فایل Models\IdentityModels.cs میتوانید مشاهده کنید. در مطلب جاری، این نوع پیش فرض، به نوع متداول int تغییر خواهد یافت. به همین جهت نیاز است کلاسهای ذیل را به پروژهی DomainClasses اضافه کرد:
using System.ComponentModel.DataAnnotations.Schema; using Microsoft.AspNet.Identity.EntityFramework; namespace AspNetIdentityDependencyInjectionSample.DomainClasses { public class ApplicationUser : IdentityUser<int, CustomUserLogin, CustomUserRole, CustomUserClaim> { // سایر خواص اضافی در اینجا [ForeignKey("AddressId")] public virtual Address Address { get; set; } public int? AddressId { get; set; } } } using System.Collections.Generic; namespace AspNetIdentityDependencyInjectionSample.DomainClasses { public class Address { public int Id { get; set; } public string City { get; set; } public string State { get; set; } public virtual ICollection<ApplicationUser> ApplicationUsers { set; get; } } } using Microsoft.AspNet.Identity.EntityFramework; namespace AspNetIdentityDependencyInjectionSample.DomainClasses { public class CustomRole : IdentityRole<int, CustomUserRole> { public CustomRole() { } public CustomRole(string name) { Name = name; } } } using Microsoft.AspNet.Identity.EntityFramework; namespace AspNetIdentityDependencyInjectionSample.DomainClasses { public class CustomUserClaim : IdentityUserClaim<int> { } } using Microsoft.AspNet.Identity.EntityFramework; namespace AspNetIdentityDependencyInjectionSample.DomainClasses { public class CustomUserLogin : IdentityUserLogin<int> { } } using Microsoft.AspNet.Identity.EntityFramework; namespace AspNetIdentityDependencyInjectionSample.DomainClasses { public class CustomUserRole : IdentityUserRole<int> { } }
بدیهی است در اینجا کلاس پایه کاربران را میتوان سفارشی سازی کرد و خواص دیگری را نیز به آن افزود. برای مثال در اینجا یک کلاس جدید آدرس تعریف شدهاست که ارجاعی از آن در کلاس کاربران نیز قابل مشاهده است.
سایر کلاسهای مدلهای اصلی برنامه که جداول بانک اطلاعاتی را تشکیل خواهند داد نیز در آینده به همین اسمبلی DomainClasses اضافه میشوند.
ساختار پروژهی AspNetIdentityDependencyInjectionSample.DataLayer جهت اعمال الگوی واحد کار
اگر به همان فایل Models\IdentityModels.cs ابتدایی پروژه که اکنون کلاس ApplicationUser آنرا به پروژهی DomainClasses منتقل کردهایم، مجددا مراجعه کنید، کلاس DbContext مخصوص ASP.NET Identity نیز در آن تعریف شدهاست:
public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
اینترفیس IUnitOfWork برنامه، در پروژهی DataLayer چنین شکلی را دارد که نمونهای از آنرا در مطلب آشنایی با نحوهی پیاده سازی الگوی واحد کار در EF Code First، پیشتر ملاحظه کردهاید.
using System.Collections.Generic; using System.Data.Entity; namespace AspNetIdentityDependencyInjectionSample.DataLayer.Context { public interface IUnitOfWork { IDbSet<TEntity> Set<TEntity>() where TEntity : class; int SaveAllChanges(); void MarkAsChanged<TEntity>(TEntity entity) where TEntity : class; IList<T> GetRows<T>(string sql, params object[] parameters) where T : class; IEnumerable<TEntity> AddThisRange<TEntity>(IEnumerable<TEntity> entities) where TEntity : class; void ForceDatabaseInitialize(); } }
public class ApplicationDbContext : IdentityDbContext<ApplicationUser, CustomRole, int, CustomUserLogin, CustomUserRole, CustomUserClaim>, IUnitOfWork { public DbSet<Category> Categories { set; get; } public DbSet<Product> Products { set; get; } public DbSet<Address> Addresses { set; get; }
کار کردن با این کلاس، هیچ تفاوتی با DbContextهای متداول EF Code First ندارد و تمام اصول آنها یکی است.
در ادامه اگر به فایل App_Start\IdentityConfig.cs مراجعه کنید، کلاس ذیل در آن قابل مشاهدهاست:
public class ApplicationDbInitializer : DropCreateDatabaseIfModelChanges<ApplicationDbContext>
using System.Data.Entity.Migrations; namespace AspNetIdentityDependencyInjectionSample.DataLayer.Context { public class Configuration : DbMigrationsConfiguration<ApplicationDbContext> { public Configuration() { AutomaticMigrationsEnabled = true; AutomaticMigrationDataLossAllowed = true; } } }
ساختار پروژهی AspNetIdentityDependencyInjectionSample.ServiceLayer
در ادامه مابقی کلاسهای موجود در فایل App_Start\IdentityConfig.cs را به لایه سرویس برنامه منتقل خواهیم کرد. همچنین برای آنها یک سری اینترفیس جدید نیز تعریف میکنیم، تا تزریق وابستگیها به نحو صحیحی صورت گیرد. اگر به فایلهای کنترلر این مثال پیش فرض مراجعه کنید (پیش از تغییرات بحث جاری)، هرچند به نظر در کنترلرها، کلاسهای موجود در فایل App_Start\IdentityConfig.cs تزریق شدهاند، اما به دلیل عدم استفاده از اینترفیسها، وابستگی کاملی بین جزئیات پیاده سازی این کلاسها و نمونههای تزریق شده به کنترلرها وجود دارد و عملا معکوس سازی واقعی وابستگیها رخ ندادهاست. بنابراین نیاز است این مسایل را اصلاح کنیم.
الف) انتقال کلاس ApplicationUserManager به لایه سرویس برنامه
کلاس ApplicationUserManager فایل App_Start\IdentityConfig.c را به لایه سرویس منتقل میکنیم:
using System; using System.Security.Claims; using System.Threading.Tasks; using AspNetIdentityDependencyInjectionSample.DomainClasses; using AspNetIdentityDependencyInjectionSample.ServiceLayer.Contracts; using Microsoft.AspNet.Identity; using Microsoft.AspNet.Identity.Owin; using Microsoft.Owin.Security.Cookies; using Microsoft.Owin.Security.DataProtection; namespace AspNetIdentityDependencyInjectionSample.ServiceLayer { public class ApplicationUserManager : UserManager<ApplicationUser, int>, IApplicationUserManager { private readonly IDataProtectionProvider _dataProtectionProvider; private readonly IIdentityMessageService _emailService; private readonly IApplicationRoleManager _roleManager; private readonly IIdentityMessageService _smsService; private readonly IUserStore<ApplicationUser, int> _store; public ApplicationUserManager(IUserStore<ApplicationUser, int> store, IApplicationRoleManager roleManager, IDataProtectionProvider dataProtectionProvider, IIdentityMessageService smsService, IIdentityMessageService emailService) : base(store) { _store = store; _roleManager = roleManager; _dataProtectionProvider = dataProtectionProvider; _smsService = smsService; _emailService = emailService; createApplicationUserManager(); } public void SeedDatabase() { } private void createApplicationUserManager() { // Configure validation logic for usernames this.UserValidator = new UserValidator<ApplicationUser, int>(this) { AllowOnlyAlphanumericUserNames = false, RequireUniqueEmail = true }; // Configure validation logic for passwords this.PasswordValidator = new PasswordValidator { RequiredLength = 6, RequireNonLetterOrDigit = true, RequireDigit = true, RequireLowercase = true, RequireUppercase = true, }; // Configure user lockout defaults this.UserLockoutEnabledByDefault = true; this.DefaultAccountLockoutTimeSpan = TimeSpan.FromMinutes(5); this.MaxFailedAccessAttemptsBeforeLockout = 5; // Register two factor authentication providers. This application uses Phone and Emails as a step of receiving a code for verifying the user // You can write your own provider and plug in here. this.RegisterTwoFactorProvider("PhoneCode", new PhoneNumberTokenProvider<ApplicationUser, int> { MessageFormat = "Your security code is: {0}" }); this.RegisterTwoFactorProvider("EmailCode", new EmailTokenProvider<ApplicationUser, int> { Subject = "SecurityCode", BodyFormat = "Your security code is {0}" }); this.EmailService = _emailService; this.SmsService = _smsService; if (_dataProtectionProvider != null) { var dataProtector = _dataProtectionProvider.Create("ASP.NET Identity"); this.UserTokenProvider = new DataProtectorTokenProvider<ApplicationUser, int>(dataProtector); } } } }
- متد استاتیک Create این کلاس حذف و تعاریف آن به سازندهی کلاس منتقل شدهاند. به این ترتیب با هربار وهله سازی این کلاس توسط IoC Container به صورت خودکار این تنظیمات نیز به کلاس پایه UserManager اعمال میشوند.
- اگر به کلاس پایه UserManager دقت کنید، به آرگومانهای جنریک آن یک int هم اضافه شدهاست. این مورد جهت استفاده از primary key از نوع int ضروری است.
- در کلاس پایه UserManager تعدادی متد وجود دارند. تعاریف آنها را به اینترفیس IApplicationUserManager منتقل خواهیم کرد. نیازی هم به پیاده سازی این متدها در کلاس جدید ApplicationUserManager نیست؛ زیرا کلاس پایه UserManager پیشتر آنها را پیاده سازی کردهاست. به این ترتیب میتوان به یک تزریق وابستگی واقعی و بدون وابستگی به پیاده سازی خاص UserManager رسید. کنترلری که با IApplicationUserManager بجای ApplicationUserManager کار میکند، قابلیت تعویض پیاده سازی آنرا جهت آزمونهای واحد خواهد یافت.
- در کلاس اصلی ApplicationDbInitializer پیش فرض این مثال، متد Seed هم قابل مشاهدهاست. این متد را از کلاس جدید Configuration اضافه شده به DataLayer حذف کردهایم. از این جهت که در آن از متدهای کلاس ApplicationUserManager مستقیما استفاده شدهاست. متد Seed اکنون به کلاس جدید اضافه شده به لایه سرویس منتقل شده و در آغاز برنامه فراخوانی خواهد شد. DataLayer نباید وابستگی به لایه سرویس داشته باشد. لایه سرویس است که از امکانات DataLayer استفاده میکند.
- اگر به سازندهی کلاس جدید ApplicationUserManager دقت کنید، چند اینترفیس دیگر نیز به آن تزریق شدهاند. اینترفیس IApplicationRoleManager را ادامه تعریف خواهیم کرد. سایر اینترفیسهای تزریق شده مانند IUserStore، IDataProtectionProvider و IIdentityMessageService جزو تعاریف اصلی ASP.NET Identity بوده و نیازی به تعریف مجدد آنها نیست. فقط کلاسهای EmailService و SmsService فایل App_Start\IdentityConfig.c را نیز به لایه سرویس منتقل کردهایم. این کلاسها بر اساس تنظیمات IoC Container مورد استفاده، در اینجا به صورت خودکار ترزیق خواهند شد. حالت پیش فرض آن، وهله سازی مستقیم است که مطابق کدهای فوق به حالت تزریق وابستگیها بهبود یافتهاست.
ب) انتقال کلاس ApplicationSignInManager به لایه سرویس برنامه
کلاس ApplicationSignInManager فایل App_Start\IdentityConfig.c را نیز به لایه سرویس منتقل میکنیم.
using AspNetIdentityDependencyInjectionSample.DomainClasses; using AspNetIdentityDependencyInjectionSample.ServiceLayer.Contracts; using Microsoft.AspNet.Identity.Owin; using Microsoft.Owin.Security; namespace AspNetIdentityDependencyInjectionSample.ServiceLayer { public class ApplicationSignInManager : SignInManager<ApplicationUser, int>, IApplicationSignInManager { private readonly ApplicationUserManager _userManager; private readonly IAuthenticationManager _authenticationManager; public ApplicationSignInManager(ApplicationUserManager userManager, IAuthenticationManager authenticationManager) : base(userManager, authenticationManager) { _userManager = userManager; _authenticationManager = authenticationManager; } } }
ج) انتقال کلاس ApplicationRoleManager به لایه سرویس برنامه
کلاس ApplicationRoleManager فایل App_Start\IdentityConfig.c را نیز به لایه سرویس منتقل خواهیم کرد:
using AspNetIdentityDependencyInjectionSample.DomainClasses; using AspNetIdentityDependencyInjectionSample.ServiceLayer.Contracts; using Microsoft.AspNet.Identity; namespace AspNetIdentityDependencyInjectionSample.ServiceLayer { public class ApplicationRoleManager : RoleManager<CustomRole, int>, IApplicationRoleManager { private readonly IRoleStore<CustomRole, int> _roleStore; public ApplicationRoleManager(IRoleStore<CustomRole, int> roleStore) : base(roleStore) { _roleStore = roleStore; } public CustomRole FindRoleByName(string roleName) { return this.FindByName(roleName); // RoleManagerExtensions } public IdentityResult CreateRole(CustomRole role) { return this.Create(role); // RoleManagerExtensions } } }
تا اینجا کار تنظیمات لایه سرویس برنامه به پایان میرسد.
ساختار پروژهی AspNetIdentityDependencyInjectionSample.IocConfig
پروژهی IocConfig جایی است که تنظیمات StructureMap را به آن منتقل کردهایم:
using System; using System.Data.Entity; using System.Threading; using System.Web; using AspNetIdentityDependencyInjectionSample.DataLayer.Context; using AspNetIdentityDependencyInjectionSample.DomainClasses; using AspNetIdentityDependencyInjectionSample.ServiceLayer; using AspNetIdentityDependencyInjectionSample.ServiceLayer.Contracts; using Microsoft.AspNet.Identity; using Microsoft.AspNet.Identity.EntityFramework; using Microsoft.Owin.Security; using StructureMap; using StructureMap.Web; namespace AspNetIdentityDependencyInjectionSample.IocConfig { public static class SmObjectFactory { private static readonly Lazy<Container> _containerBuilder = new Lazy<Container>(defaultContainer, LazyThreadSafetyMode.ExecutionAndPublication); public static IContainer Container { get { return _containerBuilder.Value; } } private static Container defaultContainer() { return new Container(ioc => { ioc.For<IUnitOfWork>() .HybridHttpOrThreadLocalScoped() .Use<ApplicationDbContext>(); ioc.For<ApplicationDbContext>().HybridHttpOrThreadLocalScoped().Use<ApplicationDbContext>(); ioc.For<DbContext>().HybridHttpOrThreadLocalScoped().Use<ApplicationDbContext>(); ioc.For<IUserStore<ApplicationUser, int>>() .HybridHttpOrThreadLocalScoped() .Use<UserStore<ApplicationUser, CustomRole, int, CustomUserLogin, CustomUserRole, CustomUserClaim>>(); ioc.For<IRoleStore<CustomRole, int>>() .HybridHttpOrThreadLocalScoped() .Use<RoleStore<CustomRole, int, CustomUserRole>>(); ioc.For<IAuthenticationManager>() .Use(() => HttpContext.Current.GetOwinContext().Authentication); ioc.For<IApplicationSignInManager>() .HybridHttpOrThreadLocalScoped() .Use<ApplicationSignInManager>(); ioc.For<IApplicationUserManager>() .HybridHttpOrThreadLocalScoped() .Use<ApplicationUserManager>(); ioc.For<IApplicationRoleManager>() .HybridHttpOrThreadLocalScoped() .Use<ApplicationRoleManager>(); ioc.For<IIdentityMessageService>().Use<SmsService>(); ioc.For<IIdentityMessageService>().Use<EmailService>(); ioc.For<ICustomRoleStore>() .HybridHttpOrThreadLocalScoped() .Use<CustomRoleStore>(); ioc.For<ICustomUserStore>() .HybridHttpOrThreadLocalScoped() .Use<CustomUserStore>(); //config.For<IDataProtectionProvider>().Use(()=> app.GetDataProtectionProvider()); // In Startup class ioc.For<ICategoryService>().Use<EfCategoryService>(); ioc.For<IProductService>().Use<EfProductService>(); }); } } }
در تعاریف فوق یک مورد را به فایل Startup.cs موکول کردهایم. برای مشخص سازی نمونهی پیاده سازی کنندهی IDataProtectionProvider نیاز است به IAppBuilder کلاس Startup برنامه دسترسی داشت. این کلاس آغازین Owin اکنون به نحو ذیل بازنویسی شدهاست و در آن، تنظیمات IDataProtectionProvider را به همراه وهله سازی CreatePerOwinContext مشاهده میکنید:
using System; using AspNetIdentityDependencyInjectionSample.IocConfig; using AspNetIdentityDependencyInjectionSample.ServiceLayer.Contracts; using Microsoft.AspNet.Identity; using Microsoft.Owin; using Microsoft.Owin.Security.Cookies; using Microsoft.Owin.Security.DataProtection; using Owin; using StructureMap.Web; namespace AspNetIdentityDependencyInjectionSample { public class Startup { public void Configuration(IAppBuilder app) { configureAuth(app); } private static void configureAuth(IAppBuilder app) { SmObjectFactory.Container.Configure(config => { config.For<IDataProtectionProvider>() .HybridHttpOrThreadLocalScoped() .Use(()=> app.GetDataProtectionProvider()); }); SmObjectFactory.Container.GetInstance<IApplicationUserManager>().SeedDatabase(); // Configure the db context, user manager and role manager to use a single instance per request app.CreatePerOwinContext(() => SmObjectFactory.Container.GetInstance<IApplicationUserManager>()); // Enable the application to use a cookie to store information for the signed in user // and to use a cookie to temporarily store information about a user logging in with a third party login provider // Configure the sign in cookie app.UseCookieAuthentication(new CookieAuthenticationOptions { AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie, LoginPath = new PathString("/Account/Login"), Provider = new CookieAuthenticationProvider { // Enables the application to validate the security stamp when the user logs in. // This is a security feature which is used when you change a password or add an external login to your account. OnValidateIdentity = SmObjectFactory.Container.GetInstance<IApplicationUserManager>().OnValidateIdentity() } }); app.UseExternalSignInCookie(DefaultAuthenticationTypes.ExternalCookie); // Enables the application to temporarily store user information when they are verifying the second factor in the two-factor authentication process. app.UseTwoFactorSignInCookie(DefaultAuthenticationTypes.TwoFactorCookie, TimeSpan.FromMinutes(5)); // Enables the application to remember the second login verification factor such as phone or email. // Once you check this option, your second step of verification during the login process will be remembered on the device where you logged in from. // This is similar to the RememberMe option when you log in. app.UseTwoFactorRememberBrowserCookie(DefaultAuthenticationTypes.TwoFactorRememberBrowserCookie); } } }
تنظیمات برنامهی اصلی ASP.NET MVC، جهت اعمال تزریق وابستگیها
الف) ابتدا نیاز است فایل Global.asax.cs را به نحو ذیل بازنویسی کنیم:
using System; using System.Data.Entity; using System.Web; using System.Web.Mvc; using System.Web.Optimization; using System.Web.Routing; using AspNetIdentityDependencyInjectionSample.DataLayer.Context; using AspNetIdentityDependencyInjectionSample.IocConfig; using StructureMap.Web.Pipeline; namespace AspNetIdentityDependencyInjectionSample { public class MvcApplication : HttpApplication { protected void Application_Start() { AreaRegistration.RegisterAllAreas(); FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters); RouteConfig.RegisterRoutes(RouteTable.Routes); BundleConfig.RegisterBundles(BundleTable.Bundles); setDbInitializer(); //Set current Controller factory as StructureMapControllerFactory ControllerBuilder.Current.SetControllerFactory(new StructureMapControllerFactory()); } protected void Application_EndRequest(object sender, EventArgs e) { HttpContextLifecycle.DisposeAndClearAll(); } public class StructureMapControllerFactory : DefaultControllerFactory { protected override IController GetControllerInstance(RequestContext requestContext, Type controllerType) { if (controllerType == null) throw new InvalidOperationException(string.Format("Page not found: {0}", requestContext.HttpContext.Request.RawUrl)); return SmObjectFactory.Container.GetInstance(controllerType) as Controller; } } private static void setDbInitializer() { Database.SetInitializer(new MigrateDatabaseToLatestVersion<ApplicationDbContext, Configuration>()); SmObjectFactory.Container.GetInstance<IUnitOfWork>().ForceDatabaseInitialize(); } } }
ب) به پوشهی Models برنامه مراجعه کنید. در اینجا در هر کلاسی که Id از نوع string وجود داشت، باید تبدیل به نوع int شوند. چون primary key برنامه را به نوع int تغییر دادهایم. برای مثال کلاسهای EditUserViewModel و RoleViewModel باید تغییر کنند.
ج) اصلاح کنترلرهای برنامه جهت اعمال تزریق وابستگیها
اکنون اصلاح کنترلرها جهت اعمال تزریق وابستگیها سادهاست. در ادامه نحوهی تغییر امضای سازندههای این کنترلرها را جهت استفاده از اینترفیسهای جدید مشاهده میکنید:
[Authorize] public class AccountController : Controller { private readonly IAuthenticationManager _authenticationManager; private readonly IApplicationSignInManager _signInManager; private readonly IApplicationUserManager _userManager; public AccountController(IApplicationUserManager userManager, IApplicationSignInManager signInManager, IAuthenticationManager authenticationManager) { _userManager = userManager; _signInManager = signInManager; _authenticationManager = authenticationManager; } [Authorize] public class ManageController : Controller { // Used for XSRF protection when adding external logins private const string XsrfKey = "XsrfId"; private readonly IAuthenticationManager _authenticationManager; private readonly IApplicationUserManager _userManager; public ManageController(IApplicationUserManager userManager, IAuthenticationManager authenticationManager) { _userManager = userManager; _authenticationManager = authenticationManager; } [Authorize(Roles = "Admin")] public class RolesAdminController : Controller { private readonly IApplicationRoleManager _roleManager; private readonly IApplicationUserManager _userManager; public RolesAdminController(IApplicationUserManager userManager, IApplicationRoleManager roleManager) { _userManager = userManager; _roleManager = roleManager; } [Authorize(Roles = "Admin")] public class UsersAdminController : Controller { private readonly IApplicationRoleManager _roleManager; private readonly IApplicationUserManager _userManager; public UsersAdminController(IApplicationUserManager userManager, IApplicationRoleManager roleManager) { _userManager = userManager; _roleManager = roleManager; }
البته تعدادی اکشن متد نیز در اینجا وجود دارند که از string id استفاده میکنند. اینها را باید به int? Id تغییر داد تا با نوع primary key جدید مورد استفاده تطابق پیدا کنند.
کدهای کامل این مثال را از اینجا میتوانید دریافت کنید:
AspNetIdentityDependencyInjectionSample
معادل این پروژه جهت ASP.NET Core Identity : «سفارشی سازی ASP.NET Core Identity - قسمت اول - موجودیتهای پایه و DbContext برنامه »
ارتباط با سخت افزار کاربر با Web RTC
این پروژه در 12 بخش گوناگون تقسیم بندی شدهاست که هر کدام در قالب یک فایل HTML میباشد و تمامی اسکریپتهای مورد نیاز به آن افزوده شدهاست. هر بخش به صورت مجزا به شرح یک ویژگی کاربردی در angular-translate میپردازد.
ex1_basic_usage
<script src="Scripts/angular.js"></script> <script src="Scripts/angular-translate.js"></script>
angular.module('app', ['pascalprecht.translate']) .config([ '$translateProvider', function ($translateProvider) { // Adding a translation table for the English language $translateProvider.translations('en_US', { "TITLE": "How to use", "HEADER": "You can translate texts by using a filter.", "SUBHEADER": "And if you don't like filters, you can use a directive.", "HTML_KEYS": "If you don't like an empty elements, you can write a key for the translation as an inner HTML of the directive.", "DATA_TO_FILTER": "Your translations might also contain any static ({{staticValue}}) or random ({{randomValue}}) values, which are taken directly from the model.", "DATA_TO_DIRECTIVE": "And it's no matter if you use filter or directive: static is still {{staticValue}} and random is still {{randomValue}}.", "RAW_TO_FILTER": "In case you want to pass a {{type}} data to the filter, you have only to pass it as a filter parameter.", "RAW_TO_DIRECTIVE": "This trick also works for {{type}} with a small mods.", "SERVICE": "Of course, you can translate your strings directly in the js code by using a $translate service.", "SERVICE_PARAMS": "And you are still able to pass params to the texts. Static = {{staticValue}}, random = {{randomValue}}." }); // Adding a translation table for the Russian language $translateProvider.translations('ru_RU', { "TITLE": "Как пользоваться", "HEADER": "Вы можете переводить тексты при помощи фильтра.", "SUBHEADER": "А если Вам не нравятся фильтры, Вы можете воспользоваться директивой.", "HTML_KEYS": "Если вам не нравятся пустые элементы, Вы можете записать ключ для перевода в как внутренний HTML директивы.", "DATA_TO_FILTER": "Ваши переводы также могут содержать любые статичные ({{staticValue}}) или случайные ({{randomValue}}) значения, которые берутся прямо из модели.", "DATA_TO_DIRECTIVE": "И совершенно не важно используете ли Вы фильтр или директиву: статическое значение по прежнему {{staticValue}} и случайное - {{randomValue}}.", "RAW_TO_FILTER": "Если вы хотите передать \"сырые\" ({{type}}) данные фильтру, Вам всего лишь нужно передать их фильтру в качестве параметров.", "RAW_TO_DIRECTIVE": "Это также работает и для директив ({{type}}) с небольшими модификациями.", "SERVICE": "Конечно, Вы можете переводить ваши строки прямо в js коде при помощи сервиса $translate.", "SERVICE_PARAMS": "И вы все еще можете передавать параметры в тексты. Статическое значение = {{staticValue}}, случайное = {{randomValue}}." }); // Tell the module what language to use by default $translateProvider.preferredLanguage('en_US'); }])
.controller('ctrl', ['$scope', '$translate', function ($scope, $translate) { $scope.tlData = { staticValue: 42, randomValue: Math.floor(Math.random() * 1000) }; $scope.jsTrSimple = $translate.instant('SERVICE'); $scope.jsTrParams = $translate.instant('SERVICE_PARAMS', $scope.tlData); $scope.setLang = function (langKey) { // You can change the language during runtime $translate.use(langKey); // A data generated by the script have to be regenerated $scope.jsTrSimple = $translate.instant('SERVICE'); $scope.jsTrParams = $translate.instant('SERVICE_PARAMS', $scope.tlData); }; }]);
<p> <a href="#" ng-click="setLang('en_US')">English</a> | <a href="#" ng-click="setLang('ru_RU')">Русский</a> </p> <!-- Translation by a filter --> <h1>{{'HEADER' | translate}}</h1> <!-- Translation by a directive --> <h2 translate="SUBHEADER">Subheader</h2> <!-- Using inner HTML as a key for translation --> <p translate>HTML_KEYS</p> <hr> <!-- Passing a data object to the translation by the filter --> <p>{{'DATA_TO_FILTER' | translate: tlData}}</p> <!-- Passing a data object to the translation by the directive --> <p translate="DATA_TO_DIRECTIVE" translate-values="{{tlData}}"></p> <hr> <!-- Passing a raw data to the filter --> <p>{{'RAW_TO_FILTER' | translate:'{ type: "raw" }' }}</p> <!-- Passing a raw data to the filter --> <p translate="RAW_TO_DIRECTIVE" translate-values="{ type: 'directives' }"></p> <hr> <!-- Using a $translate service --> <p>{{jsTrSimple}}</p> <!-- Passing a data to the $translate service --> <p>{{jsTrParams}}</p>
ex2_remember_language_cookies
<script src="Scripts/angular-cookies.js"></script> <script src="Scripts/angular-translate-storage-cookie.js"></script>
// Tell the module to store the language in the cookie $translateProvider.useCookieStorage();
ex3_remember_language_local_storage
این مثال همانند مثال قبل رفتار میکند، با این تفاوت که به جای اینکه کلید زبان کنونی را درون کوکی ذخیره کند، آن را درون Local Storage با نام NG_TRANSLATE_LANG_KEY قرار میدهد. برای اجرا کافیست اسکریپتها و تکه کد زیر را با موارد مثال قبل جایگزین کنید.
<script src="Scripts/angular-translate-storage-local.js"></script> // Tell the module to store the language in the local storage $translateProvider.useLocalStorage();
مثال های ex4_set_a_storage_key و ex5_set_a_storage_prefix نام کلیدی که برای ذخیره سازی زبان کنونی در کوکی یا Local Storage قرار میگیرد را تغییر میدهد که به دلیل سادگی از شرح آن میگذریم.
ex6_namespace_support
translate table در angular-translate قابلیت مفید namespacing را نیز داراست. این قابلیت به ما کمک میکند که جهت کپسوله کردن بخشهای مختلف، ترجمه آنها را با namespaceهای خاص خود نمایش دهیم. به مثال زیر توجه کنید:
$translateProvider.translations('en_US', { "TITLE": "How to use namespaces", "ns1": { "HEADER": "A translations table supports namespaces.", "SUBHEADER": "So you can to structurize your translation table well." }, "ns2": { "HEADER": "Do you want to have a structured translations table?", "SUBHEADER": "You can to use namespaces now." } });
همانطور که توجه میکنید بخش ns1 خود شامل زیر مجموعههایی است و ns2 نیز به همین صورت. هر کدام دارای کلید HEADER و SUBHEADER میباشند. فرض کنید هر کدام از این بخشها میخواهند اطلاعات درون یک section را نمایش دهند. حال به نحوهی فراخوانی این translate tableها دقت کنید:
<!-- section 1: Translate Table Called by ns1 namespace --> <h1 translate>ns1.HEADER</h1> <h2 translate>ns1.SUBHEADER</h2> <!-- section 2: Translate Table Called by ns2 namespace --> <h1 translate>ns2.HEADER</h1> <h2 translate>ns2.SUBHEADER</h2>
به همین سادگی میتوان تمامی بخشها را با namespaceهای مختلف در translate table قرار داد.
در بخش بعدی (پایانی) شش قابلیت دیگر angular translate که شامل فراخوانی translate table از یک فایل JSON، فراخوانی فایلهای translate table به صورت lazy load و تغییر زبان بخشی از صفحه به صورت پویا هستند، بررسی خواهند شد.
فایل پروژه: AngularJs-Translate-BestPractices.zip
ReSharper Ultimate 2019.2.3 منتشر شد
Moments ago we published a new bugfix – please welcome ReSharper Ultimate 2019.2.3 . It delivers highly requested support for the .NET Core 3.0 release build, which was released earlier, for all the tools in the ReSharper Ultimate family!