Комментарии 37
Подозреваю, что-то подобное со временем получится у Google (наверное в первую очередь для GoogleOS)
В классическом способе не раскрыт вариант использования e-mail вместо логина. Что практически сразу избавляет его от всех минусов вроде запоминания логина/занятости логина другим человеком.
Лучший вариант — комбинированный email/pass + openid
Лучший вариант — комбинированный email/pass + openid
Авторизация и аутентификация — это не одно и то же.
а еще после регистрации система сама может авторизовывать пользователя, это гораздо удобнее конечному…
Предлагаю рассмотреть такой способ:
— Для регистрации или регистрации пользователь указывает только e-mail
— Генерируем рандомный пароль и сохраняем email и пароль в БД
— На указанный e-mail приходит ссылка для входа на сайт
При такой схеме пользователю не нужно помнить лишнюю информацию, только свой e-mail. Регистрация также очень проста.
— Для регистрации или регистрации пользователь указывает только e-mail
— Генерируем рандомный пароль и сохраняем email и пароль в БД
— На указанный e-mail приходит ссылка для входа на сайт
При такой схеме пользователю не нужно помнить лишнюю информацию, только свой e-mail. Регистрация также очень проста.
Для входа каждый раз предлагается порыться в почте?
К сожалению, когда вы зайдете с другого компьютера вам опять придется авторизироваться — а следовательно вспоминать хотя бы пароль.
Вы не поняли, пользователь вообще не знает своего пароля. Для авторизации ему нужно ввести e-mail на сайте, в ответ ему придёт ссылка (вида site.ru/login.php?email=info@mail.ru&password=12345), по которой он переходит и сайт его авторизует.
Если ему нужно авторизоваться с другого компьютера — он опять вводит e-mail, получает ссылку и переходит по ней.
Если ему нужно авторизоваться с другого компьютера — он опять вводит e-mail, получает ссылку и переходит по ней.
Мне кажется это несколько тернисто, возможно я не прав, но почему-то уверен, что мне было бы неудобно.
Не жизнеспособно.
Предполагаем ситуацию: есть рабочий e-mail. Доступа к нему через web-интерфейс нету — только почтовый клиент.
В гостях я не смогу войти под своим логином — нужно ставить почтовый клиент. С мобильного телефона быстро войти не смогу.
Да и в остальных случаях мне рано или поздно надоест необходимость постоянно заходить в почту, чтобы авторизоваться.
Вообще такой способ ничуть не проще тычки «забыли пароль». Точно так же придет ссылка на емайл.
Предполагаем ситуацию: есть рабочий e-mail. Доступа к нему через web-интерфейс нету — только почтовый клиент.
В гостях я не смогу войти под своим логином — нужно ставить почтовый клиент. С мобильного телефона быстро войти не смогу.
Да и в остальных случаях мне рано или поздно надоест необходимость постоянно заходить в почту, чтобы авторизоваться.
Вообще такой способ ничуть не проще тычки «забыли пароль». Точно так же придет ссылка на емайл.
Да, это по-сути тоже самое, что «вспомнить пароль», однако в моём случае есть два преимущества:
— пользователю не нужно придумывать и помнить пароль
— пароль генерируется системой, а значит он намного более стойкий
Случай который вы описали не позволит авторизоваться, но я думаю что это исключительный случай.
— пользователю не нужно придумывать и помнить пароль
— пароль генерируется системой, а значит он намного более стойкий
Случай который вы описали не позволит авторизоваться, но я думаю что это исключительный случай.
Ну модифицируем алгоритм восстановления пароля:
На емайл приходит новый пароль, сгенерированный системой и ссылка.
После перехода по ссылке пользователь активирует новый пароль и автоматически логинится. Если захочет сменить пароль — может сделать это в профиле.
Итого имеем — классический способ, проверенный временем, и неудобную плюшку, которая может кому-то понравится. :)
На емайл приходит новый пароль, сгенерированный системой и ссылка.
После перехода по ссылке пользователь активирует новый пароль и автоматически логинится. Если захочет сменить пароль — может сделать это в профиле.
Итого имеем — классический способ, проверенный временем, и неудобную плюшку, которая может кому-то понравится. :)
А в чём вы видите неудобство?
(кроме ситуации когда нет доступа к почте, ибо я считаю это надуманным)
(кроме ситуации когда нет доступа к почте, ибо я считаю это надуманным)
Ну во-первых ситуация с почтой не надумана.
Например, у меня на работе:
За почтой следит Microsoft Exchange Server, аутентификация через Kerberos. Соответственно, чтобы открыть почту нужно быть в домене active directory. Т.е. из дома я этого сделать не смогу. (коннект через imap или web-интерфейс тоже возможен, но для этого нужно получить отдельный пароль у админа)
Во-вторых: я, например, дома редко проверяю почту — там не может быть ничего срочного и архиважного (для этого есть есть другие средства коммуникации). Открывать каждый раз почту из-за такого сайта я не буду.
В общем:
Я не вижу смысла заменять классический и привычный подход инновационным, если их можно совместить так, что ни один не потеряет в удобстве (что я и показал выше).
Например, у меня на работе:
За почтой следит Microsoft Exchange Server, аутентификация через Kerberos. Соответственно, чтобы открыть почту нужно быть в домене active directory. Т.е. из дома я этого сделать не смогу. (коннект через imap или web-интерфейс тоже возможен, но для этого нужно получить отдельный пароль у админа)
Во-вторых: я, например, дома редко проверяю почту — там не может быть ничего срочного и архиважного (для этого есть есть другие средства коммуникации). Открывать каждый раз почту из-за такого сайта я не буду.
В общем:
Я не вижу смысла заменять классический и привычный подход инновационным, если их можно совместить так, что ни один не потеряет в удобстве (что я и показал выше).
Если все OpenID провайдеры будут в обязательном порядке использовать хотя бы минимальный набор sreg/ax атрибутов, необходимых для регистрации на разных ресурсах (т.е. как минимум email), то проблем станет сильно меньше. А то толку от OpenID, если ты в итоге о человеке ничего вообще не знаешь и все равно приходится заставлять его вводить хотя бы ник и почту…
не могу согласиться с автором по поводу «отсутствие поддержки со стороны крупных и популярных ресурсов» — например такие крупные игроки поддерживают openid — google, yahoo, livejournal и это еще далеко не все
Подобный комментарий уже был, но я все же напишу еще раз, более развернуто.
В статье обсуждается процесс аутентификации — «узнавания» пользователя.
А авторизация — это процесс определения прав пользователя: например, один пользователь, написавший статью, может ее редактировать, остальные могут только комментировать ее. А Администратор может ее скрыть.
В статье обсуждается процесс аутентификации — «узнавания» пользователя.
А авторизация — это процесс определения прав пользователя: например, один пользователь, написавший статью, может ее редактировать, остальные могут только комментировать ее. А Администратор может ее скрыть.
Спасибо, тем не менее здесь рассматриваются эти два понятия как смежные, а регистрация пользователя так и вообще может рассматриваться как часть и аутентификации и авторизации, с одной стороны мы «узнаем» пользователя, с другой стороны — пользователь получает привилегии зарегистрированного т.е. авторизируется.
Для «золотой середины» обновил теги
Конечно эти понятия смежные, но, возможно по невнимательности, я не увидел ни слова про авторизацию. Все же в статье речь идет исключительно об аутентификации. А «привилегии зарегистрированного [пользователя]» могут быть очень разными и именно этим и занимается авторизация.
Я просто хочу посоветовать немного переименовать статью, т.к. я открыл статью в надежде почитать про одно, а здесь — про другое.
Я просто хочу посоветовать немного переименовать статью, т.к. я открыл статью в надежде почитать про одно, а здесь — про другое.
Возможно просто браузер может взять на себя функцию удостоверения пользователя на сайтах. Уже сейчас многие доверяют пароли, закладки и прочую информацию разработчикам браузеров. Тогда просто отпадут все эти формы бесконечные. Заходишь на любой сайт, браузер сообщает твой id и подтверждающие данные в формате одной из систем, с которой он работает, сайт проверяет id на сервисе системы, получает открытую публичную информацию о тебе, и ты уже залогинен, даже если зашел на сайт первый раз. Но, конечно здесь исчезает тайна личной жизни.
Я тоже о подобном думал. Но необязательно слать какой-то id сайту всегда. Пусть это будет немного модифицированый OpenID. Есть какойто сервис (service.com). Регаемся на нем, и я получаю id — kastigar@service.com (не обязательно мыло, но в том же формате). Далее логинимся в браузере (с помощью экстеншена, например, если браузер не поддерживает нативно). Теперь на любом сайте site.com вводим наш айди kastigar@service.com, site.com шлет на service.com, что kastigar хочет авторизироваться и урл авторизации. Теперь экстешен/браузер получает от service.com ссылку авторизации и идет туда.
Вобщем сумбурно и не оптимизировано, но как-то так. По сути мы не шлем какой-то id всем сайтам, по которому можно получить публичные даные, но и не нужно авторизироватся на сайте провайдера openID (избегаем возможности фишинга).
Вобщем сумбурно и не оптимизировано, но как-то так. По сути мы не шлем какой-то id всем сайтам, по которому можно получить публичные даные, но и не нужно авторизироватся на сайте провайдера openID (избегаем возможности фишинга).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Рассуждение на тему аутентификации