发布于2026-07-17 阅读(0)
扫一扫,手机访问
先说结论:用 dotnet new mvc -au Individual 创建项目最省事,它自动生成带 Identity 的完整认证流程——注册、登录、登出、密码重置全套搞定,不用手动配 DbContext、UserManager 或写 Account 控制器。对于绝大多数场景,这是开箱即用的最佳起点。

手搭 Identity 容易卡在三类问题上:数据库迁移失败、UserManager 注入失败、或登录后 HttpContext.User.Identity.IsAuthenticated 始终为 false。这些不是逻辑错误,而是服务注册顺序、中间件加载时机、Cookie 策略配置等底层链路没对齐导致的。官方模板已验证过所有环节,适合绝大多数业务场景,何必自己踩完所有坑再回头改呢?
Program.cs 中调用 builder.Services.AddDefaultIdentity() ,不是 AddIdentity() —— 后者不带 UI 和默认策略,额外要配的东西太多,容易挂一漏万。.AddEntityFrameworkStores() ,否则 UserManager 没法查库,注入时直接报错。app.UseAuthentication() 和 app.UseAuthorization() 要放在 app.UseRouting() 之后、app.UseEndpoints() 之前,顺序错一个中间件就失效,登录后 Cookie 根本不生效。AddDbContext 里用的完全一致,比如 options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")),那 appsettings.json 里就得有 "DefaultConnection" 这个 key。名字对不上,运行时直接抛异常,查半天才发现是配置键名写错了。常见现象是加了 [Authorize] 的 Action 仍能匿名访问,或者跳转到空白登录页。别急着怀疑框架,先看这三步:
ApplicationUser 类是否继承自 IdentityUser(不是 IdentityUser 或其他泛型变体)?继承错类型会导致 ClaimsPrincipal 解析失败,用户身份根本拿不到。SignInManager.PasswordSignInAsync() 而不是只调 UserManager.CheckPasswordAsync()?后者只验密,不发认证 Cookie,所以登录完页面一刷新就回到未登录状态。Cookie 头?API 场景下容易忽略这点,导致服务端认为“未登录”。建议用 Postman 先确认 Set-Cookie 响应头存在且域名路径匹配,否则排查半天可能只是浏览器没存 Cookie。最常被忽略的是:角色授权(如 [Authorize(Roles="Admin")])要求用户必须已分配角色,且角色名大小写完全匹配数据库中 AspNetRoles.Name 字段值——不是你代码里写的字符串,而是 EF 实际存进去的那条记录。大小写不一致,授权永远失败。
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
正版软件
正版软件
正版软件
正版软件
正版软件
1
2
3
7
8