یکی از تغییرات مهم Identity 3 نسبت به نسخه قبلی و قطعه کد پرکاربرد
using Microsoft.AspNet.Identity; User.Identity.GetUserId();
این لینک به نظرم جالب اومد. این مطلب توسط جونارک از ایالات متحده نوشته شده است. در این پروژه با استفاده از JQuery UI ِِDialog در محیط ASP.NET یک GridView ساخته می‌شود. به ازای هر سطر GridView ما کلید حذف داریم و با کلیک روی آن قبل از اقدام به حذف یک دیالوگ تصدیق به ما نشان می‌دهد.
برای افزایش سطح امنیتی پیشنهاد میشه هنگام هش حتماً از یک کلید دیگه هم استفاده بشه چون در صورتی که فرد مهاجم از فرآیند هشینگ اطلاع پیدا کرد نتونه با تغییر داده و هشینگ داده جعلی و جایگزینی هشینگ آن با هشینگ داده اصلی، باعث عدم اصالت رکورد بشه
در سناریویی که برای سفارشی سازی Identity داریم باید Claims و Logins و ... رو از User جدا کنیم؛ به این که هر کاربر در نرم افزارهای مختلف دارای Claims متفاوتی است. با Ignore کردن UserId در Claims و ... و تعریف یک کلید جدید باز هم رابطه‌ی بین User و Claims ایجاد می‌شود!
چگونه باید از ایجاد این ارتباط جلوگیری کرد؟
تشکر
با سلام. یک سوال در رابطه با جدول UserToken داشتم. من برای ذخیره کردن توکن برای کاربران میخوام از این جدول استفاده کنم و فیلدهای LoginProvider و Name هم به عنوان کلید اصلی در نظر گرفته شده است. در هنگام درج رکورد چه مقادیری باید به این دو فیلد بدهم. یا باید جدول دیگه ای برای این کار اضافه کنم؟
ممنون از راهنمایی
میخواستم بدونم امنیت در این پروژه به چه نحوی مدیریت میشه؟
منظورم این هست که برای ارسال اطلاعات تنظیمات درگاه توسط یک کلید که خود کاربر ارسال میکند اطلاعات رو Enc , Dec کرد تا امنیت بیشتری وجود داشته باشه
- ممکن است Cookei.Name ایی را که انتخاب کرده‌اید، جای دیگری هم استفاده شده‌است و قسمت‌های دیگری آن‌را بازنویسی می‌کنند. این نام را تغییر دهید.
- ممکن است کلید رمزنگاری اطلاعات در این بین تغییر کرده‌است که اطلاعات دیگر قابل رمزگشایی نیستند. این کلیدها را باید دائمی کنید: «غیرمعتبر شدن کوکی‌های برنامه‌های ASP.NET Core هاست شده‌ی در IIS پس از ری‌استارت آن»
- ممکن است کلید رمزنگاری اطلاعات در این بین تغییر کرده‌است که اطلاعات دیگر قابل رمزگشایی نیستند. این کلیدها را باید دائمی کنید: «غیرمعتبر شدن کوکی‌های برنامه‌های ASP.NET Core هاست شده‌ی در IIS پس از ری‌استارت آن»
در Core 2 و identity 2 دیگر نمیشود از این حالت ارث بری کرد و فقط نوع کلید قابل مشخص شدن هست. برای این حالت چگونه ارتباط‌ها و ... رو تعریف کنیم جهت بروزرسانی به Core 2 ؟ ایا رابطه‌ها باید به صراحت ذکر بشود؟
public class User : IdentityUser<int, UserClaim, UserRole, UserLogin>
آیا طراحی چندین ViewModel برای یک کلاس لایه Domain اشکالی دارد؟مثلا یک
ViewModel بدون ذکر کلیدهای خارجی برای اکشن هایی که فقط جهت نمایش
اطلاعات هستند و طراحی یک ViewModel مجزا بهمراه اطلاعات کلید خارجی برای اکشن هایی که مربوط به
ویرایش اطلاعات هستند
- موجودیت‌های مشترک بین افزونه‌ها را در یک پروژه‌ی مجزا قرار دهید؛ مانند: CommonEntities
- از این پروژه‌ی مشترک، ارجاعی را به افزونه‌های مورد نظر اضافه کنید.
پروژه‌ی جاری جهت افزودن کلید خارجی به کاربران مشترک بین تمام افزونه‌ها به روز شد، با این تغییرات و با این خروجی (که در آن در هر دو افزونه‌ی تعریف شده، ارجاعی به کلاس User مشترک هست):
- از این پروژه‌ی مشترک، ارجاعی را به افزونه‌های مورد نظر اضافه کنید.
پروژه‌ی جاری جهت افزودن کلید خارجی به کاربران مشترک بین تمام افزونه‌ها به روز شد، با این تغییرات و با این خروجی (که در آن در هر دو افزونه‌ی تعریف شده، ارجاعی به کلاس User مشترک هست):
