Подтверждение электронных писем для существующих пользователей (адрес электронной почты, используемый кем-то еще, социальный вход) - PullRequest
0 голосов
/ 20 сентября 2018

ЧАСТЬ 1
У меня есть следующий сценарий, и мне было интересно, смогу ли я получить ваши мысли:

  • Джек имеет учетную запись user1 с электронной почтой test@test.com
  • У Джека действительно нет test@test.com или он ошибся при регистрации
  • Приходит Джилл и входит в Facebook test@test.com

Вопросы:

  1. Джилл только получает учетную запись "user1"?потому что в конце концов это ее адрес электронной почты?
  2. Что происходит с Джеком?Неужели он только что потерял свой аккаунт?

PART 2
В настоящее время я конвертирую старое приложение webforms в ядро ​​asp.net, и ястолкнуться с проблемой рабочего процесса больше, чем ошибка.В старом приложении Webforms никогда не было подтвержденных адресов электронной почты.Я хочу при входе в ядро ​​asp.net отправлять письма с подтверждением.Проблема заключается в том, что может быть вероятность того, что некоторые люди использовали поддельные электронные письма, служба электронной почты больше не существует или не использовала адрес электронной почты другого лица (возможно, его опечатка).

Пример
Person1 зарегистрировал учетную запись Person1 с электронной почтой test@test.com (не может подтвердить эту электронную почту)
Person2 хочет подписаться на Person2 по электронной почте test@test.com (так как им действительно принадлежит это письмо, и они могут проверить его)

Вопросы 1) Человек 1 не может подтвердить свою электронную почту, он не сможет войти в систему.

2) Человек 2 не может зарегистрироваться, потому что электронная почта уже получена, Person2 забывает пароль и обнаруживает его'используется Person1 и затем может войти в систему как Person1.Это не идеально, потому что на самом деле это не их учетная запись

Как можно обработать вышеуказанные ситуации?

Ответы [ 2 ]

0 голосов
/ 20 сентября 2018

Я думаю, что логика регистрации должна содержать дополнительные шаги,

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

  • Секретные вопросы: еще одна возможность - использовать дополнительные шаги для сброса пароля, например, секретные вопросы, если он был задан ранее, или вопросы о предыдущих действиях для обеспечениятот, кто сбрасывает пароль, является владельцем учетной записи

Еще один момент - определить период проверки для старых зарегистрированных пользователей:

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

  • В течение этого периода пользователь должен иметь возможность использовать свою учетную запись без ограничений.

  • Те, кто не может проверить свою электронную почту из-за недоступностиэлектронная почта, они могут изменить адрес электронной почты на новый в течение указанного периода.

  • По истечении периода проверки непроверенные учетные записи могут быть приостановлены до тех пор, пока он не будет проверен,затем может быть удалено, если еще не подтверждено.Таким образом, вы также можете очистить базу данных от неиспользуемых учетных записей.

0 голосов
/ 20 сентября 2018

У вас есть выбор, чтобы определить, как эта ситуация будет управляться.Технически, это все ваш выбор, поскольку внешняя аутентификация будет рассматриваться только как внешний токен.Вот имплантация по умолчанию (или, по крайней мере, как она обрабатывается в моем последнем проекте, не помню).

[HttpGet]
[AllowAnonymous]
public async Task<IActionResult> ExternalLoginCallback(string returnUrl = null, string remoteError = null)
{
    if (remoteError != null)
    {
        return RedirectToAction(nameof(Login));
    }
    var info = await _signInManager.GetExternalLoginInfoAsync();
    if (info == null)
    {
        return RedirectToAction(nameof(Login));
    }

    // Sign in the user with this external login provider if the user already has a login.
    var result = await _signInManager.ExternalLoginSignInAsync(info.LoginProvider, info.ProviderKey, isPersistent: false, bypassTwoFactor: true);
    if (result.Succeeded)
    {
        _logger.LogInformation("User logged in with {Name} provider.", info.LoginProvider);
        return RedirectToLocal(returnUrl);
    }
    else
    {
        var email = info.Principal.FindFirstValue(ClaimTypes.Email);
        var isEmailAlreadyPresent = await _userManager.FindByEmailAsync(email);

        if (isEmailAlreadyPresent == null)
        {
            var user = new User { UserName = email, Email = email };
            var createUserResult = await _userManager.CreateAsync(user);
            if (createUserResult.Succeeded)
            {
                createUserResult = await _userManager.AddLoginAsync(user, info);
                if (createUserResult.Succeeded)
                {
                    await _signInManager.SignInAsync(user, isPersistent: false);
                    _logger.LogInformation("User created an account using {Name} provider.", info.LoginProvider);
                    return RedirectToLocal(returnUrl);
                }
            }
        }
        else
        {
            var addLoginAsyncResult = await _userManager.AddLoginAsync(isEmailAlreadyPresent, info);
            if (!result.Succeeded)
            {
            }

            await _signInManager.SignInAsync(isEmailAlreadyPresent, isPersistent: false);
            _logger.LogInformation("User created an account using {Name} provider.", info.LoginProvider);
            return RedirectToLocal(returnUrl);
        }
    }

    return RedirectToLocal(returnUrl);
}

Как вы можете видеть, это действительно зависит от того, как вы хотите реализовать это.И если ваш вопрос касается наилучшего способа сделать это, ну, это зависит от вашей философии.Но уверены ли вы, что такая ситуация будет часто происходить или это ситуация «на всякий случай»?

...