我正在尝试确认一个帐户,但收到"无效令牌"错误。
这是我正在尝试的:
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<MyCustomUserService>
但我遇到了同样的错误。
有什么线索吗?
传输中的代码被浏览器修改了。尝试对令牌进行 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
public static class UrlEncoding
{
public static string Base64ForUrlEncode(this string str)
{
byte[] encbuff = Encoding.UTF8.GetBytes(str);
return HttpServerUtility.UrlTokenEncode(encbuff);
}
public static string Base64ForUrlDecode(this string str)
{
byte[] decbuff = HttpServerUtility.UrlTokenDecode(str);
return Encoding.UTF8.GetString(decbuff);
}
}
好吧,这浪费了我生命中的几个小时 - 不,几天。在此线程中尝试了所有其他建议后,Asp.NET - 标识 2 - 无效令牌错误,我发现而不是调用
await SignInManager.SignInAsync(user, isPersistent: false, rememberBrowser: false);
在 Register-方法中,紧邻 GenerateEmailConfirmationTokenAsync-block
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.Net MVC 版本为应用程序搭建脚手架引起的。所述方法可以在2013年的 http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity 中找到。
如果这些解决方案不适合您 - 我在 Asp.Net Core 项目中遇到了问题,因为我在 Startup.cs 中添加了以下配置:
services.Configure<RouteOptions>(options =>
{
options.LowercaseUrls = true;
options.LowercaseQueryStrings = true;
});
第二个设置导致确认代码转换为小写,从而导致验证失败。 理想情况下,我想将查询字符串参数保持小写,并且不更改查询字符串值,但我没有找到一种方法来做到这一点,所以我只是删除了查询字符串设置:
services.Configure<RouteOptions>(options =>
{
options.LowercaseUrls = true;
});
Serdar的解决方案是使用Angular作为客户端Web应用程序解决空白空间和+ simbols的关键。
但有时我会收到随机的"无效令牌"错误消息。在对用户数据库进行一些查询后,我发现这些错误仅与那些用户名中有空格或破折号的用户有关。
解决方案是将用户管理器配置为允许用户名中的这些字符。意思是说我的用户数据库直接从Druppal迁移到SQL Server,其中许多用户避免了UserManager的用户验证器的默认策略。
您可以找到如何配置用户验证程序以允许在此线程末尾使用非字母数字字符:
Asp.NET - 标识 2 - 令牌无效错误