www.dntips.ir
مطالب ۳۶۹۴
نویسندگان ۲۷۶
گروه‌های مطالب ۱۰۲۴
نقشه‌های راه ۱۱۹
دوره‌ها ۱۴
اشتراک‌ها ۱۷۹۱۴
عنوان:

‫سفارشی سازی ASP.NET Core Identity - قسمت اول - موجودیت‌های پایه و DbContext برنامه


نویسنده: وحید نصیری
تاریخ: ۱۳۹۵/۱۱/۱۰ ۱۱:۲۵
آدرس: www.dntips.ir
با به پایان رسیدن مرحله‌ی توسعه‌ی ASP.NET Identity 2.x مخصوص نگارش‌های ASP.NETایی که از Full .NET Framework استفاده می‌کنند، نگارش جدید آن صرفا بر پایه‌ی ASP.NET Core تهیه شده‌است و در طی یک سری، نحوه‌ی سفارشی سازی تقریبا تمام اجزای آن‌را بررسی خواهیم کرد. جهت سهولت پیگیری این سری، پروژه‌ی کامل سفارشی سازی شده‌ی ASP.NET Core Identity را از مخزن کد DNT Identity می‌توانید دریافت کنید.


پیشنیازهای اجرای پروژه‌ی DNT Identity

 - ابتدا نیاز است حداقل ASP.NET Core Identity 1.1 را نصب کرده باشید.
 - همچنین بانک اطلاعاتی پایه‌ی آن که به صورت خودکار در اولین بار اجرای برنامه تشکیل می‌شود، مبتنی بر LocalDB است. بنابراین اگر قصد تغییری را در تنظیمات Context آن ندارید، بهتر است LocalDB را نیز بر روی سیستم نصب کنید. هرچند با تغییر تنظیم ActiveDatabase به SqlServer در فایل appsettings.json، برنامه به صورت خودکار از نگارش کامل SqlServer استفاده خواهد کرد. رشته‌ی اتصالی آن نیز در مدخل ConnectionStrings فایل appsettings.json ذکر شده‌است و قابل تغییر است. برای شروع به کار، نیازی به اجرای مراحل Migrations را نیز ندارید و همینقدر که برنامه را اجرا کنید، بانک اطلاعاتی آن نیز تشکیل خواهد شد.
 - کاربر پیش فرض Admin سیستم و کلمه‌ی عبور آن از مدخل AdminUserSeed فایل appsettings.json خوانده می‌شوند.
 - تنظیمات ایمیل پیش فرض برنامه به استفاده‌ی از PickupFolder در مدخل Smtp فایل appsettings.json تنظیم شده‌است. بنابراین تمام ایمیل‌های برنامه را جهت آزمایش محلی می‌توانید در مسیر PickupFolder آن یا همان c:\smtppickup مشاهده کنید. محتوای این ایمیل‌ها را نیز توسط مرورگر (drag&drop بر روی یک tab جدید) و یا برنامه‌ی Outlook می‌توان مشاهده کرد.


سفارشی سازی کلید اصلی موجودیت‌های ASP.NET Core Identity

ASP.NET Core Identity به همراه دو سری موجودیت است. یک سری ساده‌ی آن که از یک string به عنوان نوع کلید اصلی استفاده می‌کنند و سری دوم، حالت جنریک که در آن می‌توان نوع کلید اصلی را به صورت صریحی قید کرد و تغییر داد. در اینجا نیز قصد داریم از حالت جنریک استفاده کرده و نوع کلید اصلی جداول را تغییر دهیم. تمام این موجودیت‌های تغییر یافته را در پوشه‌ی src\ASPNETCoreIdentitySample.Entities\Identity نیز می‌توانید مشاهده کنید و شامل موارد ذیل هستند:

جدول نقش‌های سیستم 
    public class Role : IdentityRole<int, UserRole, RoleClaim>, IAuditableEntity
    {
        public Role()
        {
        }

        public Role(string name)
            : this()
        {
            Name = name;
        }

        public Role(string name, string description)
            : this(name)
        {
            Description = description;
        }

        public string Description { get; set; }
    }
کار با ارث بری از نگارش جنریک کلاس IdentityRole شروع می‌شود. این کلاس پایه، حاوی تعاریف اصلی فیلدهای جدول نقش‌های سیستم است که اولین آرگومان جنریک آن، نوع کلید اصلی جدول مرتبط را نیز مشخص می‌کند و در اینجا به int تنظیم شده‌است. همچنین یک اینترفیس جدید IAuditableEntity را نیز در انتهای این تعریف‌ها مشاهده می‌کنید. در مورد این اینترفیس و Shadow properties متناظر با آن، در ادامه‌ی بحث با سفارشی سازی DbContext برنامه بیشتر توضیح داده خواهد شد.


در اولین بار اجرای برنامه، نقش Admin در این جدول ثبت خواهد شد.

جدول کاربران منتسب به نقش‌ها 
    public class UserRole : IdentityUserRole<int>, IAuditableEntity
    {
        public virtual User User { get; set; }

        public virtual Role Role { get; set; }
    }
کلاس پایه‌ی جدول کاربران منتسب به نقش‌ها، کلاس جنریک IdentityUserRole است که در اینجا با تغییر آرگومان جنریک آن به int، نوع فیلدهای UserId و RoleId آن به int تنظیم می‌شوند. در کلاس سفارشی سازی شده‌ی فوق، دو خاصیت اضافه‌تر User و Role نیز را مشاهده می‌کنید. مزیت تعریف آن‌ها، دسترسی ساده‌تر به اطلاعات کاربران و نقش‌ها توسط EF Core است.


در اولین بار اجرای برنامه، کاربر شماره 1 یا همان Admin به نقش شماره 1 یا همان Admin، انتساب داده می‌شود.


جدول جدید  IdentityRoleClaim سیستم 
public class RoleClaim : IdentityRoleClaim<int>, IAuditableEntity
{
   public virtual Role Role { get; set; }
}
در ASP.NET Core Identity، جدول جدیدی به نام RoleClaim نیز اضافه شده‌است. در این سری از آن برای پیاده سازی سطوح دسترسی پویای به صفحات استفاده خواهیم کرد. ابتدا یک سری نقش ثابت در جدول Roles ثبت خواهند شد. سپس تعدادی کاربر به هر نقش نسبت داده می‌شوند. اکنون می‌توان به هر نقش نیز تعدادی Claim را انتساب داد. برای مثال یک Claim سفارشی که شامل ID سفارشی area:controller:action باشد. به این ترتیب و با بررسی سفارشی آن می‌توان سطوح دسترسی پویا را نیز پیاده سازی کرد و مزیت آن این است که تمام این Claims به صورت خودکار به کوکی شخص نیز اضافه شده و دسترسی به اطلاعات آن بسیار سریع است و نیازی به مراجعه‌ی به بانک اطلاعاتی را ندارد.

جدول UserClaim سیستم 
public class UserClaim : IdentityUserClaim<int>, IAuditableEntity
{
   public virtual User User { get; set; }
}
می‌توان به هر کاربر یک سری Claim مخصوص را نیز انتساب داد. برای مثال مسیر عکس ذخیره شده‌ی او در سرور، چه موردی است و این اطلاعات به صورت خودکار به کوکی او نیز توسط ASP.NET Core Identity اضافه می‌شوند. البته ما در این سری روش دیگری را برای سفارشی سازی Claims عمومی کاربران بکار خواهیم گرفت (با سفارشی سازی کلاس ApplicationClaimsPrincipalFactory آن).

جداول توکن و لاگین‌های کاربران 
public class UserToken : IdentityUserToken<int>, IAuditableEntity
{
   public virtual User User { get; set; }
}

