【问题标题】:How to seed ASP.NET Core Identity users as part of EF Migrations如何将 ASP.NET Core Identity 用户作为 EF 迁移的一部分播种
【发布时间】:2020-03-15 07:41:16
【问题描述】:

总结:

我一直在尝试将用户作为 ASP.NET Core 3.0 项目的一部分进行播种,该项目使用 Identity 3.0 和本地用户帐户,但在通过 EF 迁移播种时遇到无法登录的问题;如果我在应用程序启动时这样做,它会起作用。

工作方法(在应用启动时):

如果我创建一个静态初始化器类并在我的Startup.csConfigure 方法中调用它,那么一切正常,之后我可以毫无问题地登录。

ApplicationDataInitialiser.cs

public static class ApplicationDataInitialiser
    {
        public static void SeedData(UserManager<ApplicationUser> userManager, RoleManager<ApplicationRole> roleManager)
        {
            SeedRoles(roleManager);
            SeedUsers(userManager);
        }

        public static void SeedUsers(UserManager<ApplicationUser> userManager)
        {
            if (userManager.FindByNameAsync("admin").Result == null)
            {
                var user = new ApplicationUser
                {
                    UserName = "admin",
                    Email = "admin@contoso.com",
                    NormalizedUserName = "ADMIN",
                    NormalizedEmail = "ADMIN@CONTOSO.COM"
                };

                var password = "PasswordWouldGoHere";

                var result = userManager.CreateAsync(user, password).Result;

                if (result.Succeeded)
                {
                    userManager.AddToRoleAsync(user, "Administrator").Wait();
                }
            }
        }

        public static void SeedRoles(RoleManager<ApplicationRole> roleManager)
        {
            if (!roleManager.RoleExistsAsync("Administrator").Result)
            {
                var role = new ApplicationRole
                {
                    Name = "Administrator"
                };
                roleManager.CreateAsync(role).Wait();
            }
        }
    }

Startup.cs

public class Startup
{
    public Startup(IConfiguration configuration)
    {
        Configuration = configuration;
    }

    public IConfiguration Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddControllersWithViews();
        services.AddRazorPages();
    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env, UserManager<ApplicationUser> userManager, RoleManager<ApplicationRole> roleManager)
    {
        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
            app.UseDatabaseErrorPage();
        }
        else
        {
            app.UseExceptionHandler("/Home/Error");
            app.UseHsts();
        }
        app.UseHttpsRedirection();
        app.UseStaticFiles();

        app.UseRouting();

        app.UseAuthentication();
        app.UseAuthorization();

        app.UseEndpoints(endpoints =>
        {
            endpoints.MapControllerRoute(
                name: "default",
                pattern: "{controller=Home}/{action=Index}/{id?}");
            endpoints.MapRazorPages();
        });

        ApplicationDataInitialiser.SeedData(userManager, roleManager);
    }
}

这样做的问题是,在启动时运行它意味着密码必须在那个时候对应用程序可用,这要么意味着将其提交到源代码控制(显然不是一个好主意),要么可能将其作为环境变量(这意味着它在主机上可用,因此这也是一个潜在的问题)。

非工作方法(在 EF 迁移期间):

因此,我一直在考虑在上下文的 OnModelCreating 方法中播种用户和角色,并在需要时生成 EF 迁移脚本,而不是将迁移提交到源代码管理。

MyContext.cs - OnModelCreating 方法

protected override void OnModelCreating(ModelBuilder builder)
    {
        base.OnModelCreating(builder);

        builder.Entity<ApplicationUser>(b =>
        {
            b.HasMany(e => e.UserRoles)
                .WithOne(e => e.User)
                .HasForeignKey(ur => ur.UserId);
        });

        builder.Entity<ApplicationRole>(b =>
        {
            b.HasMany(e => e.UserRoles)
                .WithOne(e => e.Role)
                .HasForeignKey(ur => ur.RoleId)
                .OnDelete(DeleteBehavior.Restrict);
        });

        var adminRole = new ApplicationRole { Name = "Administrator", NormalizedName = "ADMINISTRATOR" };

        var appUser = new ApplicationUser
        {
            UserName = "admin",
            Email = "admin@contoso.com",
            NormalizedUserName = "ADMIN",
            NormalizedEmail = "ADMIN@CONTOSO.COM",
            SecurityStamp = Guid.NewGuid().ToString()
        };

        var hasher = new PasswordHasher<ApplicationUser>();
        appUser.PasswordHash = hasher.HashPassword(appUser, "PasswordWouldBeHere");

        builder.Entity<ApplicationRole>().HasData(
            adminRole
        );
        builder.Entity<ApplicationUser>().HasData(
            appUser
        );
        builder.Entity<ApplicationUserRole>().HasData(
            new ApplicationUserRole { RoleId = adminRole.Id, UserId = appUser.Id }
        );
    }

