В соответствии с заголовком я попытался настроить простой проект веб-API ASP.NET Core 2.2 (поэтому ничего общего с MVC Razor Pages или пользовательским интерфейсом).
Я следовал этому руководству Microsoft Подтверждение учетной записи и восстановление пароля в ASP.NET Core , но, очевидно, адаптировал его для моего проекта Web API, который состоит из следующих четырех конечных точек:
- CreateUserAsync
- ConfirmEmailAsync
- PasswordResetEmailAsync
- ResetPasswordAsync
Имена довольно понятны: первые две конечные точки имеют дело с созданием пользователя, отправкой электронной почты с использованием SendGrid, а затем сделки с второй конечной точкойс проверкой токена подтверждения и подтверждением учетной записи пользователя.
Пока все хорошо, как задумано, токен правильно проверен, и поле строки таблицы AspNetUser EmailConfirmed
установлено в true (1).Извинения за то, что я упомянул об этом, я уже подготовил таблицы, связанные с AspNetUser, используя Entity Framework Migrations (команда Add-Migration
).
Теперь третья и четвертая конечные точки имеют дело со сценарием пользователя, запрашивающего парольтокен сброса затем использовать для сброса пароля, чтобы конечная точка с номером 3 PasswordResetEmailAsync
повторно использовала тот же код, что и конечная точка ConfirmEmailAsync
, сначала проверяя, существует ли пользователь с помощью метода UserManager.FindByNameAsync
, а затем передает объект ApplicationUser
этого типа (полученный из IdentityUser
)) в метод FindByNameAsync
, который затем попадает в резервное хранилище и извлекает пользователя, которого мы создали ранее (это работает как задумано):
var result = await _userManager
.ResetPasswordAsync(user, token, theNewPassword)
.ConfigureAwait(false);
Это всегда возвращает следующее ( used Object Exporter надстройка для этого ):
{
"Errors":
[
{
"Code": "InvalidToken",
"Description": "Invalid token."
}
],
"Succeeded": false,
"_errors":
}
Как видно из фрагмента JSON выше, токен считается недействительным, однако, когда я сравнил сгенерированный токен с передаваемым.в конечную точку ResetPasswordAsync то же самое:
CfDJ8NKO7RlW/idPs+/v0VVN8vv99DYu3b4zYHddSIlvUBHjcThOMG85zegMIJ6AUpQJXpC0Ouk0QW8hVVDIRUgT7u0TnUU+kJePskU2UMRaul0NtddoeJ30LsOe62K8lMqm9OyC8+CsU9nZZFKIWRDoJxnGCAJiznVukulFX9BxAhnFN+ocOHZBEwIVw9w/86wJRI1WKegiemcgWmepEZalBzU8bWHQHzKbHd4aIfahfK4OVcYNwPo0K1+5ypE4Jx1Mpg==
указанный выше пароль очищенПосле генерации письма с токеном сброса с использованием метода WebUtility.UrlEncode
и его декодирования обратно в конечную точку ResetPasswordAsync
с использованием WebUtility.UrlDecode
.
Я использовал KDiff3 для подтверждения того, что обе строки токена идентичны, и в AspNetUser есть только один пользовательно токен всегда недействителен, а процесс сброса пароля завершается неудачей.
Класс StartUp.cs не представляет собой ничего особенного, выглядит как пример, приведенный в приведенном выше уроке, который я упомянул, ключевой момент в том, что я добавляю провайдера удостоверенийпри запуске:
services.AddDefaultIdentity<ApplicationUser>(config =>
{
config.SignIn.RequireConfirmedEmail = true;
})
.AddEntityFrameworkStores<AuthContext>();
Это сводит меня с ума, и я потерял уверенность в идентичности ASP.NET Core 2.2 в отношении работы с проектом Web API.Почему я так делаю?В остальном мире не используются MVC или Razor Pages, в наше время все без головы и внешний интерфейс (какой бы он ни был, React, Angular и т. Д.) Потребляет конечные точки, а другая причина в том, что я собираю кучуМикросервисы, расположенные за шлюзом приложений Azure.
Заранее спасибо.