Какова наилучшая практика регистрации omniauth & email-пароля?

Question

Как лучше всего объединить вход в Facebook (скажем, я буду использовать гем Omniauth) и адрес электронной почты + пароль?

Я видел несколько блогов, видел Railscasts, я знаю, что все используют Deviseдрагоценный камень с Omniauth.Но я ищу какую-то другую точку зрения.

подвопросы:

Я подумываю создать электронную почту + зарегистрировать пароль с нуля (для этого не используется никакой драгоценный камень), давайте держать это быстро и легко) так что у вас есть какие-либо советы для этого?Или, если вы имеете в виду какой-то конкретный драгоценный камень, пожалуйста, пусть он будет быстрым.

И есть ли у вас какие-либо другие рекомендации по использованию драгоценных камней Oauth2 (альтернативы Omniauth) для аутентификации в Facebook?

Извините, я задаю эти фундаментальные вопросы здесь, но я не нашел много ответов (и большинство из них, которые я нашел, основаны на Devise)

Answer 1

Так я видел, как это делается в большинстве примеров в Интернете

в основном, когда вы регистрируетесь по электронной почте + пароль, вы создаете строку непосредственно для модели пользователя (не касаясь модели Authent.), А при регистрации в Omniauth вы создаете новую аутентификацию, которая связывается с моделью пользователя.

И в основном при следующем входе в систему вы делаете что-то вроде этого:

 if (user.password == 'xxx')
    login
 elsif user.authentication.uid == 'xxx'
    login
 else
    'hello signup !'
 end

так что вы переключаетесь между двумя моделями и изнасилуете (простите за термин), что пользовательская модель должна содержать только пользовательскую информацию

Решение, в некотором смысле, я считаю правильным (из моего опыта и бесед с моими коллегами, но я все еще не уверен на 100%, что это правильный ответ)

как видите, даже пользователь + пароль проходит через Authent. модель, это означает, что пользователь + пароль на сайте выступает в роли поставщика самостоятельно

так, чтобы быть абсолютно правильным, это должно выглядеть так

• сценарий 1

регистрация с FB : вы сохраняете идентификатор FB и authKey в таблице аутентификации, затем создаете пользователя

• сценарий 2

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

Почему?

потому что теперь, когда пользователь входит в систему, всегда происходит через Authent. модель, не устанавливающая условия между двумя моделями (модель Authent. и User)

теперь может кто-нибудь сказать, пожалуйста ... это хороший подход: D?

Answer 2

Intridea предлагает стратегию использования электронной почты и пароля, чтобы: https://github.com/intridea/omniauth-identity

: -)

Answer 3

Omniauth великолепен, поэтому вам, вероятно, следует использовать его для любых / всех входов в социальные сети.

Что касается настройки собственной аутентификации, это не должно быть слишком сложно.У Райана Бейтса есть отличный скринкаст на эту тему: Аутентификация с нуля

Вот очень хорошая статья о всеведении (хотя вам придется адаптировать ее к своей таблице пользователей, но она все равно отличный ресурс) Грохот Омниавта .Обратите внимание, что я считаю, что автор статьи использует термин авторизация в неправильном контексте здесь.Omniauth не имеет ничего общего с авторизацией, только с аутентификацией, и это тонкое, но очень важное отличие.

Answer 4

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

Проблема в том, что я пытаюсь объединить свои функции аутентификации с функциональностью входа в систему / регистрации.Ведьма - это два разных поведения.По окончании регистрации в FB с помощью omniauth в таблице аутентификации у вас будет идентификатор пользователя Facebook, и это все, что нужно для повторного входа в FB в следующий раз (конечно, вы можете хранить другую информацию (например, электронную почту) ...но по логике они больше атрибутов пользователей и должны идти в таблицу пользователей).

note: its ok to  store user information from provider, in Authentication table,
but if you want to work with them you should  copy these informations to Users table

Когда вы регистрируетесь с помощью решения электронной почты / пароля, вы пишете информацию, которая определяет пользователя на вашем сайте.(Аутентификация просто указывает на пользователя) Если бы мы хотели выполнить регистрацию пароля через таблицу аутентификации, нам пришлось бы хранить имя пользователя и пароль в таблице аутентификаций, и таким образом объединить модель пользователя и аутентификацию в одну модель.Это будет гораздо более уродливое решение, не говоря уже о проблеме, как хранить несколько строк одному пользователю.Аутентификация или Oauth также являются синонимами «доступа к вашему приложению через другой сайт» (смотрите эти видео oauth2, если вы не можете себе это представить http://www.youtube.com/view_play_list?p… 0139F609), но при обычном входе в систему вы получаете прямой доступ к сайту.*

Единственный способ обойти эту проблему - создать небольшое приложение, которое будет обрабатывать электронную почту / пароль или регистрацию пользователя / пароля, генерировать UID провайдера паролей и записывать эти данные в таблицу Users.запросит через omniauth доступ к miniapp и сохранит UID в таблице аутентификаций.

http://eq8scrapbook.heroku.com/equivalents_article/on_omniauth_and_password_login_best_practice

Answer 5

Вот ссылка на страницу панели инструментов ruby ​​для самых популярных гемов аутентификации: http://ruby -toolbox.com / Categories / rails_authentication.html . Вы, вероятно, не сможете найти именно ту функциональность, которую ищете, прямо из коробки с любым из решений.

Не думаю, что вы правы в том, что использование разных методов аутентификации для разных таблиц приведет к чрезмерной нагрузке (возможно, лучшему термину) для моделей.

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

Если вы работаете над текущим проектом со многими тысячами одновременно работающих пользователей, которые испытывают трудности с масштабированием, игнорируйте мой совет, поскольку я не знаком с такими проблемами.