2017-02-08 6 views
3

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

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

  • Если я первый использовать Google, после того, как я использую ссылку для сброса пароля теперь я могу пользователь либо поставщик войти в систему, и оба они связаны с тем же firebase uid. Если я отлаживаю, я могу видеть как в массиве providerDetails объекта authData, который я возвращаюсь из Firebase.
  • Если я использую Facebook первым, после того, как я использую ссылку на пароль, поставщик пароля полностью заменяет Facebook, хотя он сохраняет старый firebase uid. На этом этапе я больше не могу использовать вход в Facebook.

Мои вопросы: это поведение предназначено и есть ли способ отключить его?

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

Спасибо

+0

Хороший вопрос, интересующийся персоналом fb! – Pandaiolo

ответ

1

Поведение преднамеренное.

Для конечных пользователей, если они вошли в приложение с помощью Google или Facebook, а затем они хотят восстановить пароль, наиболее вероятная причина заключается в том, что они (или злоумышленники) не могут войти в систему с этим поставщиком удостоверений.

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

В случае, если почтовая служба пользователя совпадает с провайдером идентификации (например, пользователи @ gmail.com входят в приложение с помощью Google), Firebase имеет оптимизацию, чтобы поддерживать поставщика удостоверений, поскольку нет угрозы безопасности.

+0

ОК спасибо. Я подозревал, как много. – John

+0

Одна вещь, чтобы противостоять этому Цзинь: Мы обнаружили, что пользователи не щелкают по ссылке сброса, потому что они не могут войти в систему с помощью Google/Facebook, а потому, что они забыли, какой метод они использовали в первую очередь. Таким образом, они могут восстановить эту ситуацию, используя ссылку сброса, но это действительно запутывает, что они переключаются. Если они действительно не могут войти в систему с помощью Google/Facebook, не было бы более разумным, чтобы они сбросили свой пароль у источника, а не переключили поставщиков в Firebase? – John

+0

Чтобы решить проблему, когда пользователи забывают предыдущий метод входа в систему, FirebaseUI реализует поток идентификатора - сначала, когда пользователь сначала вводит свой адрес электронной почты, а следующая подсказка будет основана на статусе учетной записи (перенаправление на Google/Facebook или существующий пароль , или новая учетная запись). –

 Смежные вопросы

  • Нет связанных вопросов^_^