@beduin01

сложно ли перейти с Loginza на нативной oAuth провайдер?

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

Просто боюсь, что могу столкнуться с проблемами, запустив сайт с логинзой.

Так же подскажите, как лучше всего реализовать связку аккаунтов. К примеру человек входит на сайт через vk, а потом начинает использовать google. Как сделать, чтобы вместо нового аккаунта человек смог бы использовать свой старый?

При этом логично предположить, что если пользователя просить указать все используемые им oAuth провайдеры, он этого может просто не сделать.
  • Вопрос задан
  • 2819 просмотров
Пригласить эксперта
Ответы на вопрос 2
EnChikiben
@EnChikiben
Думаю отказ ни так страшен, вам просто надо будет написать так сказать свою логинзу :) но с учетом того что Вы данные полученные от Loginza сейчас будете сохранять в БД. Потом просто работайте с ними.
А вот по связке аккаунтов я бы сделал в профиле что то на подобии общей странице аккаунтов пользователя и если надо то он прицепляет их к профилю если нет то нет. Т.е. структура бд должна содержать таблицу профиль пользователя и к ней уже подцепляются внешние аккаунты. Главное хорошо продумать модель хранения, а потом на неё уже опираться. Но задача не такая и уж сложная.
Ответ написан
Комментировать
@CrazyRad
Web Developer
Для связки акаунтов я бы предложил такую логику: пользователь логинится используя нового oAuth провайдера, для него создаётся новый акаунт. Во время логина система получает базовые данные пользователя (имя, фамилию, email). Нужно уведомить пользователя, что для него создан новый акаунт, но если он уже тут логинился под другим провайдером, то он может связать свой новый акаунт со старым. Если по совпадению имени + фамилии или email-у находится другой акаунт в системе тут же предлагается связать акаунты. Для подтверждения что тот акаунт принадлежит пользователю нужно залогиниться используя тот oAuth который он использовал раньше. Если пользователь не может это сделать, надо предоставить другой вариант, например указать ответ на секретный вопрос заданый на вашем сайте или вспомнить другие данные акаунта на ваше усмотрение, чтобы быть увереным, что это не однофамилец. Самый крайний случай — кнопка «сообщить в support» которая отправит сообщение администратору о том, что пользователь хочет связать два акаунта, чтобы это связку проверил и сделал человек.

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы