x
 
Тимур Юсупов
8 января 2013

Здравствуйте!

Меня интересует вопрос, связанный с системой регистрации и входа без пароля.

Как я понял, при таком подходе пользователю следует заполнить только поле с электронной почтой. Дальше на указанный адрес посылается ссылка, по которой вход в систему совершается автоматически. В такой ссылке присутствует случайно созданный пароль. Если пользователь получает письмо, он просто переходит по ссылке, и всё готово — он в системе.

Но предположим, что пользователь допустил ошибку в заполнении адреса эл. почты, а такой ошибочный адрес действительно существует. Тогда письмо придёт не тому пользователю на ящик. Этот пользователь перейдёт по ссылке и получит полный доступ к акаунту пользователя, совершившего ошибку.

Что же делать в таком случае? Я мог просто неправильно понять данный подход к осуществлению авторизации пользователя, но мне нравится эта задумка, и поэтому хотелось бы понять, как она действительно работает более детально.



Тимур!

Важно, чтобы во время действия, повлекшего такую прозрачную регистрацию — например, при покупке в интернет-магазине — покупателю уже выдавалась кука, которая позволит его узнавать, даже если он не перейдёт по отправленной ссылке. Тогда, если ссылка уйдёт по почте «злоумышленнику», наш покупатель останется в своём акаунте и сможет поменять почту.

Но что если покупатель поймёт, что ошибся, слишком поздно, и злоумышленник успеет воспользоваться его акаунтом?

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

Интерфейс и информация — дисциплина Школы дизайнеров. Набор открыт. Чем раньше поступите, тем ниже стоимость и выше шанс на бесплатное место.
 

Поделиться
Отправить

Комментарии

Саша Сушко
8 января 2013

Тимур, в какой ситуации почта указывается после ввода данных, об утрате которых вы беспокоитесь?

Что мешает вам «повесить» на сайте предупреждение с текстом «Адрес эл. почты не подтверждён…» и тогда пусть пользователь совершает действия на свой страх и риск, если он не хочет подтверждать адрес своей почты?

Андрей Щербатых
8 января 2013

А кто мешает привязать этот пароль (если я правильно понял, он одноразовый) к айпи посетителя? Тогда при заходе с левого айпи-адреса пароль не сработает. Ведь предполагается, что человек сгенерил себе эту ссылку, и сразу по ней перешёл, и дальше там чё-то пыхтит на сайте.

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

Егор Милюков
9 января 2013

Что-то странное вы говорите мне кажется. Почему нельзя просто проверять соответствие введенного адреса реально существующему пользователю? То есть если пользователь ошибется с адресом, но такого адреса нет в базе юзеров — письмо не уйдёт. А если существует, то ему придет ссылка на вход в его профиль, того чей адрес вбит. В таком случае кому бы не ушла ссылка, она будет вести на вход в его профиль, и никто не сможет войти в чужой.

Алексей Остапенко
9 января 2013

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

Поэтому даже если пользователь ошибся и ввёл не свою эл. почту, это никак не повлияет на его аккаунт в интернет-магазине.

Александр Дебкалюк
9 января 2013

Обощая то, что предложил Илья — давайте пользователю делать максимум на вашем сайте без подтверждения почты, и только для критических операций просите сделать это.

Ещё обратите внимание на альтернативные варианты подтверждения личности — код в смс, код в почтовой открытке (реальный пример с trustcloud.com).


5 марта 2013

Егор, Алексей, никакого «реально существующего пользователя» в базе нет, здесь речь идёт о новом пользователе, а не о восстановлении пароля существующим.


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.





Недавно всплыло

1 1 1 5