Авторизация: Логин/Пароль или E-mail/Пароль
Anatoly Shikhov
Сегодня на работе возникла дискуссия.
Какой способ авторизации, Логин/Пароль или E-mail/Пароль, лучше
применить в разрабатываемой системе, ориентированной одновременно на
B2C и B2B клиентов?
Система пока что предоставляет доступ в личный кабинет. Однако в
будущем, от имени B2C клиентов могут публиковаться отзывы в публичной
части портала.
В общем, здесь суть не в системе, а во взвешивании, у какого из
подходов наиболее существенные слабые места.
После непродолжительного сравнения наиболее слабым подходом оказался E-
mail/Пароль.
Здесь приведены аргументы: http://www.ahatur.com/concept-design/login-password-or-email-password
Метод авторизации по E-mail/Пароль использует Google.
Однако, считаю неоправданным копировать такой подход лишь потому, что
это известная компания.
Думается, они так делают исходя из собственной цели.
Vladimir
номеру телефона.
А можно подход озона с авторизацией по логину, который при регистрации
есть e-mail и может быть изменен после.
У e-mail/номер-телефона авторизации есть всего два плюса:
1) Не надо думать;
2) Не надо помнить пароль, его всегда можно запросить.
По аргументам:
> 1. Если в конторе у нескольких сотрудников один e-mail...
Решается созданием "гостевых" учеток с различными паролями, прямо из
главной.
> 2. Если сотрудник уволился из организации...
Можно при увольнении стирать память. Или для юриков можно привязывать
учетку к реквизитам, а не к e-mail.
> 3. Если выводить логины в блог
При попытке написать куда-либо можно навязчиво спросить под каким
именем публиковать ответы. Это избавит от логинов вида Петя123.
> 4. Злоумышленник сможет проверить не зареган ли его сотрудник
Вывести текст "Для продолжения операции следуйте инструкции
отправленной вам на почтовый ящик", а на почту послать "логин уже
существует, воспользоваться системой восстановления пароля".
Anatoly Shikhov
Пожалуйста уточните насчет "гостевых" учетных записей с различными
паролями.
Как их можно хранить в базе если каждый пароль хранится в отдельной
записи, ключом которой является E-mail.
Ведь не верно дублировать ключи, да и СУБД этого не позволит.
Кроме этого требуется наворачивать функциональность по созданию этих
самых гостевых учеток.
Хотя в погоне за преимуществами подхода авторизации по E-mail можно и
потратиться на доработку.
Vladimir
Исходить можно из того, что учетной записью является пара логин-
пароль. Где все учетные запись с одинаковым логином (в пределе может и
разными) являются частью одной мастер-записи. При этом у мастер-записи
есть некая админ-запись из обычных записей.
Варианты которые при этом приходят на ум:
1) Ключом может являться и пара значений (логин, пароль), придется
добавить поле с правами на изменение списка учетных записей;
2) Добавить таблицу паролей (id-учетки, пароль, права доступа, видимое
имя);
3) Добавить несколько полей с паролями (директор, бухгалтер и тд).
Наворачивать при этом действительно придется много.
Alexey Pankov
Вы смешиваете в одну кучу e-mail'ы ролевые - sales@, support@, director@ и персональные - vasya.pupkin@, ivan.gavrilov@, и из этого возникают мешающие вам коллизии.
Адреса первого рода сотрудник при увольнении из компании увести не может. А "уход" адресов второго рода никаких негативных последствий иметь не должен.
Если сотрудник (или несколько сотрудников) какой-то организации пользуются одним ролевым e-mail'ом, это означает, что через этот e-mail, и через учетную запись на вашем сервиса, зарегистрированную на этот e-mail, они должны выражать точку зрения своей организации, а не свою личную. Увольнение какого-то сотрудника ничто не меняет. E-mail остается за компанией, и его получит другой человек.
Положительный пример: Озон вполне позволяет изменить e-mail, используемый для авторизации.
Отрицательный: Не знаю, как сейчас, а раньше то ли на E-Bay, то ли на PayPal нельзя было зарегистрироваться, используя бесплатный e-mail (hotmail, gmail etc.). "Разрешались" только проверенные корпоративные e-mail'ы. И изменить этот адрес было нельзя. Поэтому при увольнении твой аккаунт пропадал.
Получается, что это как бы спич в защиту e-mail'ов. Но это не так.
Я за то, чтобы давать людям все возможные способы авторизации - по логину, по ФИО, по e-mail'у, по номеру ICQ, по номеру телефона, по любому Open ID, по отпечатку пальца, в конце концов. И пусть они пользуются тем, который им удобен. И, конечно, же "подпись" в блогах и на форумах не должна тупо браться из поля "логин". Впрочем, по счастью, таких форумов, где это не так, уже почти не осталось. Так что и вам не стоит опасаться этой проблемы.
Кирилл Тимофеев
------------------------------
With best regards, Kirill Timofeev
--
Вы являетесь подписчиком группы User Experience Russia.
Чтобы отправить сообщение в группу, используйте адрес
uxru...@googlegroups.com
Изменить настройки участия можно по ссылке - http://groups.google.com/group/uxrussia/subscribe
Домашняя страница группы: http://groups.google.com/group/uxrussia
IgrOK
Логин вообще нужен только в том случае, если пользователи могут
общаться между собой. Или что-то публиковать для других. Иначе он ни к
чему.
Если решили, что логин нужен -- допускаете вход и по логину, и по
мейлу. Так и пишете "логин или email".
Anatoly Shikhov
>
> Логин вообще нужен только в том случае, если пользователи могут
> общаться между собой. Или что-то публиковать для других. Иначе он ни к
> чему.
> Если решили, что логин нужен -- допускаете вход и по логину, и по
> мейлу. Так и пишете "логин или email".
Да, пожалуй это наиболее гармоничное решение.