ASP.NET Identity 2.0随机无效令牌

本文关键字：随机 无效 令牌 NET Identity ASP | 更新日期: 2024-10-20 20:01:07

有时用户在点击电子邮件确认链接时会收到无效令牌。我不明白为什么，这完全是随机的。

以下是创建用户的代码：

IdentityResult result = manager.Create(user, "Password134567");
if (result.Succeeded)
{
    var provider = new DpapiDataProtectionProvider("WebApp2015");
    UserManager<User> userManager = new UserManager<User>(new UserStore<User>());
    userManager.UserTokenProvider = new DataProtectorTokenProvider<User>(provider.Create(user.Id));
    manager.UserTokenProvider = new DataProtectorTokenProvider<User>(provider.Create("ConfirmUser"));
    var emailInfo = new Email();
    string code = HttpUtility.UrlEncode(Context.GetOwinContext().GetUserManager<ApplicationUserManager>().GenerateEmailConfirmationToken(user.Id));
    string callbackUrl = IdentityHelper.GetUserConfirmationRedirectUrl(code, user.Id, Request);
    if (email.IndexOf("@") != -1)
    {
        if (assignedId == 0)
        {
            lblError.Text = "There was an error adding this user";
            return;
        }
        string emailcontent = emailInfo.GetActivationEmailContent(assignedId, callbackUrl, userRole);
        string subject = emailInfo.Subject;
        if (string.IsNullOrEmpty(subject))
        {
            subject = "Your Membership";
        }
        Context.GetOwinContext()
               .GetUserManager<ApplicationUserManager>()
               .SendEmail(user.Id, subject, emailcontent);
        if (user.EmailConfirmed)
        {
            IdentityModels.IdentityHelper.SignIn(manager, user, isPersistent: false);
            IdentityHelper.RedirectToReturnUrl(Request.QueryString["ReturnUrl"], Response);
        }
        else
        {
            ErrorMessage.ForeColor = Color.Green;
            ErrorMessage.Text = "An email has been sent to the user, once they verify their email they are ready to login.";
        }
    }
    else
    {
        ErrorMessage.ForeColor = System.Drawing.Color.Green;
        ErrorMessage.Text = "User has been created.";
    }
    var ra = new RoleActions();
    ra.AddUserToRoll(txtEmail.Text, txtEmail.Text, userRole);
}
else
{
    ErrorMessage.Text = result.Errors.FirstOrDefault();
}

这是给出"无效令牌"错误的确认页面

protected void Page_Load(object sender, EventArgs e)
{
    var code = IdentityHelper.GetCodeFromRequest(Request);
    var userId = IdentityHelper.GetUserIdFromRequest(Request);
    if (code != null && userId != null)
    {
        var manager = Context.GetOwinContext()
                             .GetUserManager<ApplicationUserManager>();
        var confirmId = manager.FindById(userId);
        if (confirmId != null)
        {
            var result = manager.ConfirmEmail(userId, HttpUtility.UrlDecode(code));
            if (result.Succeeded)
            {
                return;
            }
            else
            {
                lblError.Text = result.Errors.FirstOrDefault();
                txtNewPassword.TextMode= TextBoxMode.SingleLine;
                txtNewPassword.Text = "Error contact support";
                txtNewPassword2.TextMode= TextBoxMode.SingleLine;
                txtNewPassword2.Text = result.Errors.FirstOrDefault();
                txtNewPassword.Enabled = false;
                txtNewPassword2.Enabled = false;
                imageButton1.Enabled = false;
            }
        }
        else
        {
            lblError.Text = "Account Does Not Exist";
            imageButton1.Enabled = false;
        }
    }
}

ASP.NET Identity 2.0随机无效令牌

现场演示项目

我为您创建了一个精简的演示项目。它在这里的GitHub上托管，并在这里的Azure上直播。它按设计工作（请参阅有关Azure网站的编辑），并使用与您使用的方法相似但不完全相同的方法。

它从这个教程开始，然后我删除了这个NuGet演示代码附带的cruft：

Install-Package -Prerelease Microsoft.AspNet.Identity.Samples

出于您的目的，我的演示代码比NuGet示例更相关，因为它只关注令牌创建和验证。特别是，看看这两个文件：

Startup.Auth.cs

每次应用程序启动时，我们只实例化IDataProtectionProvider一次。

public partial class Startup
{
    public static IDataProtectionProvider DataProtectionProvider 
    { 
        get; 
        private set; 
    }
    public void ConfigureAuth(IAppBuilder app)
    {
        DataProtectionProvider = 
            new DpapiDataProtectionProvider("WebApp2015");
        // other code removed
    }
}

AccountController.cs

然后在AccountController中，我们使用静态提供程序，而不是创建一个新的提供程序。

userManager.UserTokenProvider = 
    new DataProtectorTokenProvider<User>(
        Startup.DataProtectionProvider.Create("UserToken"));

这样做可能会删除您看到的错误。以下是一些问题，供您在进一步进行故障排除时考虑。

您是否使用了两种不同的UserTokenProvider目的

DataProtectorTokenProvider.Create(string[] purposes)方法采用purposes参数。以下是MSDN对此的看法：

目的。用于确保受保护数据的附加熵可能仅出于正确目的而不受保护。

当您创建用户code时，您使用（至少）两种不同的目的：

  1. user.Id
  2. "ConfirmUser"和
  3. 使用GetOwinContext()...检索的ApplicationUserManager的用途

这是您的代码片段。

userManager.UserTokenProvider = 
    new DataProtectorTokenProvider<User>(provider.Create(user.Id));
manager.UserTokenProvider = 
    new DataProtectorTokenProvider<User>(provider.Create("ConfirmUser"));