public class UserLogin : IdentityUserLogin<int>, IAuditableEntity
{
   public virtual User User { get; set; }
}
دراینجا نیز نحوه‌ی سفارشی سازی و تغییر جداول لاگین‌های کاربران و توکن‌های مرتبط با آن‌ها را مشاهده می‌کنید. این جداول بیشتر جهت دسترسی به حالت‌هایی مانند لاگین با حساب کاربری جی‌میل مورد استفاده قرار می‌گیرند و کاربرد پیش فرضی ندارند (اگر از تامین کننده‌های لاگین خارجی نمی‌خواهید استفاده کنید).

جدول کاربران سیستم 
    public class User : IdentityUser<int, UserClaim, UserRole, UserLogin>, IAuditableEntity
    {
        public User()
        {
            UserUsedPasswords = new HashSet<UserUsedPassword>();
            UserTokens = new HashSet<UserToken>();
        }

        [StringLength(450)]
        public string FirstName { get; set; }

        [StringLength(450)]
        public string LastName { get; set; }

        [NotMapped]
        public string DisplayName
        {
            get
            {
                var displayName = $"{FirstName} {LastName}";
                return string.IsNullOrWhiteSpace(displayName) ? UserName : displayName;
            }
        }

        [StringLength(450)]
        public string PhotoFileName { get; set; }

        public DateTimeOffset? BirthDate { get; set; }

        public DateTimeOffset? CreatedDateTime { get; set; }

        public DateTimeOffset? LastVisitDateTime { get; set; }

        public bool IsEmailPublic { get; set; }

        public string Location { set; get; }

        public bool IsActive { get; set; } = true;

        public virtual ICollection<UserUsedPassword> UserUsedPasswords { get; set; }

        public virtual ICollection<UserToken> UserTokens { get; set; }
    }

    public class UserUsedPassword : IAuditableEntity
    {
        public int Id { get; set; }

        public string HashedPassword { get; set; }

        public virtual User User { get; set; }
        public int UserId { get; set; }
    }
در اینجا علاوه بر نحوه‌ی تغییر نوع کلید اصلی جدول کاربران سیستم، نحوه‌ی افزودن خواص اضافه‌تری مانند نام، تاریخ تولد، مکان، تصویر و غیره را نیز مشاهده می‌کنید. به علاوه جدولی نیز جهت ثبت سابقه‌ی کلمات عبور هش شده‌ی کاربران نیز تدارک دیده شده‌است تا کاربران نتوانند از 5 کلمه‌ی عبور اخیر خود (تنظیم NotAllowedPreviouslyUsedPasswords در فایل appsettings.json) استفاده کنند.
فیلد IsActive نیز از این جهت اضافه شده‌است تا بجای حذف فیزیکی یک کاربر، بتوان اکانت او را غیرفعال کرد.


تعریف Shadow properties ثبت تغییرات رکوردها

در #C ارث‌بری چندگانه‌ی کلاس‌ها ممنوع است؛ مگر اینکه از اینترفیس‌ها استفاده شود. برای مثال IdentityUser یک کلاس است و در اینجا دیگر نمی‌توان کلاس دومی را به نام BaseEntity جهت اعمال خواص اضافه‌تری اعمال کرد. به همین جهت است که اعمال اینترفیس خالی IAuditableEntity را در اینجا مشاهده می‌کنید. این اینترفیس کار علامت‌گذاری کلاس‌هایی را انجام می‌دهد که قصد داریم به آن‌ها به صورت خودکار، خواصی مانند تاریخ ثبت رکورد، تاریخ ویرایش آن و غیره را اعمال کنیم.
در Context برنامه، به اطلاعات src\ASPNETCoreIdentitySample.Entities\AuditableEntity مراجعه شده و متد AddAuditableShadowProperties بر روی تمام کلاس‌هایی از نوع IAuditableEntity اعمال می‌شود. این متد خواص مدنظر ما را مانند ModifiedDateTime به صورت Shadow properties به موجودیت‌های علامت‌گذاری شده اضافه می‌کند.
همچنین متد SetAuditableEntityPropertyValues، کار مقدار دهی خودکار این خواص را انجام خواهد داد. بنابراین دیگر نیازی نیست در برنامه برای مثال IP شخص ثبت کننده یا ویرایش کننده را به صورت دستی مقدار دهی کرد. هم تعریف و هم مقدار دهی آن توسط Change tracker سیستم به صورت خودکار انجام خواهند شد.


تاثیر افزودن Shadow properties را بر روی کلاس نقش‌های سیستم، در تصویر فوق ملاحظه می‌کنید. خواصی که به صورت معمول در کلاس‌های برنامه ظاهر نمی‌شوند و صرفا هدف بازبینی سیستم را برآورده می‌کنند و مدیریت آن‌ها نیز در اینجا کاملا خودکار است.


سفارشی سازی DbContext برنامه

نحوه‌ی سفارشی سازی DbContext برنامه را در پوشه‌ی src\ASPNETCoreIdentitySample.DataLayer\Context و src\ASPNETCoreIdentitySample.DataLayer\Mappings ملاحظه می‌کنید. پوشه‌ی Context حاوی کلاس ApplicationDbContextBase است که تمام سفارشی سازی‌های لازم بر روی آن انجام شده‌است؛ شامل:
 - تغییر نوع کلید اصلی موجودیت‌ها به همراه معرفی موجودیت‌های تغییر یافته:
 public abstract class ApplicationDbContextBase :
  IdentityDbContext<User, Role, int, UserClaim, UserRole, UserLogin, RoleClaim, UserToken>,
  IUnitOfWork
ما در ابتدای بحث، برای مثال کلاس Role را سفارشی سازی کردیم. اما برنامه از وجود آن بی‌اطلاع است. با ارث بری از IdentityDbContext و ذکر این کلاس‌های سفارشی به همراه نوع int کلید اصلی مورد استفاده، کار معرفی موجودیت‌های سفارشی سازی شده انجام می‌شود.

 - اعمال متد BeforeSaveTriggers به تمام نگارش‌های مختلف SaveChanges
protected void BeforeSaveTriggers()
{
  ValidateEntities();
  SetShadowProperties();
  this.ApplyCorrectYeKe();
}
در اینجا پیش از ذخیره‌ی اطلاعات، ابتدا موجودیت‌ها اعتبارسنجی می‌شوند. سپس مقادیر Shadow properties تنظیم شده و دست آخر، ی و ک فارسی نیز به اطلاعات ثبت شده، جهت یک دست سازی اطلاعات سیستم، اعمال می‌شوند.

- انتخاب نوع بانک اطلاعاتی مورد استفاده در متد OnConfiguring
در اینجا است که خاصیت ActiveDatabase تنظیم شده‌ی در فایل appsettings.json خوانده شده و اعمال می‌شوند. تعریف متد GetDbConnectionString را در کلاس SiteSettingsExtesnsions مشاهده می‌کنید. کار آن استفاده‌ی از بانک اطلاعاتی درون حافظه‌ای، جهت انجام آزمون‌های واحد و یا استفاده‌ی از LocalDb و یا نگارش کامل SQL Server می‌باشد. اگر علاقمند بودید تا بانک اطلاعاتی دیگری (مثلا SQLite) را نیز اضافه کنید، ابتدا enum ایی به نام ActiveDatabase را تغییر داده و سپس متد GetDbConnectionString و متد OnConfiguring را جهت درج اطلاعات این بانک اطلاعاتی جدید، اصلاح کنید.

