Asp.net mvc 5 确认电子邮件上的aspnet标识无效令牌

我正在尝试确认帐户，但收到“无效令牌”。错误

以下是我正在尝试的：

var code = await UserManager.GenerateEmailConfirmationTokenAsync(user.Id);
var callbackUrl = Url.Action("ConfirmacaoEmail", "Usuario", new { userId = user.Id, code = code }, protocol: Request.Url.Scheme);

await UserManager.SendEmailAsync(user.Id, "Ativação de Conta", user.GetEmailAtivacao(model.Nome, callbackUrl));

如果在此代码之后调用

UserManager.ConfirmEmailAsync

，我可以确认帐户。但是，如果我打开链接，发现它在变量callbackUrl中，并尝试通过该操作进行确认，则会出现错误

我认为它可能与OwinContext有关，所以我决定调用

HttpContext.GetOwinContext（）.GetUserManager

，但我得到了相同的错误

---

有什么线索吗？

最有可能是传输中的代码被浏览器修改了。尝试在令牌上执行UrlEncode：

var code = await userManager.GenerateEmailConfirmationTokenAsync(userId);
code = System.Web.HttpUtility.UrlEncode(code);

否则，浏览器会弄乱令牌中可能存在的特殊符号

我也遇到过同样的问题。我用以下代码解决了问题。

示例：

var emailToken = _customManager.GenerateEmailConfirmationToken(userId);
emailToken = emailToken.Base64ForUrlEncode();

扩展方法=>名称空间：System.Text，System.Web

---

Serdar的解决方案是使用Angular作为客户端web应用程序解决空白和+Simbol的关键

但有时我会收到随机的“无效令牌”错误消息。在对用户数据库进行了一些查询之后，我发现这些错误只出现在用户名中有空格或破折号的用户身上

解决方案是将用户管理器配置为允许用户名中包含这些字符。这意味着我的用户数据库是从Druppal直接迁移到SQL Server的，其中许多用户避免了用户管理器中UserValidator的默认策略

您可以找到如何配置UserValidator以允许在此线程末尾使用非字母数字字符：

---

好吧，这浪费了我生命中的几个小时，不，几天。在尝试了这个线程中的所有其他建议后，我发现

await SignInManager.SignInAsync(user, isPersistent: false, rememberBrowser: false);

在GenerateMailConfirmationTokenAsync块之前的Register方法中

await SignInAsync(user, isPersistent: false);

被称为，定义为

private async Task SignInAsync(ApplicationUser user, bool isPersistent)
{
        AuthenticationManager.SignOut(DefaultAuthenticationTypes.ExternalCookie);
        AuthenticationManager.SignIn(new AuthenticationProperties() { IsPersistent = isPersistent }, await user.GenerateUserIdentityAsync(UserManager));
}

---

我认为这是由于使用较旧的ASP.NETMVC版本搭建应用程序造成的。所述方法可在2013年起的中找到。

如果这些解决方案不适用于您，我在Asp.Net核心项目中遇到了此问题，因为我在Startup.cs中添加了以下配置：

services.Configure<RouteOptions>(options =>
{
  options.LowercaseUrls = true;
  options.LowercaseQueryStrings = true;
});

services.Configure（选项=>
{
options.LowercaseUrls=true；
options.LowercaseQueryStrings=true；
});

第二个设置导致确认代码转换为小写，从而导致验证失败。理想情况下，我希望保留查询字符串参数的小写形式，并且不更改查询字符串值，但我没有找到这样做的方法，因此我只是删除了查询字符串设置：

services.Configure<RouteOptions>(options =>
{
  options.LowercaseUrls = true;
});

services.Configure（选项=>
{
options.LowercaseUrls=true；
});

我不知道为什么，但我已经从POST变为GET，而且很有效。@ThiagoCustodio从POST变为GET意味着什么，在哪里？请更具体地帮助其他人…@Giox确认令牌有问题。当我使用POST进行操作时，代码不起作用。因此，我修改了代码，使用GET实现了操作，并且成功了。对我来说这没有意义，但我可以用这个小小的改变来解决这个问题。@ThiagoCustodio谢谢。是的，我也看不出它有什么意义！！顺便说一句，经过数小时的努力，我发现我的无效令牌是由ApplicationUserManager.Create（）方法中的Microsoft.Owin.Security.DataProtection.DpapiDataProtectionProvider（…appName）中设置的不同应用程序名称造成的。我必须将UrlDecode（代码）添加到ConfirmMail操作中才能工作。在我的例子中（Asp.Net Core 3.0）似乎是脚手架页面引入了此错误。在这里见我的朋友。

services.Configure<RouteOptions>(options =>
{
  options.LowercaseUrls = true;
});