string code = Context
    .GetOwinContext()
    .GetUserManager<ApplicationUserManager ()      
    .GenerateEmailConfirmationToken(user.Id)

当您验证code时，您可能使用了错误的目的。您将用于确认电子邮件的ApplicationUserManager的UserTokenProvider分配到哪里？它的目的论点必须相同！

var manager = Context.GetOwinContext()
                  .GetUserManager<ApplicationUserManager>();
var result = manager.ConfirmEmail(userId, HttpUtility.UrlDecode(code));

令牌很有可能无效，因为有时使用与验证不同的UserTokenProvider创建目的。

为什么有时会这样？对代码进行彻底搜索，以找到分配给UserTokenProvider的所有位置。也许您在某个意外的地方覆盖了它（例如在属性或IdentityConfig.cs文件中），使它看起来是随机的。

TokenLifespan过期了吗

您已经提到Invalid Token消息是随机发生的。可能是令牌已过期。本教程注意到，默认寿命为一天。你可以这样更改：

manager.UserTokenProvider = 
    new DataProtectorTokenProvider<ApplicationUser>
      (dataProtectionProvider.Create("WebApp2015"))
      {                    
         TokenLifespan = TimeSpan.FromHours(3000)
      };

为什么有三个UserManager实例

以下是对创建确认令牌的代码的一些注释。您似乎使用了三个独立的UserManager实例，其中包括一个派生的ApplicationUserManager类型。这是怎么回事？

  1. 这里的manager是什么类型的
  2. 为什么要创建userManager而不是使用现有的manager
  3. 为什么使用manager.UserTokenProvider而不是userManager.UserTokenProvider
  4. 为什么要从Context获得第三个UserManager实例

请注意，我删除了很多代码，只关注您的代币创建。

// 1. 
IdentityResult result = manager.Create(user, "Password134567");
if (result.Succeeded)
{
    var provider = new DpapiDataProtectionProvider("WebApp2015");
    // 2. 
    UserManager<User> userManager = 
        new UserManager<User>(new UserStore<User>());
    userManager.UserTokenProvider = 
        new DataProtectorTokenProvider<User>(provider.Create(user.Id));
    // 3.
    manager.UserTokenProvider = 
        new DataProtectorTokenProvider<User>(provider.Create("ConfirmUser"));
    // 4. 
    string raw = Context.GetOwinContext()
                 .GetUserManager<ApplicationUserManager>()
                 .GenerateEmailConfirmationToken(user.Id)
    // remaining code removed
}

我想知道我们是否可以将上面的内容简化为只使用一个UserManager实例，如下所示。

// 1. 
IdentityResult result = manager.Create(user, "Password134567");
if (result.Succeeded)
{
    var provider = new DpapiDataProtectionProvider("WebApp2015");
    manager.UserTokenProvider = 
        new DataProtectorTokenProvider<User>(provider.Create(user.Id));
    // 3.
    var provider = provider.Create("ConfirmUser");
    manager.UserTokenProvider = 
        new DataProtectorTokenProvider<User>(provider);
    // 4. 
    string raw = manager.GenerateEmailConfirmationToken(user.Id);
    // remaining code removed
}

如果使用这种方法，请确保在确认电子邮件时使用相同的"ConfirmUser"目的参数。

IdentityHelper里面有什么

由于错误是随机发生的，我突然想到IdentityHelper方法可能对code做了一些奇怪的事情，把事情搞砸了。每种方法的内部都有什么？

  • IdentityHelper.GetUserConfirmationRedirectUrl()
  • IdentityHelper.RedirectToReturnUrl()
  • IdentityHelper.GetCodeFromRequest()
  • IdentityHelper.GetUserIdFromRequest()

我可能会编写一些测试，以确保您的进程创建的原始code始终与您的进程从Request检索的原始code匹配。在伪代码中：

var code01 = CreateCode();
var code02 = UrlEncode(code01);
var request = CreateTheRequest(code02);
var response = GetTheResponse();
var code03 = GetTheCode(response);
var code04 = UrlDecode(code03);
Assert.AreEquals(code01, code04);

运行以上10000次，以确保不存在任何问题。

结论

我强烈怀疑问题在于在令牌创建期间使用一个purposes参数，在确认期间使用另一个参数。只使用一个目的，你可能会没事的。

在Azure网站上进行此操作

  1. 使用SqlCompact而不是localdb
  2. 使用app.GetDataProtectionProvider()而不是DpapiDataProtectionProvider，因为Dpapi不适用于web场

站点是否托管在多个web服务器上？如果是，则不能在此处使用DPAPI。它是特定于机器的。您需要使用另一个数据保护提供程序。

代码（令牌）中可能存在一些url无效字符。因此，当它出现在任何url中时，我们需要使用HttpUtility.UrlEncode(token)和HttpUtility.UrlDecode(token)。

请在此处查看详细信息：身份密码重置令牌无效

虽然我认为肖恩为解决这些问题提供了很好的反馈。你的一条评论让我觉得这可能是一个备用代币问题。另请参阅关于多个服务器和令牌的评论。

这完全是随机

我不认为这是随机的。但对于一些用户来说，是什么让它在大部分时间内都能工作呢。

令牌是为不同的页面或应用程序生成的，或者来自同一应用程序，并且刚刚过期。例如短期有效的令牌。存在于浏览器中。令牌来自类似的应用程序或来自不同表单/页面上的同一应用程序。浏览器呈现该令牌，因为该令牌是为域生成的。

但当分析时，令牌不匹配，或者刚刚过期。

考虑令牌的生命周期。

相关文章：