Недопустимый токен 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<MyCustomUserService>, но я получаю ту же ошибку.

Любые подсказки?

Ответ 1

Скорее всего, что код в пути изменен браузером. Попробуйте выполнить UrlEncode на токене:

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

В противном случае браузеры со специальными символами, которые могут присутствовать в токене.

Ответ 2

У меня возникла та же проблема. Я решил проблему со следующим кодом.

Пример:

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

Ответ 3

Решение Serdar было ключом к решению для пустых пространств и + символов с использованием Angular в качестве клиентского веб-приложения.

Но иногда я получал случайные сообщения об ошибках "недопустимый токен". При возникновении некоторых запросов к пользовательской базе данных я обнаружил, что эти ошибки были только с теми пользователями, у которых есть пробелы o тире в их UserName.

Решение было настроено на User Manager, чтобы разрешить эти символы в UserNames. Предположим, что моя пользовательская база данных была перенесена из Druppal непосредственно на SQL Server, и многие из этих пользователей избегали политики по умолчанию из UserValidator в User Manager.

Вы можете найти, как настроить UserValidator, чтобы в конце этого потока разрешались не буквенно-цифровые символы:

Asp.NET - Идентификатор 2 - Неверная ошибка токена

Ответ 4

Хорошо, это потраченные впустую часы - нет, дней - моей жизни. После того, как вы попробовали все другие предложения в этом потоке в Asp.NET - Identity 2 - Invalid Token Error, я обнаружил, что вместо вызова

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

в методе Register непосредственно перед блоком GenerateEmailConfirmationTokenAsync

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. Описанный метод можно найти в http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity с 2013 года.

Ответ 5

Если эти решения не работают для вас - я столкнулся с проблемой в проекте Asp.Net Core, потому что я добавил следующую конфигурацию в Startup.cs:

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

Второй параметр вызывал преобразование кода подтверждения в нижний регистр, что приводило к сбою проверки. В идеале я хотел бы сохранить параметры строки запроса в нижнем регистре и не изменять значения строки запроса, но я не нахожу способ сделать это, поэтому я просто удалил параметр строки запроса:

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