پس از تعریف این DbContext پایه‌ی سفارشی سازی شده، کلاس جدید ApplicationDbContext را مشاهده می‌کنید. این کلاس ‍Context ایی است که در برنامه از آن استفاده می‌شود و از کلاس پایه ApplicationDbContextBase مشتق شده‌است:
 public class ApplicationDbContext : ApplicationDbContextBase
تعاریف موجودیت‌های جدید خود را به این کلاس اضافه کنید.
تنظیمات mapping آن‌ها نیز به متد OnModelCreating این کلاس اضافه خواهند شد. فقط نحوه‌ی استفاده‌ی از آن را به‌خاطر داشته باشید:
        protected override void OnModelCreating(ModelBuilder builder)
        {
            // it should be placed here, otherwise it will rewrite the following settings!
            base.OnModelCreating(builder);

            // Adds all of the ASP.NET Core Identity related mappings at once.
            builder.AddCustomIdentityMappings(SiteSettings.Value);

            // Custom application mappings


            // This should be placed here, at the end.
            builder.AddAuditableShadowProperties();
        }
ابتدا باید base.OnModelCreating را ذکر کنید. در غیراینصورت تمام سفارشی سازی‌های شما بازنویسی می‌شوند.
سپس متد AddCustomIdentityMappings ذکر شده‌است. این متد اطلاعات src\ASPNETCoreIdentitySample.DataLayer\Mappings را به صورت خودکار و یکجا اضافه می‌کند که در آن برای مثال نام جداول پیش فرض Identity سفارشی سازی شده‌اند.


در آخر باید AddAuditableShadowProperties فراخوانی شود تا خواص سایه‌ای که پیشتر در مورد آن‌ها بحث شد، به سیستم به صورت خودکار اضافه شوند.
تمام نگاشت‌های سفارشی شما باید در این میان و در قسمت «Custom application mappings» درج شوند.

در قسمت بعدی، نحوه‌ی سفارشی سازی سرویس‌های پایه‌ی Identity را بررسی خواهیم کرد. بدون این سفارشی سازی و اطلاعات رسانی به سرویس‌های پایه که از چه موجودیت‌های جدید سفارشی سازی شده‌ایی در حال استفاده هستیم، کار Migrations انجام نخواهد شد.


کدهای کامل این سری را در مخزن کد DNT Identity می‌توانید ملاحظه کنید.
مطالب مشابه

نظرات

  • حامد فتحی در ۱۳۹۵/۱۱/۱۰ ۱۵:۴۲
    با سلام؛ دو تا سوال نسبت به مقاله فوق برای من پیش اومده 
    1) اول اینکه امکان جایگزین کردن Dapper به جای EntityFramework وجود داره یا خیر ؟
    2) آیا استفاده از پایگاه داده‌های NoSQL مثل MongoDB به جای SqlServer برای سناریو فوق فکر خوبی است ؟ اگر بله آیا پیاده سازی آن مبتنی بر Identity ممکن است یا خیر ؟
    البته یک سوال کلی هم دارم که ممکن به این بحث مربوط نشه، کلا برای مواردی مثل ثبت لاگ، ثبت جزییات خطاها، اطلاعات کاربران،  ورود و خروج‌ها بهتر نیست از NoSQL‌ها استفاده کنیم ؟
    • وحید نصیری در ۱۳۹۵/۱۱/۱۰ ۱۷:۳۰
      - « Identity.Dapper »
      - « AspNetCore.Identity.MongoDB »
      - این مورد بیشتر به طراحی کل سیستم بر می‌گردد؛ چون اجزای مختلف یک سیستم قرار است هماهنگ با اطلاعات کاربران و سطوح دسترسی آن‌ها کار کنند. بنابراین بهتر است زیرساخت سیستم یکپارچه باشد (اگر NoSQL انتخاب شد، کل سیستم NoSQL طراحی شود) تا مشکلات نگهداری، توسعه و همچنین کاهش کارآیی آن با سوئیچ بین بانک‌های اطلاعاتی مختلف وجود نداشته باشد.
      به علاوه با تعویض این موارد در آینده همیشه یک قدم عقب‌تر از تیم ASP.NET Core Identity خواهید بود. همچنین بهینه سازی‌هایی که در اینجا صورت گرفته و طراحی آن، عمیقا با دید به EF Core انجام شده‌است (و اساس طراحی آن هم «رابطه‌ای» است). EF Core وابستگی به SQL Server ندارد و تعداد پروایدرهای رسمی بانک‌های اطلاعاتی مختلف آن قابل توجه است (SQL Server, SQLite, PostgreSQL, MySQL, SQL CE, InMemory) و سیستمی که با یک ORM کار می‌کند، همواره این مزیت قابل تعویض بودن بانک اطلاعاتی برنامه را خواهد داشت.
      استفاده‌ی از Dapper و SQL نویسی مستقیم، تنها با یک اشتباه کوچک و فراموشی نکته‌ای، به حملات تزریق اس‌کیوال ختم خواهد شد و این مورد مساله‌ای است که حداقل با EF Core وجود ندارد و فوق العاده مهم است.
  • وحید نصیری در ۱۳۹۵/۱۲/۲۹ ۱۲:۲۶
    جهت اطلاع
    این پروژه به VS 2017 ارتقاء داده شد؛ به همراه رفع مشکل migrations آن پس از تغییرات جدید.
  • کیانوش درتاج در ۱۳۹۶/۰۴/۲۴ ۱۳:۴۳
    مشکلی که من دارم اینه که پکیج‌ها بعضیشون نصب نشدن و بعضیهاشون هم علامت زرد روشون هست . باید چیکارشون کنم ؟

     1 - Microsoft.AspNetCore.Mvc.ViewFeatures
    2 - Microsoft.AspNetCore.Mvc.Razor 
    3- CoreCompat.System.Drawing
    4 - cloudscribe.Web.Pagination
    • وحید نصیری در ۱۳۹۶/۰۴/۲۴ ۱۴:۵۸
      این مورد عموما به معنای استفاده نکردن از آخرین SDKها و ابزارهای موجود است.
      - یا باید از VS 2017 استفاده کنید به همراه نصب وابستگی‌های NET Core. و آخرین به روز رسانی‌های آن (اجباری)
      - یا از روش مطرح شده‌ی برای VSCode استفاده کنید.
      dotnet restore
