Подтвердить что ты не робот

OmniAuth: защита нескольких учетных записей для одного пользователя

У меня есть несколько приложений Rails, которые я собираюсь интегрировать с OmniAuth, но есть концептуальная проблема, с которой я сталкиваюсь, что я хотел бы выяснить в первую очередь. Рассмотрим следующий сценарий:

  • Ваше приложение Foo поддерживает учетные записи OmniAuth через Twitter и Facebook.
  • Джо приходит на ваш сайт и регистрируется через свою учетную запись Twitter. Это создает нового пользователя в Foo и связывает его с этой новой авторизацией Twitter.
  • Джо выходит из Foo и забывает о сайте в течение шести месяцев.
  • Джо возвращается в Foo, не помня, что он ранее вошел в систему с Twitter.
  • Джо входит в систему с Facebook. Поскольку он еще не авторизовался через свою оригинальную авторизацию Twitter, нет никакого способа обнаружить, что он, фактически, тот же Joe, и создается новая учетная запись.
  • Джо обнаруживает свою старую учетную запись и теперь разочарован тем, что его более старый контент привязан к этой старой учетной записи и что он не может войти в систему с Twitter и Facebook взаимозаменяемо.

Так как Twitter не снабжает Foo адресом электронной почты, универсальный идентификатор не используется для обнаружения того, что два Joes - это тот же Joe. Вы можете принять решение поддерживать только поставщиков, которые предоставляют вам адрес электронной почты пользователя, но это не помогает, если пользователь зарегистрировался с разными адресами электронной почты на разных провайдерах.

Единственное другое решение, о котором я могу думать, - предоставить пользователю способ слияния двух существующих учетных записей. Это большая головная боль по сравнению с относительной легкостью всего остального при использовании OmniAuth. Если это единственное решение, может ли кто-нибудь обратиться к руководству/учебнику, показывающему пример того, как это можно сделать? Я удивлен, что эта проблема не получила большего внимания, учитывая популярность OmniAuth.

Спасибо!

4b9b3361

Ответ 1

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

Ответ 2

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

Полное раскрытие: я не придумал этого, я украл его у кого-то еще в Интернете. Там хорошая запись на вики Omniauth.

Я никогда не нашел хороший способ автоматической связи аккаунтов Facebook/Twitter/etc, но вместо этого сделал так, чтобы пользователь мог связать несколько учетных записей, как только они вошли в систему с первым.

Это сценарий:

  • Пользователь регистрируется, например. Facebook
  • У них есть страница профиля, в которой перечислены социальные сети, которые они подключили к учетной записи, и возможность связать каждый тип с учетной записью
    • например, "Facebook Linked | Link Twitter | Link Google"
  • "Link Twitter", например, ссылки на одно и то же действие omniauth, которое пользователь будет использовать для входа в Twitter.
  • в обработчике обратного вызова, проверьте, зарегистрирован ли пользователь
    • если они есть, сохраните поставщика и uid в отдельной записи для пользователя
    • в противном случае запишите их как обычно

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

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

Ответ 3

Я также столкнулся с этой проблемой сегодня. Я думаю, что я обработаю его следующим образом:

Я буду спрашивать у пользователя их адрес электронной почты и пароль при регистрации, как в традиционной настройке проверки подлинности, где я пытаюсь получить электронное письмо от службы OmniAuth, которую выбрал пользователь (FB, Twitter,...), Поэтому они должны отправлять только электронное письмо, если оно не предоставляется поставщиком auth. Затем, если пользователь подписывается позже с тем же провайдером, который они использовали для регистрации, они будут немедленно зарегистрированы. Это, вероятно, произойдет в 99% случаев.

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

  • Исходный поставщик аутентификации отключен или пользователь удалил свою учетную запись провайдера аутентификации → Решение: пользователь может войти в систему традиционным способом, используя свой адрес электронной почты и пароль. (Обратите внимание, что это важный случай, который я еще не видел нигде в сети. Люди, похоже, предполагают, что FB, Twitter и т.д. Будут навсегда, никогда не будут недоступны, и пользователи никогда не покинут свои аккаунты с теми сервисы. Не сохраняя пользователей pw и email, вы потеряете все свои учетные записи пользователей, которые были сгенерированы провайдером, если один из этих случаев возникнет, поскольку вы не можете больше сопоставить их пользователям. Для меня это неприемлемая зависимость от внешняя служба.)

  • Пользователь регистрируется позже с другим поставщиком проверки подлинности (это ваш случай) → Решение. Попробуйте сопоставить пользователя с существующей учетной записью, используя их электронную почту, если это не удается, отобразите форму регистрации с помощью кнопки /link "У меня уже есть аккаунт, пожалуйста, войдите в систему" ​​(или аналогичный;-). Если они нажмут это, они должны будут указать свой адрес электронной почты и пароль. Затем, если они успешно аутентифицируются, вы можете просто добавить этого провайдера в существующую пользовательскую запись, и в следующий раз, когда они будут зарегистрированы в тот же день, точно так же, как с провайдером, изначально используемым для регистрации...

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

Ответ 4

Я заметил, что Qaru пытается устранить эту проблему в некоторой степени, сохранив предпочтение аутентификации пользователя в cookie и автоматически выполнив вход в систему, когда вы вернетесь на страницу входа.

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