نظرات مطالب
اعتبارسنجی مبتنی بر JWT در ASP.NET Core 2.0 بدون استفاده از سیستم Identity
- هدرهای سفارشی را نمی‌توان با فرم‌های معمولی ارسال کرد. این روش برای کار با فرم‌های معمولی POST غیر Ajax ای طراحی نشده. برای آن‌ها (فرم‌های post back ای) از روش کار با کوکی‌ها استفاده کنید که به صورت خودکار توسط مرورگر ارسال می‌شوند و نیاز به تنظیم خاصی ندارند: «اعتبارسنجی مبتنی بر کوکی‌ها در ASP.NET Core 2.0 بدون استفاده از سیستم Identity» 
- البته OnMessageReceived را در صفحه‌ی جاری جستجو کنید. امکان ارسال توکن‌ها به صورت فیلدهای سفارشی هم وجود دارد که در سمت سرور باید آن‌ها را پردازش کنید.
نظرات مطالب
سفارشی سازی ASP.NET Core Identity - قسمت سوم - نرمال سازها و اعتبارسنج‌ها
ارتقاء به ASP.NET Core Identity 3.0

امضای اینترفیس ILookupNormalizer، از حالت کلی زیر، که هم ایمیل و هم نام را شامل می‌شد:
    public interface ILookupNormalizer
    {
        string Normalize(string key);
    }
به حالت اختصاصی‌تر زیر تغییر کرده‌است:
    public interface ILookupNormalizer
    {
        string NormalizeEmail(string email);
        string NormalizeName(string name);
    }
نظرات مطالب
IdentityServer قسمت اول
- در قسمت اول به واژه‌هایی مانند «شرکت»، «مرکزی»، «single sign-on»، و «چندین برنامه‌ی مختلف فقط با یک لاگین» که قرار نیست اطلاعات کاربران خودشان را داخل بانک‌های اطلاعاتی خودشان به صورت مجزایی قرار دهند، بیشتر دقت کنید.
- Identity Server برای انتقال و نگهداری اطلاعات موقتی خودش از ترکیب کوکی‌های رمزنگاری شده و همچنین JWT استفاده می‌کند. مثال کاملی در این مورد در سری جدید «امن سازی برنامه‌های ASP.NET Core توسط IdentityServer 4x» با تمام جزئیات ممکن، بررسی شده‌است.
نظرات مطالب
اعتبارسنجی مبتنی بر JWT در ASP.NET Core 2.0 بدون استفاده از سیستم Identity
از هر دو می‌توانید استفاده کنید. اولی مبتنی بر توکن‌ها است «معرفی JSON Web Token» و دومی به صورت پیش‌فرض مبتنی بر کوکی‌ها. توکن‌ها برای برنامه‌های SPA، مانند Angular بیشتر مرسوم هستند. امکان کار کردن با آ‌ن‌ها در برنامه‌های غیروبی هم هست. در کل هدف از بحث جاری، ارائه‌ی یک راه حل سبک، بجای ASP.NET Core Identity هست و تمام امکانات آن‌را شامل نمی‌شود.
نظرات مطالب
ASP.NET MVC و Identity 2.0 : مفاهیم پایه
سلام؛ با فرض استفاده از asp.net mvc5 code first و Identity 2.0، چطور می‌تونیم یک فیلد سفارشی (به طور مثال فیلد تاریخ انقضا) به جدول AspNetUserRoles  اضافه کنیم و بعد از اضافه کردن چطور می‌تونیم به این فیلد دسترسی داشته باشیم؟ هدف اینه که به کاربران نقشی به مدت محدود اعطا بشه. در واقع نقشی که به کاربر اعطا می‌شه دارای تاریخ انقضا باشه.
نظرات مطالب
سفارشی سازی ASP.NET Core Identity - قسمت پنجم - سیاست‌های دسترسی پویا
برای افزودن لیست Claims کاربر موجود در بانک اطلاعاتی به لیست Claims کاربر وارد شده‌ی توسط اکتیو دایرکتوری، باید از یک IClaimsTransformation سفارشی استفاده کنید تا این نگاشت را انجام دهد (نمونه‌اش در مطلب « سفارشی سازی ASP.NET Core Identity - قسمت چهارم - User Claims » به نحو دیگری استفاده شده‌است):
public class ApplicationClaimsTransformation : IClaimsTransformation
{
}
پیاده سازی کامل آن در اینجا
و برای ثبت آن:
services.AddScoped<IClaimsTransformation, ApplicationClaimsTransformation>();
نظرات مطالب
شروع به کار با EF Core 1.0 - قسمت 14 - لایه بندی و تزریق وابستگی‌ها
- احتمالا مرتبط است به حالت Transient که در نظر بعدی به آن اشاره کردید. یک نمونه پروژه که از الگوی جاری استفاده می‌کند DNTIdentity است که جزئیات و توضیحات بیشتر آن‌را می‌توانید در گروه ASP.NET Core Identity پیگیری نمائید.
- همچنین مطالب « کار با کلیدهای اصلی و خارجی در EF Code first» و «شروع به کار با EF Core 1.0 - قسمت 13 - بررسی سیستم ردیابی تغییرات» را نیز مطالعه کنید .  
نظرات مطالب
اعمال تزریق وابستگی‌ها به مثال رسمی ASP.NET Identity
- بله. فقط بجای return Viewها شما بازگشت متداول http status‌ها را خواهید داشت مانند return NotFound و یا return Ok. مابقی کدهای آن تفاوتی نمی‌کند.
- هدف نحوه‌ی نمایش این است که تزریق وابستگی‌های ASP.NET Identity و امکانات تنظیم شده‌ی آن در این مثال، در یک کنترلر Web API هم کار می‌کند.
- اگر هدف صرفا استفاده از Single page applications و Web API است، روش استفاده‌ی JWT متداول‌تر است.
نظرات مطالب
طراحی افزونه پذیر با ASP.NET MVC 4.x/5.x - قسمت سوم
مطلب «اعمال تزریق وابستگی‌ها به مثال رسمی ASP.NET Identity» را مطالعه کنید. نیازی نیست چندین Context ایجاد کنید. اینبار Context اصلی برنامه همان ApplicationDbContext خواهد بود. یعنی در مثال جاری، کلاس MvcPluginMasterAppContext با ApplicationDbContext جایگزین می‌شود؛ به همراه افزودن کدهای سفارشی کلاس MvcPluginMasterAppContext به ApplicationDbContext.
نظرات مطالب
مدیریت سفارشی سطوح دسترسی کاربران در MVC
وجود اینترفیس و قرارداد در کدها برای این است که هم طراح و هم استفاده کننده تکلیف خودشان را بدانند. اگر قرار باشد این اینترفیس‌ها به میل شما هر روز تغییر کنند که دیگر به آن قرارداد گفته نمی‌شود. ضمنا برای پاسخگویی به این نوع سؤالات تمامی ناپذیر، سیستم جدیدی رو طراحی کردند به نام ASP.NET Identity. این سیستم از بنیان سورس باز هست. در اینجا شما هر طور که دوست داشتید، تمام اینترفیس‌ها و کدها رو تغییر بدید. سورس رو که دارید. وابسته هم نیست به بانک اطلاعاتی خاصی.