R4MVC is a Roslyn code generator for ASP.NET MVC Core apps that creates strongly typed helpers that eliminate the use of literal strings in many places.
It is a re-implementation of T4MVC for ASP.NET Core projects.
ممنون از مطلب خوبتون.
من جداول خودم رو برای احراز هویت دارم آیا میشه همین جداول رو با ASP.NET Identity کار کنم؟
اگر نمیشه، این بانک ASP.NET Identity که توی SQL Server نمیسازه بانک Database.mdf رو میسازه، میشه توی SQL بسازیم از همون ابتدای پروژه؟
سلام، متشکرم.
ASP.NET Identity بصورت پیش فرض در قالب پروژه‌های VS 2013 استفاده میشه. در پست‌های قبلی بیشتر درباره این فریم بحث شده که می‌تونید مراجعه کنید. برای اطلاعات بیشتر به ASP.NET Identity سر بزنید.
If you are using StructreMap to resolve the dependencies in the ASP.NET MVC 5 application then Steve Smith’s blog postResolving Dependencies in ASP.NET MVC 5 with StructureMap can be a great help for you
با عرض سلام و تشکر
1. در پروژه برای کلاس Product و Category، مثالی برای اعمال CRUD در سطح کنترلر ارائه نشده، یا من پیدا نکردم؟ یا چون در بحث Identity نبوده تکمیل نشده این قسمت.
در این پروژه آیا برای انجام عملیات CRUD، به روشی که در پروژه «اعتبار سنجی مبتنی بر Jwt در ASP.net Core 2.0 بدون استفاده از سیستم Identity» معرفی کردین عمل کنم ؟
2. تفاوت طراحی این دو پروژه در قسمتهای تزریق وابستگی، و دقیقا انجام عملیات CRUD در کنترلرهای سطح پروژه وب، چیست ؟
در ساختار درونی سیستم ASP.NET Core Identity، در عمل چیزی
به نام Role وجود خارجی ندارد. برای مثال Roleها هم در این سیستم یک User-Claim از نوع ClaimTypes.Role هستند. تمام سیستم Identity بر اساس
User Claims کار می‌کند. تمام Roleها و غیره در پشت صحنه ابتدا تبدیل به user claims می‌شوند و سپس استفاده خواهند شد.
var roles = ((ClaimsIdentity)User.Identity).Claims
.Where(c => c.Type == ClaimTypes.Role)
.Select(c => c.Value); 
خیر. شیء this.User با اطلاعات جدول کاربران، تناظر یک به یک ندارد. از نگارش‌های پیشین ASP.NET ، هنوز هم اطلاعات شیء User مانند
User.Identity.Name در ASP.NET Core نیز در دسترس هستند. به این ترتیب
زمانیکه کاربری به سیستم وارد شد، دیگر نیازی نیست تا جهت یافتن Name او،
از بانک اطلاعاتی کوئری گرفت. خاصیت Name یاد شده به صورت خودکار از کوکی
رمزنگاری شده‌ی و یا در اینجا از توکن او دریافت شده و در اختیار برنامه قرار می‌گیرد. این Name
در ASP.NET Core Identity، اصطلاحا یک User Claim پیش‌فرض نام دارد و به
صورت خودکار ایجاد و مقدار دهی می‌شود. روش مقدار دهی اولیه‌ی آن هم در متد createAccessTokenAsync مشخص است. هر زمانیکه این توکن به سمت سرور ارسال می‌شود، پس از اعتبارسنجی توکن و پذیرش آن، این Claims هم پردازش شده و جزئی از اطلاعات شیء this.User می‌شوند.
- هدرهای سفارشی را نمی‌توان با فرم‌های معمولی ارسال کرد. این روش برای کار با فرم‌های معمولی POST غیر Ajax ای طراحی نشده. برای آن‌ها (فرم‌های post back ای) از روش کار با کوکی‌ها استفاده کنید که به صورت خودکار توسط مرورگر ارسال می‌شوند و نیاز به تنظیم خاصی ندارند: «اعتبارسنجی مبتنی بر کوکی‌ها در ASP.NET Core 2.0 بدون استفاده از سیستم Identity»
- البته OnMessageReceived را در صفحه‌ی جاری جستجو کنید. امکان ارسال توکن‌ها به صورت فیلدهای سفارشی هم وجود دارد که در سمت سرور باید آن‌ها را پردازش کنید.
ارتقاء به 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);
} - در قسمت اول
به واژه‌هایی مانند «شرکت»، «مرکزی»، «single sign-on»، و «چندین
برنامه‌ی مختلف فقط با یک لاگین» که قرار نیست اطلاعات کاربران خودشان را
داخل بانک‌های اطلاعاتی خودشان به صورت مجزایی قرار دهند، بیشتر دقت کنید.
- Identity Server برای انتقال و نگهداری اطلاعات موقتی خودش از ترکیب کوکی‌های رمزنگاری شده و همچنین JWT استفاده می‌کند. مثال کاملی در این مورد در سری جدید «امن سازی برنامه‌های ASP.NET Core توسط IdentityServer 4x» با تمام جزئیات ممکن، بررسی شده‌است.