问题在于,虽然这似乎成功了,并且密码哈希显示在数据库中的长度与其他方法相同,但当我尝试使用以这种方式生成的帐户登录时,我经常收到提示密码错误的失败。

我已经覆盖了身份文件 Login.cshtml.cs 并修改了 OnPostAsync 方法以使用 UserName 属性来检查凭据,而 PasswordSignInAsync 方法每次都会失败。这不是由于帐户被锁定或任何其他可能性,因为它们在result 对象中以false 的形式返回。这是一个带有新应用程序的新数据库,因此它应该在我的上下文文件中使用与密码哈希相同的兼容版本。

Login.cshtml.cs - OnPostAsync 方法

public async Task<IActionResult> OnPostAsync(string returnUrl = null)
    {
        returnUrl = returnUrl ?? Url.Content("~/");

        if (ModelState.IsValid)
        {
            // This doesn't count login failures towards account lockout
            // To enable password failures to trigger account lockout, set lockoutOnFailure: true
            var result = await _signInManager.PasswordSignInAsync(Input.UserName, Input.Password, Input.RememberMe, lockoutOnFailure: false);
            if (result.Succeeded)
            {
                _logger.LogInformation("User logged in.");
                return LocalRedirect(returnUrl);
            }
            if (result.RequiresTwoFactor)
            {
                return RedirectToPage("./LoginWith2fa", new { ReturnUrl = returnUrl, RememberMe = Input.RememberMe });
            }
            if (result.IsLockedOut)
            {
                _logger.LogWarning("User account locked out.");
                return RedirectToPage("./Lockout");
            }
            else
            {
                ModelState.AddModelError(string.Empty, "Invalid login attempt.");
                return Page();
            }
        }

        // If we got this far, something failed, redisplay form
        return Page();
    }

所以对我来说主要的事情是尝试看看为什么当用户从 OnModelCreating 方法播种时密码不被接受 - 这可能是 PasswordHasher 的问题,但我没能看看我所做的似乎是错误的任何例子。

【问题讨论】:

  • 谢谢,但这表明如何在应用程序启动时播种数据,正如我在问题中明确指出的那样,我能够做到。问题是在 EF 迁移过程中播种包含密码的数据。

标签: c# asp.net-core entity-framework-core asp.net-identity entity-framework-migrations


【解决方案1】:

我认为这里的问题是您的前端期望用户名是电子邮件地址,而不是您拥有的简单“管理员”。尝试将您的应用用户更改为:

var appUser = new ApplicationUser
    {
        UserName = "admin@contoso.com",
        Email = "admin@contoso.com",
        NormalizedUserName = "ADMIN@CONTOSO.COM",
        NormalizedEmail = "ADMIN@CONTOSO.COM",
        SecurityStamp = Guid.NewGuid().ToString()
    };

或者不强制将您的登录名作为电子邮件地址

【讨论】:

    【解决方案2】:

    我使用这两种方式并得到NotAllowed,因为当我播种数据时EmailConfirmed 属性为假。

    虽然 asp.net core 3.0 身份是默认注册的,如下所示,其中将RequireConfirmedAccount = true 设置为需要电子邮件确认。

    services.AddDefaultIdentity<ApplicationUser>(options => options.SignIn.RequireConfirmedAccount = true)
                .AddEntityFrameworkStores<ApplicationDbContext>();
    

    当我删除上述选项或将其添加到数据播种中然后成功登录时:

    var appUser = new ApplicationUser
            {
                UserName = "admin",
                Email = "admin@contoso.com",
                NormalizedUserName = "ADMIN",
                NormalizedEmail = "ADMIN@CONTOSO.COM",
                EmailConfirmed = true,
                SecurityStamp = Guid.NewGuid().ToString()
            };
    

    【讨论】:

    • 感谢您的评论。不幸的是,我在设置默认身份时已经将RequireConfirmedAccount 设置为falseservices.AddDefaultIdentity&lt;ApplicationUser&gt;(options =&gt; options.SignIn.RequireConfirmedAccount = false) .AddRoles&lt;ApplicationRole&gt;() .AddEntityFrameworkStores&lt;MyContext&gt;() .AddDefaultTokenProviders();
    • @codeandchips 我在一个新项目中测试并且只播种用户数据(没有角色)并且它有效。你试过了吗?
    • 感谢您的快速回复!我刚刚尝试将EmailConfirmed 明确设置为true,并且还删除了角色并只是为用户帐户播种,但不幸的是仍然遇到同样的问题。
    【解决方案3】:

    我刚遇到这个问题,并注意到我没有设置我的 NormalizedUsername / NormalizedEmail 字段。我将这些设置为与用户名/电子邮件值相同,它突然起作用了。也许您需要使您的规范化字段与原始字段完全相同。

    【讨论】:

      猜你喜欢
      • 2016-03-24
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-08-27
      • 2021-11-22
      • 2018-03-12
      • 2016-06-10
      相关资源
      最近更新 更多