dotnet run
  • کیانوش درتاج در ۱۳۹۶/۰۴/۲۴ ۱۶:۵۲
    دلیل اینکه این کد‌های رو به این شکل نوشتید چیه ؟
    public static readonly Func<object, string> EFPropertyCreatedByIp =
                                entity => EF.Property<string>(entity, CreatedByIp);
        public static readonly string CreatedByIp = nameof(CreatedByIp);
    این قسمت‌ها رو اگر ممکنه یه توضیحی بدید چرا ین شکلی نوشتید . مثلا چرا برای IP به بار EFPropertyCreatedByIp  و یه بار هم اینو CreatedByIp  نوشتید ؟

    این nameof کاربردش چیه ؟
  • مهدی سیل سپور در ۱۳۹۶/۰۴/۲۸ ۱۲:۱۷
    سلام.امکان داره یه مثال در مورد نحوه استفاده از قطعه کد زیر که مربوط به خواص سایه ای میشه بزنید.
    public static readonly Func<object, DateTimeOffset?> EFPropertyCreatedDateTime =
                                                  entity => EF.Property<DateTimeOffset?>(entity, CreatedDateTime);
    به عنوان مثال سعی کردم به شکل زیر از این قطعه کد استفاده کنم ولی با پیغام
    "The EF.Property<T> method may only be used within LINQ queries"
    سیستم متوقف میشه.
    var persons = context.Persons
                                  .Where(x => AuditableShadowProperties.EFPropertyCreatedDateTime(x) == DateTimeOffset.UtcNow)
                                  .ToList();

    • وحید نصیری در ۱۳۹۶/۰۴/۲۸ ۱۲:۲۹
      - یک نمونه استفاده‌ی‌از آن خاصیت public، در متد GetLastUserPasswordChangeDateAsync هست که از GetShadowPropertyValue استفاده می‌کند.
      - برای سایر حالات از نکات مطرح شده‌ی در مطلب خواص سایه‌ای یا Shadow properties استفاده کنید و بجای ذکر رشته‌ها، می‌توان از خواص public static readonly string این کلاس در متد EF.Property استفاده کرد تا Refactoring friendly شود (هدف اصلی این خواص عمومی).
      var items = context.Persons
             .Where(x => EF.Property<DateTimeOffset?>(x, AuditableShadowProperties.CreatedDateTime) <= DateTimeOffset.UtcNow).ToList();
  • کیانوش درتاج در ۱۳۹۶/۰۵/۱۴ ۱۸:۲۶
    متاسفانه موقعی‌که میخوام Migration رو فعال کنم و دیتابیس رو بسازم این خطا رو میده. دلیل این خطا چیه؟ چطور باید حل بشه؟

  • میلاد درویشی در ۱۳۹۶/۰۵/۲۶ ۱۷:۵۵
    در Core 2 و identity 2 دیگر نمیشود از این حالت 
    public class User : IdentityUser<int, UserClaim, UserRole, UserLogin>
    ارث بری کرد و فقط نوع کلید قابل مشخص شدن هست. برای این حالت چگونه ارتباط‌ها و ... رو تعریف کنیم جهت بروزرسانی به Core 2 ؟ ایا رابطه‌ها باید به صراحت ذکر بشود؟
    • وحید نصیری در ۱۳۹۶/۰۵/۲۶ ۱۸:۲۵
      در حال به روز رسانی پروژه‌ی فعلی به ASP.NET Core 2.0 هستم. حجم تغییرات آن خیلی زیاد است. کمی صبر کنید. به زودی ...
    • وحید نصیری در ۱۳۹۶/۰۵/۲۷ ۱۸:۴۷
      جهت اطلاع
      پروژه‌ی DNTIdentity به ASP.NET Core 2.0 ارتقاء داده شد.
      - مشاهده‌ی لیست کامل تغییرات

      برای اجرای آن فقط کافی است
      - ابتدا SDK جدید را نصب کنید.
      - سپس به پوشه‌ی DataLayer مراجعه کرده و ابتدا دستور dotnet restore را صادر کنید. بعد از آن دو فایل cmd موجود در آن‌را اجرا کنید. فایل اول مهاجرت‌ها را تولید می‌کند و فایل دوم، آن‌ها را به بانک اطلاعاتی از نوع LocalDB اعمال خواهد کرد. بانک اطلاعاتی تولید شده را در پوشه‌ی wwwroot/App_Data می‌توانید مشاهده کنید.
      - در آخر به پوشه‌ی اصلی برنامه مراجعه کرده و دو فایل bat موجود در آن‌را اجرا کنید. اولی وابستگی‌ها را بازیابی می‌کند و دومی برنامه را کامپایل کرده و سپس بر روی پورت 5000 ارائه می‌دهد که بلافاصله در مرورگر قابل مشاهده خواهد بود.
      برای اجرای این مراحل نیاز به IDE خاصی ندارید. همینقدر که SDK جدید را نصب کرده باشید، کافی است. 
  • محمد دلیری در ۱۳۹۶/۰۷/۲۱ ۱۷:۲۰
    در پروژه‌های Single Page Application برای اعتبار سنجی بهتر است Asp.net core Identity استفاده کنیم یا از اعتبارسنجی‌های بر طبق jwt؟ آیا می‌شود گفت اعتبار سنجی‌های بر طبق jwt  خیلی سریع‌تر و قدرتمند‌تر از Asp.net core Identity  هستنند؟ به نظر میرسه امکان سفارشی کردن jwt  خیلی بهتر از Asp.net core Identity قابل انجام هست.
    • وحید نصیری در ۱۳۹۶/۰۷/۲۱ ۱۸:۵۳
      فلسفه‌ی وجودی «اعتبارسنجی مبتنی بر کوکی‌ها در ASP.NET Core 2.0 » و همچنین «اعتبارسنجی مبتنی بر JWT در ASP.NET Core 2.0 » فراهم آوردن زیر ساختی برای طراحی یک سیستم مستقل اعتبارسنجی، شبیه به ASP.NET Core Identity هست. چون سیستم Identity به صورت پیش‌فرض از همین زیرساخت مبتنی بر کوکی‌ها استفاده می‌کند. برای مثال اگر می‌خواهید با JWT کار کنید و مدیریت کاربران را توسط Idnetity انجام دهید، اینکار برای مثال توسط متد signInManager.PasswordSignInAsync آن قابل انجام نیست؛ چون پس از پایان کار لاگین، یک کوکی را تنظیم می‌کند و نه یک توکن‌را.
  • میلاد درویشی در ۱۳۹۶/۰۹/۰۶ ۱۸:۲۱
    آیا در پروژه هایی که SSL را دارند آیا تنظیماتی باید برای identity و مثال جاری انجام شود یا خیر؟
    • وحید نصیری در ۱۳۹۶/۰۹/۰۶ ۱۸:۲۵
      فقط بحث ثبت و پردازش کوکی‌های آن (Cookie.SecurePolicy) در اینجا حائز اهمیت است که تنظیم شده‌است.
  • درتاج در ۱۳۹۶/۱۱/۰۶ ۱۰:۱۸
    سلام؛ در ApplicationDbContext این خطا رو به من میده. برای رفع این خطا باید چکار کنم؟



    اینم اون تکه کد هستش :
    public class ApplicationDbContext :
       IdentityDbContext<User, Role, int, UserClaim, UserRole, UserLogin, RoleClaim, UserToken>, IUnitOfWork
    {
        // we can't use constructor injection anymore, because we are using the `AddDbContextPool<>`
        public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
            : base(options) { }
    • وحید نصیری در ۱۳۹۶/۱۱/۰۶ ۱۱:۱۶
      یعنی امضای موجودیت‌های تعریف شده‌ی در برنامه‌ی شما مشکل دارند. امضای تک تک آن‌ها را با آخرین نمونه‌های ارسالی تطابق دهید (این امضاها از نگارش 1 به 2، کاملا تغییر کرده‌اند و آخرین تغییرات آن‌ها در مخزن کد، لحاظ شده‌اند).
  • وحید نصیری در ۱۳۹۷/۰۲/۰۳ ۱۴:۳۷
    یک نکته‌ی تکمیلی
    چگونه این پروژه را تبدیل به یک قالب پروژه‌ی جدید کنیم: «امکان ساخت قالب برای پروژه‌های NET Core.»    
  • وحید نصیری در ۱۳۹۷/۰۲/۱۸ ۲۰:۱۵
    جهت اطلاع
    پروژه‌ی DNTIdentity به ASP.NET Core 2.1 ارتقاء داده شد.
    - مشاهده‌ی لیست کامل تغییرات 

    برای اجرای آن فقط کافی است:
    - ابتدا SDK جدید را نصب کنید.
    - سپس مجوز SSL آن‌را تبدیل به مجوز امن و قابل اطمینان کنید.
    - در ادامه به پوشه‌ی DataLayer مراجعه کرده و ابتدا دستور dotnet restore را صادر کنید. بعد از آن دو فایل cmd موجود در آن‌را اجرا کنید. فایل اول مهاجرت‌ها را تولید می‌کند و فایل دوم، آن‌ها را به بانک اطلاعاتی از نوع LocalDB اعمال خواهد کرد. بانک اطلاعاتی تولید شده را در پوشه‌ی wwwroot/App_Data می‌توانید مشاهده کنید.
    - در آخر به پوشه‌ی اصلی برنامه مراجعه کرده و دو فایل bat موجود در آن‌را اجرا کنید. اولی وابستگی‌ها را بازیابی می‌کند و دومی برنامه را کامپایل کرده و سپس بر روی پورت SSL 5001 ارائه می‌دهد که بلافاصله در مرورگر قابل مشاهده خواهد بود.

    برای اجرای این مراحل نیاز به IDE خاصی ندارید. همینقدر که SDK جدید را نصب کرده باشید، کافی است.  
  • کوشککی در ۱۳۹۷/۰۳/۲۴ ۱۶:۴۵
     NormalizedName  چه کاربردی دارد؟
  • کیان سبزی در ۱۳۹۷/۰۴/۰۴ ۲۰:۱۶
    سوال مهمی که در ذهن بنده هستش اینه که میشه JWT رو با این روش ادغام کرد(اضافه کرد) برای احراز هویت برنامه‌های موبایل که از وب سرویس‌های اپلیکیشن استفاده می‌کنند.
     و یه سوال دیگه این جدول UserToken در IdentityCore چه کاربردی داره؟
    • وحید نصیری در ۱۳۹۷/۰۴/۰۴ ۲۰:۴۸
      - نکات مطلب «اعتبارسنجی مبتنی بر JWT در ASP.NET Core 2.0 بدون استفاده از سیستم Identity» را با این پروژه یکی کنید (قسمت تولید توکن و قسمت تولید Claims آن).
      ضمنا در ASP.NET Core، بخش MVC و Web API یکی هستند. یعنی زمانیکه کاربر لاگین کرد، در یک کنترلر هم می‌توان متدهای Web API را در اختیار او قرار داد و هم MVC را. بنابراین الزامی به استفاده‌ی از JWT برای کار با Web API آن وجود ندارد. JWT فقط یک روش اعتبارسنجی دیگر است. کلاینت‌ها در حین کار با JWT باید اکسس‌توکن را به سمت سرور ارسال کنند؛ در حین کار با کوکی‌ها، کوکی تولید شده‌ی پس از لاگین را. مابقی آن یکی است. یعنی این پروژه الزاما نیازی به تلفیق با JWT ندارد. کوکی‌ها، هم در برنامه‌های MVC و هم در کلاینت‌های غیر MVC قابل استفاده هستند.
      - مربوط است به استفاده از تامین کننده‌های لاگین خارجی مانند گوگل، توئیتر و غیره.
      • افشاری م در ۱۳۹۷/۰۴/۰۵ ۲۳:۵۶
        یعنی در یک برنامه ای که اندرویدی یا  IOS هست می‌توان کاملا با cookie کارکرد ؟ منظورم به راحتیه کار با jwt و تمام امکانات رو داشت ؟
        چون من می‌خواهم از این پروژه بعنوان Web API سرویس استفاده کنم و توسط IOS و Android با مدل Cookie از تمام امکانات Identiy استفاده کنم ؟
        • وحید نصیری در ۱۳۹۷/۰۴/۰۶ ۰:۵۵
          + یک نمونه مثال از یک برنامه‌ی Angular که از روش مبتنی بر کوکی ASP.NET Core برای اعتبارسنجی استفاده می‌کند (بجای استفاده‌ی از JWT).
          • امیرفرد در ۱۳۹۷/۰۵/۱۷ ۸:۴۴
            با سلام؛ در پروژه‌های غیر وبی مثل اندروید پس از اینکه لاگین توسط HttpClient صورت گرفت چطور می‌توان اطلاعات داخل کوکی را بدست آورد؟ به طور مثال بتوانیم نام کاربر را استخراج کرد؟  یعنی ما اطلاعاتی را در کوکی ذخیره کنیم و پس از لاگین بتوانیم آن اطلاعات را دریافت کنیم
            • وحید نصیری در ۱۳۹۷/۰۵/۱۷ ۸:۵۳
              نمی‌توانید. این کوکی رمزنگاری شده‌است. روش انجام اینکار در اینجا استفاده از متدهایی مانند GetUserInfo پس از لاگین موفق است؛ برای دریافت اطلاعات User Claims.
  • کیان سبزی در ۱۳۹۷/۰۴/۰۸ ۲۳:۴۱
    با سلام. هنگام اضافه کردن پراپرتی جدید(از نوع string و به نام SerialNumber) به موجودیت User سفارشی سازی شده شما با ارور زیر در هنگام اجرا مواجه شدم :

    AggregateException: One or more errors occurred. (Invalid column name 'SerialNumber'.)

    System.Threading.Tasks.Task<TResult>.GetResultCore(bool waitCompletionNotification) 


    • وحید نصیری در ۱۳۹۷/۰۴/۰۸ ۲۳:۴۸
      مطلب «شروع به کار با EF Core 1.0 - قسمت 2 - به روز رسانی ساختار بانک اطلاعاتی» را مطالعه کنید. صرف تعریف یک خاصیت که کافی نیست. «Invalid column name» یعنی این ستون در بانک اطلاعاتی وجود خارجی ندارد. بنابراین مرحله‌ی بعد، اجرای دستی مهاجرت‌ها است که در اینجا همان اجرای فایل _01-add_migrations.cmd است.
      • کیان سبزی در ۱۳۹۷/۰۴/۰۹ ۹:۲۸
        ممنون از شما. با استفاده از خط فرمان و دستور dotnet build مشکل رو در پروژه پیدا کردم و بعد از برطرف کردن دستور dotnet ef migration با موفقیت اجرا شد و پراپرتی مورد نظر به جدول مربوطه نگاشت شد.
  • امیرفرد در ۱۳۹۷/۰۵/۰۲ ۱۱:۲۰
    با سلام. یک سوال در رابطه با جدول UserToken داشتم. من برای ذخیره کردن توکن برای کاربران میخوام از این جدول استفاده کنم و فیلدهای  LoginProvider و  Name   هم به عنوان کلید اصلی در نظر گرفته شده است. در هنگام درج رکورد چه مقادیری باید به این دو فیلد بدهم. یا باید جدول دیگه ای برای این کار اضافه کنم؟
    • وحید نصیری در ۱۳۹۷/۰۵/۰۲ ۱۲:۳۳
      قسمتی از بسته‌ی ASP.NET Core Identity مرتبط است به استفاده از تامین کننده‌های «لاگین خارجی» مانند لاگین به سایت توسط اکانت گوگل، توئیتر و غیره. کاربرد جدول UserToken هم به این مورد بر می‌گردد و کاربرد عمومی ندارد.
  • محمد رعیت پیشه در ۱۳۹۷/۱۱/۱۴ ۱۱:۵۱
    این امکان وجود داره که از سیستم Identity معرفی شده در این مطلب در پروژه‌های Multi-Tenant استفاده کرد یا باید سمت IdentityServer رفت؟
    • وحید نصیری در ۱۳۹۷/۱۱/۱۴ ۱۲:۴
      - IdentityServer کاری به مباحث چند مستاجری ندارد. هدف آن، قرار ندادن اطلاعات هویت کاربران و منطق احراز هویت آن‌ها، در تک تک برنامه‌های متفاوت و مختلف یک شرکت است. هدف اصلی آن فراهم آوردن یک سیستم احراز هویت مرکزی برای برنامه‌هایی اساسا متفاوت است.
      - زمانیکه جزئیات روش سفارشی سازی سیستمی در اختیار شما قرار گرفت (مانند این پروژه)، منطق چند مستاجری را خودتان به آن اضافه کنید.
  • محبوبه در ۱۳۹۷/۱۱/۲۱ ۱۱:۱۵
    سلام من برای جدول userrole بصورت زیر استفاده کردم :
      public virtual User User { get; set; }

        public virtual Role Role { get; set; }
    و در جدول user و role :
     public virtual ICollection<UserRole> UserRoles { get; set; } = new HashSet<UserRole>();

    اما در دیتابیس که نگاه میکنم دوتا فیلد جدا بنام user1 و role1 میسازه و زمانیکه بخام از این ارتباطات استفاده کنم اون رو در نظر نمیگیره ؟ممنون میشم بگید مشکل کجاست؟
  • رضا سلیم در ۱۳۹۷/۱۲/۲۸ ۲۲:۵۶
    بعد از اجرای پروژه خطای زیر دریافت می‌شود.دلیل صادر شدن این خطا چیست؟

    • وحید نصیری در ۱۳۹۷/۱۲/۲۹ ۰:۱
      رشته‌ی اتصالی پیش‌فرض این برنامه LocalDB است که نیازی به تعیین نام کاربری و غیره ندارد. مطلب «LocalDB FAQ» را در مورد نصب و به روز رسانی آن پیگیری کنید. اگر این رشته را تغییر دادید و قصد استفاده‌ی از SQL Server کامل را دارید، احتمالا رشته‌ی اتصالی شما از نوع windows authentication است (Integrated Security=true) که نام کاربری یوزر فعلی را که ویژوال استودیوی شما تحت آن اجرا می‌شود، عنوان کرده‌است. این کاربر باید در قسمت accounts/login مربوط به SQL Server دسترسی لازم را به بانک اطلاعاتی که مشخص کرده‌اید، پیدا کند یا ویژوال استودیو را با دسترسی ادمین اجرا کنید.
      • رضا سلیم در ۱۳۹۷/۱۲/۲۹ ۱۱:۴۷
        خطا به دلیل این هست که هنوز بانک اطلاعاتی ایجاد نشده و نمی‌تواند بانک اطلاعاتی رو پیداکنه. آیا راهی هست این بخش بعد از ایجاد بانک اطلاعاتی ثبت شود؟
        • وحید نصیری در ۱۳۹۷/۱۲/۲۹ ۱۳:۲۰
          ایجاد بانک اطلاعاتی به بالاترین سطح ممکن منتقل شد.
  • سهیل سهرابی در ۱۳۹۸/۰۳/۱۵ ۱۲:۴۷
    هنگام اضافه کردن به پروژه جدید به مشکل namespaceهای یکسان برخوردم. بخصوص زمانی که DNTCommon.Web.Core اضافه میکنم چون قبلا در namespaceهای پروژه .System.Drawing را داشته ام الان ارور یکسان بودن namespace رو میده میخواستم راهنمایی کنید چه باید کرد؟
    ارور:
    Error CS0433 The type 'Image' exists in both 'CoreCompat.System.Drawing, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c0a7ed9c2333b592'
 and 'System.Drawing.Common, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
    • وحید نصیری در ۱۳۹۸/۰۳/۱۵ ۱۸:۱۸
      CoreCompat.System.Drawing مربوط به دوران NET Core 1x. بود و در حال حاضر این پروژه وابستگی به آن ندارد (چون System.Drawing.Common توسط خود مایکروسافت ارائه شده). کدهای خودتان را با آخرین کدهای این مجموعه تطابق دهید.
      • سهیل سهرابی در ۱۳۹۸/۰۳/۱۶ ۱:۲۱
        آیا راهی هست تا این وابستگی را نادیده گرفت. منظورم اینه که این دو تا namespace باشه ولی در کدها فقط اونی که نیاز هست بتونم بنویسم؟ بدون اینکه ورژن nugetها رو تغییر بدم یا پروژه ام را تغییر بدم. یعنی در جایی از پروژه از System.Drawing.Common استفاده کنم و در جای دیگر از CoreCompact.System.Drawing
  • سید علیرضا حسینی در ۱۳۹۸/۰۴/۰۲ ۲۰:۱۵
    سلام. امکانش هست این پروژه همراه با Docker به صورت یک مقاله جدا آموزش و توضیح دهید؟
  • کیان سبزی در ۱۳۹۸/۰۵/۰۳ ۸:۴۰
    سلام. بعد از بروز رسانی به نسخه جدید از طریق ریپازیتوری dntIdentity،  پروژه وب اپلیکیشن داخل ویژوال استودیو(load failed) رو نشون میده و اون پروژه رو نمیاره. دات نت اس دی کی رو به ورژن 2.2.301 ارتقا دادم و ویژوال استودیو 2017 رو به ورژن 15.9.14 ارتقا دادم.
    • وحید نصیری در ۱۳۹۸/۰۵/۰۳ ۹:۴۸
      - من از ویژوال استودیو استفاده نمی‌کنم (آخرین نگارشی از آن که روی سیستم من نصب است، نگارش 2015 است). تمام کار این برنامه با VSCode انجام شده و با آن مشکلی نیست. برای کنترل کیفیت برنامه و دسترسی به معادل ReSharper هم می‌توانید از Rider استفاده کنید.
      - مطابق مستندات رسمی خود مایکروسافت، VS 2017 دیگر از SDKهای جدید پشتیبانی نمی‌کند و از این پس نیاز به نصب نگارش 2019 را خواهید داشت (این مورد اجباری است برای کسانیکه می‌خواهند از VS و NET Core. استفاده کنند):
      .NET Core SDK .NET Core Runtime Compatible Visual Studio MSBuild Notes
      2.1.5nn 2.1 2017 15 Installed as part of VS 2017 version 15.9
      2.1.6nn 2.1 2019 16 Installed as part of VS 2019
      2.2.1nn 2.2 2017 15 Installed manually
      2.2.2nn 2.2 2019 16 Installed as part of VS 2019
      3.0.1nn 3.0 (Preview) 2019 16 Installed manually

      Visual Studio 2017 cannot work with .NET Core SDK 2.1.6nn or 2.2.2nn. 

      • کیان سبزی در ۱۳۹۸/۰۵/۰۴ ۱۰:۵۲
        با سپاس فراوان. با پایین آوردن ورژن sdk در فایل global.json به ورژن مورد قبول ویژوال استودیو نصب شده بر روی سیستم(15.9.14) پروژه به راحتی بیلد و اجرا گردید و مشکلات قبلی برطرف گردید. در خصوص استفاده از IDE‌های دیگه معادل visual studio یه سری مزایا و معایب خودشون رو دارن ولی به منظور اون دو مورد که فرمودین کاملا نیاز رو برطرف میکنند(کنترل کیفی و Resharper).
  • سید سجاد هادیان امرئی در ۱۳۹۸/۰۶/۲۴ ۱:۴۴
    باسلام؛ بنده از این سیستم برای طراحی یک سایت فروش استفاده میکنم، سناریو به این شکل می‌باشد که تنها مدیر سیستم میتواند کاربران جدیدی را به وجود بیاورد، بنده به دنبال ملغی کردن استفاده از ایمیل می‌باشم، با وجود حذف خاصیت ایمیل در register veiwmodel  و همچین حذف ستون ایمیل در بانک کاربران باز هم  خطای اعتبار سنجی وارد کردن ایمیل را دریافت میکنم، با دنبال کردن جریان برنامه به تابع base.CreateAsyc توکار می‌رسم که نام کاربری را به صورت آدرس ایمیل مورد بررسی قرار میدهد، حتی با تغییر مقدار return  در تابع IsEmailAddress باز هم با خطا مواجه می‌گردم. خواهش میکنم راهکاری ارائه نمایید که بدون دریافت ایمیل ادمین قادر به افزودن کاربر جدید باشد.
  • سید سجاد هادیان امرئی در ۱۳۹۸/۰۶/۳۰ ۱۲:۱۱
    با سلام؛ در پوشه Scripts ‌های پروژه‌ی جاری سه فایل با نام های jquery.bootstrap-modal-ajax-form ،jquery.bootstrap-modal-alert،jquery.bootstrap-modal-confirm وجود دارد. اما ارجاعی به اسکریپت‌های یاد شده در View ‌های برنامه دیده نمی‌شود.      
  • سید سجاد هادیان امرئی در ۱۳۹۸/۰۶/۳۰ ۱۷:۴۷
    با سلام؛ در View  ایندکس، از کنترلر RolesManager با کلیک بر روی دکمه‌ی ایجاد نقش  جدید، فرم مدال ظاهر نمی‌گردد. ارجاع به اسکریپت‌های مورد نظر ایجاد شده ولی عملا اتفاقی نمی‌افته؟
    • وحید نصیری در ۱۳۹۸/۰۶/۳۰ ۱۸:۱۱
      - لطفا خارج از موضوع و عنوان اصلی، بحث نکنید.
      - فرم مودال استفاده شده‌ی در اینجا همان مطلب «صفحات مودال در بوت استرپ 3» ارتقاء داده شده به نگارش 4 آن است.
  • وحید نصیری در ۱۳۹۸/۰۷/۰۲ ۲۳:۱۷
    جهت اطلاع
    پروژه‌ی DNTIdentity به ASP.NET Core 3.0 ارتقاء داده شد.
  • مسلم نیک در ۱۳۹۸/۰۹/۳۰ ۱۳:۲۷
    سلام
    ضمن تشکر بابت مقاله مفیدتون.
    آیا میشه پروژه را از حالت code first به  database first  تبدیل کرد ؟
  • وحید کاوه در ۱۳۹۹/۰۱/۱۲ ۱۵:۵۷
    با سلام؛ متاسفانه اروری که در تصویر میبینید در پروژه من وجود داره هیچ تغییری هم ندادم و مستقیم از گیت هاب گرفتم. علت چی میتونه باشه؟

    • وحید نصیری در ۱۳۹۹/۰۱/۱۲ ۱۹:۱۹
      - زمانیکه در GitHub آیکن سبز رنگ مشاهده می‌شود، یعنی این پروژه بدون مشکل کامپایل می‌شود. اطلاعات بیشتر
      + این متد در فضای نام using ASPNETCoreIdentitySample.Common.GuardToolkit تعریف شده که import آن در سطر اول همان Context موجود است.
      - برای کار با این پروژه، قبل از هر کاری، حتما Readme آن‌را مطالعه کنید و یکسری مواردی را که ذکر کرده انجام دهید.
  • نقوی در ۱۳۹۹/۰۳/۲۵ ۱۹:۳۱
    سلام، وقتتون بخیر، برای انتی تی AppLogItem از IAuditableEntity ارث بری شده، ولی موقع لاگ خطا هیچ کدام از خاصیت‌های سایه ای (اطلاعات کاربر) برای آن درج نمی‌شود. مشکل از پروژه من هستش یا کلا برای نمونه گذاشته شده و قرار نیست که مقداردهی شود؟ با تشکر.
    • وحید نصیری در ۱۳۹۹/۰۳/۲۶ ۹:۳۵
      اصلاح شد.
  • نقوی در ۱۳۹۹/۰۵/۰۱ ۲۲:۴۱
    سلام، تاریخ هایی که در دیتابیس درج یا ویرایش می‌شوند، تاریخ یک روز قبل می‌باشد. (برای shadow‌ها تاریخ درست درج میشه) این حالت فقط برای فیلدهای جداول خودم می‌باشد.
    builder.AddDateTimeUtcKindConverter();
    کد فوق رو که کامنت میکنم درست میشه.
  • جاهد در ۱۳۹۹/۰۵/۲۸ ۱۱:۳۰
    با سلام؛ پروژه روی سیستم بنده درست اجرا میشه، ولی بعد ازپابلیش روی هاست خطای زیر رو داریم:
    HTTP Error 500.30 - ANCM In-Process Start Failure
    یک نکته اینکه تا قبل از آپدیت ویژوال استودیو به نسخه 16.7.0، همه چی درست بود حتی روی هاست.
  • احمد نهازی در ۱۳۹۹/۰۸/۰۷ ۸:۵۶
    سلام
    من می‌خوام لایه وب این پروژه رو حذف کنم و بجاش یه لایه api به نام WebAppApi بزارم و یک پروژه انگولار درست کنم که به این پروژه وصل بشه.
    سوال اینجاست که اصلا آیا این کار درست هست؟ برای بحث مدیریت کاربران در یک پروژه انگولار آیا باید از identity استفاده کرد؟
    آیا شما سمپلی دارین که مدیریت کاربران در یک پروژه انگولار پیاده سازی شده باشه؟
  • سینا راد در ۱۳۹۹/۱۲/۲۲ ۲۲:۵۱
    ببخشید وقتی یک کاربر رو با کاربر ادمین درست میکنم و بعد میخوام ایمیل اون رو در صفحه https://localhost:5001/Identity/UsersManager تایید بکنم متن داخل Modal رو درست نشون نمیده:

  • میثم سلی در ۱۴۰۰/۰۲/۲۲ ۱۰:۳۶
    با سلام آیا امکان استفاده از Identity core  رو در برنامه‌های windows form یا consol application داریم؟ اگر ممکنه منبع خوبی وجود داره؟
  • احمد قاسمی در ۱۴۰۰/۰۳/۲۳ ۱۲:۱۶
    با سلام و تشکر
    اگر بخواهیم از این پروژه برای هسته یک مجموعه نرم افزار استفاده  کنیم معماری درست چگونه است؟
    پروژه مد نظر شامل سامانه‌های مختلفی که باهم مرتبط هستند خواهد بود
    برای مثال: سامانه نگهداری اسناد و فایلها  - سامانه مکاتبات - سامانه اطلاعات تجهیزات
    این سامانه ها  مستقل هستند و ممکن است برای مشتریان یکی یا چند تا از این سامانه‌های نام برده شده نصب شود

    لازمست که احراز هویت کاربران متمرکز باشد در صورتی که مثلا دو سامانه از این سه سامانه به مشتری فروخته میشود احراز هویت و رویداد نگاری و این موارد مشترک باشد.
    از شما سپاسگزارم.
    • وحید نصیری در ۱۴۰۰/۰۳/۲۳ ۱۳:۴۴
      ASP.NET Core Identity برای اهدافی که ذکر کردید طراحی نشده؛ اطلاعات بیشتر.
  • سامانا در ۱۴۰۰/۰۶/۱۸ ۲۳:۵۸
    سلام وقت بخیر. چگونه میتوان کد زیر یا کد مشابهی را به اینترفیس unitofwork  پروژه اضافه کرد.
    using System.Linq.Expressions; 
 
public class ContextWithExtensionExample
{
   public void DoSomeContextWork(DbContext context)
   {
      var uni = new Unicorn();
      context.Set<Unicorn>().AddIfNotExists(uni , x => x.Name == "James");
   }
}

public static class DbSetExtensions
{
    public static T AddIfNotExists<T>(this DbSet<T> dbSet, T entity, Expression<Func<T, bool>> predicate = null) where T : class, new()
    {
       var exists = predicate != null ? dbSet.Any(predicate) : dbSet.Any();
       return !exists ? dbSet.Add(entity) : null;
    }
}
    • وحید نصیری در ۱۴۰۰/۰۶/۱۹ ۰:۱۷
      متد الحاقی شما، با Set از جنس DbSet کار می‌کند.
  • وحید نصیری در ۱۴۰۰/۱۱/۰۹ ۱۸:۲۲
    جهت اطلاع
    پروژه‌ی DNTIdentity به ASP.NET Core 6.0 ارتقاء داده شد. 
  • امیرسامی در ۱۴۰۱/۰۸/۰۸ ۱۰:۵
    با سلام و خسته نباشید.
    توی این پروژه ما یک جدول نقش داریم که تمامی نقش‌ها درون آن تعریف می‌شود و هر نقشی هم یک سری claim داریم که  برای آن مشخص می‌کنیم و آن نقش را به کاربر می‌دهیم. سوالی که من دارم اینه که من توی یک پروژه یک سری نقش هایی دارم مثل نماینده فروش ، مدیر داخلی و... حالا این نقش‌ها خودشون یه سری ویژگی اضافه هم دارند مثلا خود نماینده فروش میتونه یه سری نماینده فروش دیگه زیر گروهش داشته باشه با توجه به این نقش‌ها آیا بنظرتون این نقش‌ها هم مثل بقیه نقش‌ها باید داخل جدول Role قرار بگیره و تمام دسترسی‌ها رو طبق همون دسترسی  داینامیک بهش بدیم؟ و اگه اینجوری باشه تکلیف اون فیلد‌های اضافی چی میشه؟ یا حتی اگه یه نقشی بعدا اضافه بشه که همین شرایط نماینده فروش را داشته باشد. لطفا اگه ممکنه راهنماییم کنید.
    ممنون
    • وحید نصیری در ۱۴۰۱/۰۸/۰۸ ۱۰:۵۱
      محل ذخیره سازی آن مشخص و مسطح هست و self-referencing نیست. فقط روش پردازش این حالت‌هایی را که فکر می‌کنید باید ارث‌بری داشته باشند، باید از طریق نوشتن AuthorizationHandler‌های سفارشی و Policyهای سفارشی که قابلیت اضافه کردن منطق‌های پیشرفته‌ای را دارند، مدیریت کنید؛ چون حالت پیش‌فرض آن، ارث‌بری‌های چند سطحی را ندارد. نمونه مثال سطوح دسترسی پویای منویی که در این سری هست، یک ارث بری نقشی مشخص، با تعدادی زیر claims‌مشخص آن است که ارتباط بین این‌ها، توسط یک Policy سفارشی و Authorization handler خاص آن برقرار شده.
  • امیرسامی در ۱۴۰۱/۰۸/۱۸ ۱۵:۴۷
    سلام. میخواستم بدونم برای اپدیت کردن پروژه به دات نت 7 باید چکاری انجام بدهیم؟ چون وقتی به صورت عادی پکیج‌ها رو اپدیت میزنیم کلی خطا بوجود میاد.
  • امیرسامی در ۱۴۰۱/۱۲/۱۴ ۱۰:۴۶
    با سلام. من در یکی از سرویس‌ها می‌خواستم از transaction  استفاده کنم. این سرویس به این صورت است که ابتدا باید یک رکورد در یک جدول ذخیره کند و ایدی آن را در یک جدول دیگر ذخیره شود و این جداول هیچ ریلیشنی ندارد به همین خاطر میخواهم از ترنزاکشن استفاده کنم. یعنی از BeginTransaction و در اخر CommitTransaction و در صورتی که با خطا مواجه شوم از RollbackTransaction استفاده می‌کنم ولی متاسفانه خطای  زیر را می‌دهد. لطفا اگه میشه با یک مثالی بفرمایید که چطور باید از توابع بالا استفاده کنیم. ممنون
    The configured execution strategy 'SqlServerRetryingExecutionStrategy' 
does not support user-initiated transactions. Use the execution strategy 
    
returned by 'DbContext.Database.CreateExecutionStrategy()' 
    
to execute all the operations in the transaction as a retriable unit.
    • وحید نصیری در ۱۴۰۱/۱۲/۱۴ ۱۱:۵
      - لطفا خارج از موضوع بحث نکنید.
      + از issue tracker پروژه برای این مسایل استفاده کنید. این مورد قبلا مطرح شده. + ^
  • احمد قاسمی در ۱۴۰۳/۰۸/۰۳ ۱۷:۲۳
    با سلام و تشکر

    من لازم داشتم یک فیلد سوال امنیتی برای بازیابی کلمه عبور، وقتایی که ایمیل رو نمیتونیم استفاده کنیم، اضافه کنم. و میخواستم فیلد پاسخش هش شده باشه. اون قسمت هش شدن پاسخش و آپدیت شدنش (شبیه اون چیزی که برای پسورد اتفاق میفته) رو راهنمایی میفرمایید کجا باید اضافه کنم ؟

    آیا باید متد ApplicationUserManager.CreateAsync رو توسعه بدم ؟

    • وحید نصیری در ۱۴۰۳/۰۸/۰۳ ۲۰:۰۳
      موجودیت User‌ به همراه یکسری فیلد سفارشی هم هست. از آن‌ها و قسمت‌های مرتبط با آن‌ها، ایده بگیرید.
  • احمد قاسمی در ۱۴۰۳/۱۱/۱۶ ۱۴:۲۵
    سلام؛ آیا این پروژه، به‌روز رسانی‌ای با Blazor دارد؟
  • احمد قاسمی در ۱۴۰۴/۰۲/۱۶ ۱۸:۳۴
    با سلام؛ بعد از ارتقای ویژوال استودیو به Visual Studio 2022 17.13.6، پروژه موقع دیباگ هنگام اجرای متد webApp.Run در فایل Program.cs به مشکل زیر برمیخوره:
    Microsoft.AspNetCore.Hosting.Diagnostics: Information: Request finished HTTP/2 GET https://localhost:5001/ - 404 0 - 657.9667ms
Microsoft.AspNetCore.Hosting.Diagnostics: Information: Request reached the end of the middleware pipeline without being handled by application code. Request path: GET https://localhost:5001/, Response status code: 404
    تا قبل از این آپدیت بدون مشکل کار میکرد و تلاش من برای جستجو و حل این خطا متاسفانه نتیجه نداد؛ اگه لطف کنید و راهنمایی بفرمایید چکار کنم حل بشه ممنون میشم.
    • وحید نصیری در ۱۴۰۴/۰۲/۱۶ ۲۰:۰۵
      من الان پروژه را به آخرین نگارش SDK ارتقاء دادم و پس از اجرا در خط فرمان توسط NET CLI.، مشکلی نبود و برنامه اجرا می‌شود و صفحات هم قابل دسترسی هستند.

      در کل اگر SDK جدیدی را نصب کردید، بهتر است یکبار این موارد را هم انجام دهید:
      الف) نصب مجدد مجوزهای SSL آزمایشی:
      dotnet dev-certs https --clean 
dotnet dev-certs https 
dotnet dev-certs https --trust 
dotnet dev-certs https --check --trust
      این دستورات باید با مجوز ادمین اجرا شوند.

      ب) یکبار پروژه را تمیز کنید و مجددا Build کنید:
      dotnet clean
dotnet build
dotnet run
      یعنی حذف تمام پوشه‌های bin و obj و سپس build مجدد (از منوی Build، گزینه Clean Solution و سپس Rebuild Solution را اجرا کنید) و اجرا در خط فرمان و در آخر بررسی نتیجه به این صورت خارج از IDE.

      بررسی جامع خطای 404 بعد از ارتقاء به Visual Studio 2022