identificador inválido de aspnet en el correo electrónico de confirmación

Estoy intentando confirmar una cuenta, pero obtengo un “token no válido”. error.

Esto es lo que estoy intentando:

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)); 

si llamo a UserManager.ConfirmEmailAsync después de este código, puedo confirmar la cuenta. Sin embargo, si abro el enlace que está dentro de la variable callbackUrl y trato de confirmarlo, recibo el error.

Pensé que podría ser algo con OwinContext, así que decidí llamar a HttpContext.GetOwinContext().GetUserManager pero estoy obteniendo el mismo error.

¿Alguna pista?

Lo más probable es que el código en tránsito sea modificado por el navegador. Intenta hacer UrlEncode en el token:

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

De lo contrario, el navegador se equivoca con los símbolos especiales que pueden estar presentes en el token.

He experimentado el mismo problema. Resolví el problema con el siguiente código.

Muestra:

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

Métodos de extensión => Nombre del espacio: 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); } } 

La solución de Serdar fue la clave para la solución de espacios vacíos y + símbolos utilizando Angular como aplicación web cliente.

Pero a veces obtenía mensajes de error aleatorios de “token inválido”. Después de algunas consultas a la base de datos del usuario, descubrí que esos errores solo estaban relacionados con aquellos usuarios que tenían espacios o guiones en su nombre de usuario.

La solución fue configurar el Administrador de usuarios para permitir esos caracteres en UserNames. Me refiero a decir que mi base de datos de usuarios se migró de Druppal directamente a SQL Server y muchos de esos usuarios evitaron la política predeterminada de UserValidator en el Administrador de usuarios.

Puede encontrar cómo configurar UserValidator para permitir caracteres no alfanuméricos al final de este hilo:

Asp.NET – Identity 2 – Error Token no válido

Ok, estas horas desperdiciadas – no, días – de mi vida. Después de probar todas las otras sugerencias en este hilo y en Asp.NET – Identidad 2 – Error Token no válido encontré que en lugar de llamar

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

en el método de registro justo antes del bloque GenerateEmailConfirmationTokenAsync

 await SignInAsync(user, isPersistent: false); 

fue llamado que se define como

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

Creo que esto fue causado por el andamiaje de la aplicación con una versión más antigua de ASP.Net MVC. El método descrito se puede encontrar en http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity de 2013.