您不应该直接查询当前ApplicationUser的数据库。
这会引入额外的依赖关系,需要一个额外的上下文开始,但随着用户数据库表的更改(在过去的两年中有三次),API保持一致。例如,Identity Framework中的users
表现在被称为AspNetUsers
,并且几个主键字段的名称不断更改,因此几个答案中的代码将不能直接使用。
另一个问题是基础OWIN访问数据库将使用单独的上下文,因此来自单独SQL访问的更改可能会产生无效结果(例如,未看到对数据库进行的更改)。因此,解决方案是与提供的API一起工作,而不是尝试绕过它。
访问ASP.Net身份验证中当前用户对象的正确方法(截至此日期)是:
var user = UserManager.FindById(User.Identity.GetUserId());
或者,如果你有一个异步操作,类似于:
var user = await UserManager.FindByIdAsync(User.Identity.GetUserId());
FindById
需要使用以下using语句才能使非异步的UserManager
方法可用(它们是UserManager的扩展方法,如果不包括这个,你只会看到FindByIdAsync
):
using Microsoft.AspNet.Identity;
如果您根本不在控制器中(例如,您正在使用IOC注入),则从以下位置完整检索用户ID:
System.Web.HttpContext.Current.User.Identity.GetUserId();
如果你不在标准的Account控制器中,你需要将以下内容(例如)添加到你的控制器中:
1. 添加这两个属性:
protected ApplicationDbContext ApplicationDbContext { get; set; }
protected UserManager<ApplicationUser> UserManager { get; set; }
2. 在控制器的构造函数中添加以下内容:
this.ApplicationDbContext = new ApplicationDbContext();
this.UserManager = new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(this.ApplicationDbContext));
2015年3月更新
注意:最近一次的Identity框架更新改变了用于身份验证的底层类之一。现在,您可以从当前HttpContent的Owin上下文中访问它。
ApplicationUser user = System.Web.HttpContext.Current.GetOwinContext().GetUserManager<ApplicationUserManager>().FindById(System.Web.HttpContext.Current.User.Identity.GetUserId());
附加说明:
在使用EF和Identity Framework连接Azure远程数据库时(例如本地主机测试到Azure数据库),您可能会随机遇到可怕的“错误:19 - 物理连接不可用”。由于原因位于Identity Framework中,您无法添加重试(或者看起来像是缺少.Include(x->someTable)
),因此需要在项目中实现自定义的SqlAzureExecutionStrategy
。
ApplicationUser
类(应用程序特定),并与AspNetUsers
表并行使用,它们将提供任何新的字段。再次强调:不要直接连接数据库! :) - iCollect.it Ltd