gpt4 book ai didi

c# - ASP.NET MVC Identity Framework 卡在开发中的 FindByEmail 调用上,但不是实时版本

转载 作者:太空宇宙 更新时间:2023-11-03 15:01:58 26 4
gpt4 key购买 nike

我们的网站使用 MVC 和身份框架 2.0。在实时站点上(幸运的是)用户现在可以完美登录:

enter image description here

下面是使这项工作附加到 Account Controller 的 Login 操作的代码:

public async Task<ActionResult> Login(vmAccountLogin model, string ReturnUrl)
{
// if problems with model, just redisplay form
if (!ModelState.IsValid)
{
return View(model);
}


// hangs on this line
var user = UserManager.FindByEmail(model.Email);

// if user not found for this email, abort with no clues
if (user == null)

当我构建项目并将 DLL 复制到实时服务器时,它运行良好。但是……

在我的测试版本中,它卡在显示的行上。大约十秒钟后,调试跳转到 Dispose 方法。我逐行检查了 web.config 文件以检查它们是否相同。我读过很多 SO 文章,但认为它们都不适用于这个问题。顺便说一句,这是 UserManager 调用,它工作正常:

public ApplicationUserManager UserManager
{
get
{
return _userManager ?? HttpContext.GetOwinContext().GetUserManager<ApplicationUserManager>();
}
private set
{
_userManager = value;
}
}

如果我启用 .NET 符号调试,它会卡在 FindByEmail 方法调用上。 GetUserManager 调用在即时窗口中显示:

?HttpContext.GetOwinContext().GetUserManager<ApplicationUserManager>();
{wiseowl.ApplicationUserManager}
ClaimsIdentityFactory: {Microsoft.AspNet.Identity.ClaimsIdentityFactory<wiseowl.Models.ApplicationUser, string>}
DefaultAccountLockoutTimeSpan: {00:05:00}
EmailService: {wiseowl.EmailService}
MaxFailedAccessAttemptsBeforeLockout: 5
PasswordHasher: {Microsoft.AspNet.Identity.PasswordHasher}
PasswordValidator: {Microsoft.AspNet.Identity.PasswordValidator}
SmsService: {wiseowl.SmsService}
Store: {Microsoft.AspNet.Identity.EntityFramework.UserStore<wiseowl.Models.ApplicationUser>}
SupportsQueryableUsers: true
SupportsUserClaim: true
SupportsUserEmail: true
SupportsUserLockout: true
SupportsUserLogin: true
SupportsUserPassword: true
SupportsUserPhoneNumber: true
SupportsUserRole: true
SupportsUserSecurityStamp: true
SupportsUserTwoFactor: true
TwoFactorProviders: Count = 2
UserLockoutEnabledByDefault: true
UserTokenProvider: {Microsoft.AspNet.Identity.Owin.DataProtectorTokenProvider<wiseowl.Models.ApplicationUser>}
UserValidator: {Microsoft.AspNet.Identity.UserValidator<wiseowl.Models.ApplicationUser>}
Users: {System.Data.Entity.DbSet<wiseowl.Models.ApplicationUser>}
_claimsFactory: {Microsoft.AspNet.Identity.ClaimsIdentityFactory<wiseowl.Models.ApplicationUser, string>}
_defaultLockout: {00:05:00}
_disposed: false
_factors: Count = 2
_passwordHasher: {Microsoft.AspNet.Identity.PasswordHasher}
_passwordValidator: {Microsoft.AspNet.Identity.PasswordValidator}
_userValidator: {Microsoft.AspNet.Identity.UserValidator<wiseowl.Models.ApplicationUser>}

有人有什么建议吗?

最佳答案

到目前为止,测试环境中的挂起看起来像是异步和阻塞调用的混合,这可能会导致死锁。 FindByEmail 是一种扩展方法,它包装了 UserManager.FindByEmailAsync 的异步 API 调用。

UserManagerExtensions.cs 中找到该版本的源代码显示异步调用正在同步执行。

/// <summary>
/// Find a user by email
/// </summary>
/// <param name="manager"></param>
/// <param name="email"></param>
/// <returns></returns>
public static TUser FindByEmail<TUser, TKey>(this UserManager<TUser, TKey> manager, string email)
where TKey : IEquatable<TKey>
where TUser : class, IUser<TKey>
{
if (manager == null)
{
throw new ArgumentNullException("manager");
}
return AsyncHelper.RunSync(() => manager.FindByEmailAsync(email));
}

我认为在测试环境中运行时会导致死锁(挂起)。没有解释为什么它仍然在实时环境中工作。

我建议按照预期通过 FindByEmailAsync 方法使代码一直异步。尽量避免混合异步调用和阻塞调用。

public async Task<ActionResult> Login(vmAccountLogin model, string ReturnUrl) {
// if problems with model, just redisplay form
if (!ModelState.IsValid) {
return View(model);
}

// hangs on this line
var user = await UserManager.FindByEmailAsync(model.Email);

// if user not found for this email, abort with no clues
if (user == null)

//...code removed for brevity

除此之外,我还建议确保测试环境为身份数据存储使用正确的连接字符串。由于挂起也可能是由于等待连接到数据库时超时。

关于c# - ASP.NET MVC Identity Framework 卡在开发中的 FindByEmail 调用上,但不是实时版本,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/45794017/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com