Comments 175
спасибо, много полезного, взял на заметку.
Самым логичным мне кажется использовать всегда вместо логина email ибо он не повторяется, а в настройках аккаунта уже потом давать возможность выбрать более короткий логин с проверкой на доступность.
Мне кажется логичным вообще не спрашивать у пользователя почту если он не хочет подписываться на рассылку.
А если пароль забудет?—можно еще регистрировать по номеру мобильного, и логин уникальный и восстановить по СМС можно.
Лишняя морока с прикруткой смс к сайту — и расходы дополнительные. ИМХО или email или MemberID — очень хорошая практика, а + сюда чтонить опенИДешное, то забыть столько — это уже болезнью Альцгеймера попахивает :)
> «А если пароль забудет?»
А если пароль от почты забудет?
А если пароль от почты забудет?
С чем не согласны те, кто минусует?
Получается Вы согласны с тем, что пользователь может забыть пароль от Вашего ресурса, но при этом не согласны с тем, что он может забыть пароль от почты.
Получается Вы согласны с тем, что пользователь может забыть пароль от Вашего ресурса, но при этом не согласны с тем, что он может забыть пароль от почты.
конечно может забыть, но почтой пользователи пользуются значительно чаще, поэтому вероятность того, что пароль от почты будет забыт меньше. Исключение составляет, пожалуй, только случай, если пользователь зарегистрировался на Вашем сайте указав при этом адрес своей так называемой «спам-почты», но как показывает практика такие пользователи, в абсолютном большинстве бесполезны для ресурса
Минусовать надо вредительские комментарии -а не комментарии, с которыми ты не согласен.
На мой взгляд, учитывая показывалку пароля, на которой так сильно настаивает автор, тут обсуждается крайне несекъюрный сайт для людей с интеллектом уровня аквариумной рыбки. Поэтому почту спрашивать смысла нет, если он забудет пароль — ума его восстановить скорее всего не хватит. А если хватит, то хватит и ума предусмотреть такой вариант и указать мыло опционально.
Действительно, звездочка вместо буквы сразу дает +500 к security.
Тут речь про упрощение регистрации как таковой. Меня лично бесят длинные простыни «Введите дату рождения, пол, возраст, любимое блюдо и как зовут вашу рыбку». Анекту можно ненавязчиво попросить заполнить позже.
При чем тут секурность? Если человек с интеллектом уровня аквариумной рыбки, то звездочки не спасут от того же троянца или кейлоггера.
При чем тут секурность? Если человек с интеллектом уровня аквариумной рыбки, то звездочки не спасут от того же троянца или кейлоггера.
Думаю в некоторых ситуациях логично требовать реальный адрес эл. почты для верификации регистрирующегося пользователя (как мера проти фейк юзеров).
А вообще, надо действовать исходя из ситуации. Например, в одном проекте мы специально не сделали вход по email, чтобы пользователь вводя при каждом входе свой никнейм запомнил его, потому что на никнейм было много чего привязано…
А вообще, надо действовать исходя из ситуации. Например, в одном проекте мы специально не сделали вход по email, чтобы пользователь вводя при каждом входе свой никнейм запомнил его, потому что на никнейм было много чего привязано…
Спасибо за перевод. Очень понравилось, что можно читать только заголовки и смотреть картинки, при этом практически ничего не теряя из смысловой составляющей статьи.
А под Wordpress есть какие-то плагины, имеющие какие-то из вышеперечисленных элементов упрощения регистрации?
За перевод спасибо, а вот автору статьи, я бы поставил жирный минус! Так как догматизм вместо анализа зачастую поражает:
Почему кнопка логина должна быть такой же как и поля? Любишь симметрию — иди к кубистам и идеалистам.
Копировать адрес из платежных форм вообще нужно трансформировать в «доступность данных» и сформулировать так: позвольте пользователям использовать данные многократно — введите историю запросов, операций или действий (по желанию), предлагайте запомнить значения полей, в виде именованного шаблона. и т.п.
Почему кнопка логина должна быть такой же как и поля? Любишь симметрию — иди к кубистам и идеалистам.
Копировать адрес из платежных форм вообще нужно трансформировать в «доступность данных» и сформулировать так: позвольте пользователям использовать данные многократно — введите историю запросов, операций или действий (по желанию), предлагайте запомнить значения полей, в виде именованного шаблона. и т.п.
Я думаю это инструкция для тех, кто делает маленькие и невидимые кнопки. =) Чтобы уж наверняка.
Привыкли то может и все, но надо приучать людей к простоте интерфейсов А кстати давайте посчитаем коэфициент стояния кого-то за спиной во время регистрации.
Надеюсь, что сбербанк прочитает эту статью.
Надеюсь, что сбербанк прочитает эту статью.
Я так понимаю это ответ на мой комментарий. =)
Но вот про «приучать» не совсем верно. Заходя на сайт я совсем не хочу, чтобы меня кто то приучал. Решение с двумя полями универсально. И правильность пароля проверяется и никто не подсмотрит. Напирмер, во многих офисах рабочие места расположены так, что коллеги легко видят твой монитор (пассивный файрволл от развлекательных сайтов =). Да и этот чекбокс мне совсем не поможет сверить пароль, если он состоит из русских слов набранных на ангийской раскладке. Возможно еще сгодится для счастливых англоязычных людей с одной раскладкой клавиатуры.
Но вот про «приучать» не совсем верно. Заходя на сайт я совсем не хочу, чтобы меня кто то приучал. Решение с двумя полями универсально. И правильность пароля проверяется и никто не подсмотрит. Напирмер, во многих офисах рабочие места расположены так, что коллеги легко видят твой монитор (пассивный файрволл от развлекательных сайтов =). Да и этот чекбокс мне совсем не поможет сверить пароль, если он состоит из русских слов набранных на ангийской раскладке. Возможно еще сгодится для счастливых англоязычных людей с одной раскладкой клавиатуры.
Это удобно. Как вариант можно делать кнопку около поля ввода пароля, но чтобы совокупная ширина была равна полю логина.
Хотя можно их и разной формы сделать, или в другой конец страницы запихнуть
Хотя можно их и разной формы сделать, или в другой конец страницы запихнуть
По поводу большой кнопки.
Закон Фиттса никто не отменял.
Закон Фиттса никто не отменял.
С паролем мне кажется не совем верное решение. Во-первых все привыкли вводить пароль два раза, а во-вторых если у меня стоит человек за спиной во время регистрации это решение не даст мне возможности убедиться в правильности пароля. На мой взгляд, более разумное решение будет галочкой или радио-боксом дать возможность выбора между двумя способами ввода.
И с вопросиком тоже не понятно. Вопросик у поля подрозоумевает справку о том зачем нужно поле. А фраза Забыли пароль(Forgot password) всегда понятна и не вызывает лишних вопросов. Тем более для американской публики, у них и дорожные знаки в основном словами и фразами.
И с вопросиком тоже не понятно. Вопросик у поля подрозоумевает справку о том зачем нужно поле. А фраза Забыли пароль(Forgot password) всегда понятна и не вызывает лишних вопросов. Тем более для американской публики, у них и дорожные знаки в основном словами и фразами.
Насчет одного поля для пароля у меня есть еще такое соображение: лично я визуально могу определить цель заполнения формы по количеству полей, а если всего два поля будут присутствовать и при регистрации и при авторизации, то это вызовет легкое недоумение. Пример хороших форм для этого случая — http://mind42.com/signin.
Поддерживаю. Вы заполняли форму, заполнили пароль, зазвонил телефон, вы встали из-за стола и, не залочили комп по какой-то из причин. Любой может посмотреть, что же это вы там за пароль придумали. Очень секьюрно! :/
Пришел и поменял пароль.
Вокруг одни параноики.
Вокруг одни параноики.
Продолжим мысль. Интересно, как вы обезопаситесь от терморектального криптоанализа? Насколько «секьюрно»? :) Это же тоже вполне вероятно, правда?
Возникла срочная необходимость отлучиться — сотри пароль и все дела!
Не нужно выдумывать проблемы на пустом месте.
Возникла срочная необходимость отлучиться — сотри пароль и все дела!
Не нужно выдумывать проблемы на пустом месте.
Вы часто встаете из-за стола и не блокируете компьютер?
Если всё происходит на работе, то я всегда блокирую, военный объект всё-таки.
А если глубже копнуть? Что в рабочие часы мы делаем на НЕ рабочих сайтах?
А если глубже копнуть? Что в рабочие часы мы делаем на НЕ рабочих сайтах?
Могу поспорить, что у вас были случаи, когда вы не блокировали комп.
У меня работа связана с посещением других ресурсов. Мне это необходимо для развития.
У меня работа связана с посещением других ресурсов. Мне это необходимо для развития.
Лучше не спорить. У нас политика строгая в этом плане и НАТО требует жёстких мер безопасности.
— Компы блокируются после 2х минут неиспользования.
— Пароли меняются каждые 2 недели, не могут быть похожими на 6 предыдущих, иметь цифры, буквы и спец символы, хотя бы 1 заглавную
— Для перемещения по фирме, бэдж должен быть всегда на груди
— Для открытия сессии нужен бэдж
— Компы блокируются после 2х минут неиспользования.
— Пароли меняются каждые 2 недели, не могут быть похожими на 6 предыдущих, иметь цифры, буквы и спец символы, хотя бы 1 заглавную
— Для перемещения по фирме, бэдж должен быть всегда на груди
— Для открытия сессии нужен бэдж
Да я его вообще не блокирую!
У меня нет паранойи и какой-либо секретной информации. :)
У меня нет паранойи и какой-либо секретной информации. :)
Люди забыли об общении! Можно голосовым кправлением попросить того, кто стоит за спиной отвернуться на минутку :)
На мой взгляд, более разумное решение будет галочкой или радио-боксом дать возможность выбора между двумя способами ввода.
Не вполне понятный способ. Например, распространённый юзкейс, когда удобно после проверки пароля скрыть его обратно чтобы он не мозолил глаза при дальнейшем заполнении формы. При этом поле подтверждения пароля очевидно будет мешать, что сводит на нет ценность такого универсального метода.
По-моему, это слишком перегружает такую простую операцию.
Я считаю что лучше называть ссылку не «забыли парооль?», а «восстановить пароль». Это конкретное действие, а не вопрос.
Автор молодец, перевел отличную статью с прекрасными примерами «Как надо делать».
> Спамботы не могут взаимодействовать с объектами Javascript на стороне клиента, это может сделать только пользователь.
Что мешает автору бота один раз зайти на сайт, вручную отправить форму, скопировать параметры POST-запроса, а затем просто напрямую слать другие подобные запросы напрямую, минуя форму? Как написано — капчи уже нет.
Что мешает автору бота один раз зайти на сайт, вручную отправить форму, скопировать параметры POST-запроса, а затем просто напрямую слать другие подобные запросы напрямую, минуя форму? Как написано — капчи уже нет.
То же самое с сокрытием поля. Не думаю, что спам-бот — некое универсальное орудие зла и подстраивается под конкретный интернет-ресурс, что подразумевает посещение сайта инициатором спам-атаки и ознакомлением с формой регистрации (до атаки или же после неудач).
мешает то, что название генерируемого поля будет каждый раз разным
Что мешает выяснить необходимые поля, заполнять их и игнорировать все остальные?
яваскрипт генерирует поле со случайным названием
сервер проверяет присутствие этого поля в запросе
как вы будете его игнорировать?
сервер проверяет присутствие этого поля в запросе
как вы будете его игнорировать?
Спасибо, понял.
Что мешает прикрутить node.js или что-то подобное к спам боту? Мне кажется, что это гораздо проще чем OCR простой капчи, которое уже есть у многих ботов.
На сервер нужно отправить поля A, B, C и некое динамическое D..Z. Что мешает получить из сраницы это название и отправить его вместе с A, B, C? Хорошо, допустим, название поля генерируется JS. Оправляем данные через прокси-сервер, который чистит все поля, названия которых не совпадают с эталонными. Где сложность взлома?
честно говоря я вас не понял
зачем чистить поля, если сервер как раз проверяет наличие нужного поля в запросе, а не его отсутствие?
а название этого поля каждый раз разное, что-то типа «xd35fhbh235»
зачем чистить поля, если сервер как раз проверяет наличие нужного поля в запросе, а не его отсутствие?
а название этого поля каждый раз разное, что-то типа «xd35fhbh235»
На сайте был пример кода
if(!String.IsNullOrEmpty(Request.Form[«body»]))
Что-то мне говорит, что отсутствие этого поля аналогично проверке наличия пустого поля.
Да и настроив бота заполнять только A, B, C, игнорируя все остальные поля, капча сработает как надо. И пофиг как называется поле, оно уйдет пустым.
if(!String.IsNullOrEmpty(Request.Form[«body»]))
Что-то мне говорит, что отсутствие этого поля аналогично проверке наличия пустого поля.
Да и настроив бота заполнять только A, B, C, игнорируя все остальные поля, капча сработает как надо. И пофиг как называется поле, оно уйдет пустым.
>И пофиг как называется поле, оно уйдет пустым
дак никуда оно не уйдет, его просто не будет, если бот не умеет выполнять JS
объясняю на пальцах:
1. в разметке формы есть только поля A, B, C.
2. Поля D там нет, оно создается яваскриптом (оно не пустое, его просто НЕТ)
3. сервер делает такую проверку: if (!isset($_POST['D'])){ exit; }
бот не может выполнять JS, соответственно в его запросе поля D не будет и сервер не пустит форму
так вот, выше человек спросил что же тогда мешает автору бота зайти на сайт и подсмотреть название этого поля D, чтобы потом вставить его вручную? а мешает то, что это поле не всегда называется D, а каждый раз имеет разное название
дак никуда оно не уйдет, его просто не будет, если бот не умеет выполнять JS
объясняю на пальцах:
1. в разметке формы есть только поля A, B, C.
2. Поля D там нет, оно создается яваскриптом (оно не пустое, его просто НЕТ)
3. сервер делает такую проверку: if (!isset($_POST['D'])){ exit; }
бот не может выполнять JS, соответственно в его запросе поля D не будет и сервер не пустит форму
так вот, выше человек спросил что же тогда мешает автору бота зайти на сайт и подсмотреть название этого поля D, чтобы потом вставить его вручную? а мешает то, что это поле не всегда называется D, а каждый раз имеет разное название
Для такого случая запускаем бота-браузерного-кликуна, он вставляет нужные данные в форму, которую отрендерил браузер и нажимает на кнопку Send. Никаких проблем. Даже напрягаться не надо
Откуда сервер узнает очередное случайное имя, сгенерированное js, которое нужно проверить в текущем запросе?
сервер сам создает этот JS-код, например, и пропускает через обфускатор
с уже вшитым именем поля?
да, но не в явном виде
вшивается какой-то коэффициент, на основании которого генерируется имя поля
сам алгоритм генерации обфусцирован
И да, я понимаю что злой спамер может это все дело раскурить, отреверсить алгоритм и повторить его в своем боте, выдергивая из js тот самый коэффициент. Но это будет означать что ему очень-очень нужно проспамить ваш сайт. А когда очень-очень нужно и капча не спасет. Всегда можно нанять тысячу индусов которые будут вводить ее вручную.
Зато от случайных ботов, не умеющих JS, это спасает на ура
вшивается какой-то коэффициент, на основании которого генерируется имя поля
сам алгоритм генерации обфусцирован
И да, я понимаю что злой спамер может это все дело раскурить, отреверсить алгоритм и повторить его в своем боте, выдергивая из js тот самый коэффициент. Но это будет означать что ему очень-очень нужно проспамить ваш сайт. А когда очень-очень нужно и капча не спасет. Всегда можно нанять тысячу индусов которые будут вводить ее вручную.
Зато от случайных ботов, не умеющих JS, это спасает на ура
Мне пока видится, что сильно напрягаться в этом случае не обязательно. Поправьте, где я не прав:
— т.к. серверу принципиально важно знать получаемое случайное имя, которое генерируется на стороне клиента, в любом обфусцированном js-коде будут присутствовать все необходимые реквизиты для повторной генерации случайного имени (я имею ввиду, что «хитро подсолить» не получится);
— алгоритм генерации имени по реквизитам (коэффициентам) достаточно просто определяется по сигнатуре генерируемого имени и конечному числу алгоритмов шифрования/хеширования, реализованных на JavaScript. Сопоставить очень просто.
— т.к. серверу принципиально важно знать получаемое случайное имя, которое генерируется на стороне клиента, в любом обфусцированном js-коде будут присутствовать все необходимые реквизиты для повторной генерации случайного имени (я имею ввиду, что «хитро подсолить» не получится);
— алгоритм генерации имени по реквизитам (коэффициентам) достаточно просто определяется по сигнатуре генерируемого имени и конечному числу алгоритмов шифрования/хеширования, реализованных на JavaScript. Сопоставить очень просто.
Я намеренно не беру в расчет случай, когда алгоритм шифрования нужно реверсить, т.к. он разрабатывался с нуля конкретно для заданного проекта.
Это либо какой-то общеизвестный алгоритм, либо «самописная» подстановка хешей-реквизитов в строку по заданной последовательности, определить которую будет ещё проще.
Это либо какой-то общеизвестный алгоритм, либо «самописная» подстановка хешей-реквизитов в строку по заданной последовательности, определить которую будет ещё проще.
в любом случае, этим подбором нужно заниматься целенаправленно
поймите правильно, я ничего не имею против капчи, и не спорю, что она защищает гораздо лучше
вы спросили «что мешает автору бота вручную скопировать параметры POST-запроса», я предложил вариант, только и всего :)
поймите правильно, я ничего не имею против капчи, и не спорю, что она защищает гораздо лучше
вы спросили «что мешает автору бота вручную скопировать параметры POST-запроса», я предложил вариант, только и всего :)
Мне кажется споры бесполезны. Любую форму можно взломать, будь то ботом или индусом. Скажу по опыту. Проект с посещаемостью несколько тысяч пользователей существует более 5 лет. От спама там используется js замена атрибута action в форме. Т.е. без js форма отправляется на страницу с ошибкой. За все время у меня на сайте не было ни одного спам комментария отправленного автоматическим ботом.
Согласен, плохой совет для посещаемых сайтов.
Все, что расположено на клиенте, уже нахоятся в руках бота. Все ухищрения с js смешные, потому что для содателя бота это не будет никакой проблемой: нормальному клиенту-то нужно показывать видимыми определенные поля, так что мешает боту проверить атрибуты стилей и тоже сабмитить видимые поля? Ничего.
Связку js + css (+ cucmber) давно тестируют и сами разработчики, используя headless браузеры, к примеру phantomjs.
Все, что расположено на клиенте, уже нахоятся в руках бота. Все ухищрения с js смешные, потому что для содателя бота это не будет никакой проблемой: нормальному клиенту-то нужно показывать видимыми определенные поля, так что мешает боту проверить атрибуты стилей и тоже сабмитить видимые поля? Ничего.
Связку js + css (+ cucmber) давно тестируют и сами разработчики, используя headless браузеры, к примеру phantomjs.
У меня есть несколько мало посещаемых сайтов. Есть форма внесения данных, url которой внесли в список какого то из спам ботов. С помощью js в hidden поле я проставляю обычное число и сверяю его на стороне сервера. Так вот — хоть и относительно просто сделать бота, заточенного под конкретный сервер, но когда нужно спамить на тысячи серверов никто не будет проверять ваш конкретный сервер и ковырять защиту. Об этом и говорит автор топика. И мне лично это помогает. Вот если будет сервер типа хабра — тогда да, без капчи никак, а если вы в толпе тысяч таких же безликих сайтов, то совет очень даже актуальный плюс он дает преимущество, так как нет капчи.
>> Автоматически устанавливайте курсор в первое поле формы
>> Как только пользователи увидят перед собой форму авторизации, они будут готовы к тому, чтобы войти на сайт. Вы можете облегчить им задачу, размещая курсор в первом поле ввода.
С этим можно поспорить: если это справедливо для формы регистрации, то в случае с формой авторизации, которая зачастую выводится на всех страницах, могут появиться непредвиденные проблемы. К примеру, часто открыв страницу незнакомого сайта из результатов поиска я ищу на странице определённый текст: в Опере быстрый поиск — жмём слэш и набираем, что ищем по странице, но если фокус на каком-то поле формы (обычно любят на поле поиска ставить), то вместо поиска по странице я получаю ненужный набор текста, приходится кликать по странице, чтобы вернуть фокус и повторять операцию.
Разумеется, какое-либо желание регистрироваться на таком сайте пропадает.
По-моему, фокус на текстовом поле оправдан только для страниц, где кроме формы ничего полезного нет: стартовая страница поисковика, страница с формой регистрации, отдельная страница входа.
>> Как только пользователи увидят перед собой форму авторизации, они будут готовы к тому, чтобы войти на сайт. Вы можете облегчить им задачу, размещая курсор в первом поле ввода.
С этим можно поспорить: если это справедливо для формы регистрации, то в случае с формой авторизации, которая зачастую выводится на всех страницах, могут появиться непредвиденные проблемы. К примеру, часто открыв страницу незнакомого сайта из результатов поиска я ищу на странице определённый текст: в Опере быстрый поиск — жмём слэш и набираем, что ищем по странице, но если фокус на каком-то поле формы (обычно любят на поле поиска ставить), то вместо поиска по странице я получаю ненужный набор текста, приходится кликать по странице, чтобы вернуть фокус и повторять операцию.
Разумеется, какое-либо желание регистрироваться на таком сайте пропадает.
По-моему, фокус на текстовом поле оправдан только для страниц, где кроме формы ничего полезного нет: стартовая страница поисковика, страница с формой регистрации, отдельная страница входа.
> Авторизация на сайте — это важная функция, и пользователи захотят иметь возможность авторизоваться с любой странички на сайте.
Это аутентификация.
Это аутентификация.
Отличная статья! Спасибо, в закладки.
>> И если при отправке данных в поле появляется какой-то текст, вы можете игнорировать этот случай заполнения формы, т.к. перед вами спам бот.
Наивный финский парень, этот Phil Haack. Ничто не мешает боту отправлять данные через curl напрямую, без использования форм и прочей мишуры. Скрытую капчу он придумал…
Наивный финский парень, этот Phil Haack. Ничто не мешает боту отправлять данные через curl напрямую, без использования форм и прочей мишуры. Скрытую капчу он придумал…
Автозаполнение поля «город» на основе почтового индекса
Для России почти бессмысленно, как и для международных сайтов.
Автоподстановка в поле «страна»
Почему никто до сих пор не допёр использовать автоопределение страны с выбором соответствующего пункта в списке через GeoIP? Если пользователю хочется — поправит вручную.
Позволяйте пользователям скопировать платежный адрес из адреса доставки
Не согласен насчёт копирования данных посредством JS в другую (зачастую полностью идентичную) группу полей. Гораздо целесообразнее при отметке чекбокса «тот же» просто скрывать остальные поля.
Простой способ побороть спам, при этом не теряя в конверсии — использование скрытого обязательного поля ввода, создаваемого JavaScript на стороне клиента. Спамботы не могут взаимодействовать с объектами Javascript на стороне клиента, это может сделать только пользователь.
Весьма популярное заблуждение. Только ботам до JS никакого дела нет: они проанализируют контент страницы и сабмитнут сразу нужный набор данных.
Автозаполнение поля «город» на основе почтового индекса
Для России почти бессмысленно, как и для международных сайтов.
Ну почему же бессмысленно. Есть база индексов при наличии которой это делается легко www.geopostcodes.com. Главное чтобы не сильно умничать, сталкивался с такими формами где после ввода адреса мне выдавало ошибку что индекс не соответствует городу или что улица не соответствует, либо выдавало select с улицами где моей не было в списке. Так что эта инфа по любому должна быть доступна для редактирования а использование баз должно быть лишь для того чтобы облегчить ввод информации.
Тут ни слова не сказано про имена полей, думаю это самое важное в формах регистрациях. При правильном именовании полей браузер сделает большую часть работы.
Почему никто до сих пор не допёр использовать автоопределение страны с выбором соответствующего пункта в списке через GeoIP?
Почему это вдруг? Много где вижу.
Почему никто до сих пор не допёр использовать автоопределение страны с выбором соответствующего пункта в списке через GeoIP?
Только изменить надо еще дать. Я вот сижу через Питерские и Баварские прокси.
Почему никто до сих пор не допёр использовать автоопределение страны с выбором соответствующего пункта в списке через GeoIP? Если пользователю хочется — поправит вручную.
Для себя так и не решил, что лучше для пользователя — определять страну (язык, культуру) по GeoIP, или по Accept-Language. И у того, и у другого способа есть недостатки, то есть юзкейсы, когда они сфейлят. С одной стороны, даже верно определенная (что не факт) по IP страна, может быть неверной для пользователя (турист, командировочный и т. п.). С другой — аналогично для браузера, человек может как пользоваться чужим браузером, так и иметь культуру в настройках браузера несоответствующую стране (по личному опыту справедливо для Украины и Белоруссии — настройки ru_RU встречаются чаще чем ru_UA, ru_BY (такого вообще не припомню, кажется), uk_UA и be_BY).
Гораздо целесообразнее при отметке чекбокса «тот же» просто скрывать остальные поля.
А если счеит нужно доставить в тот же дом, только в соседнюю квартиру? Все заново вводить? А так скопировал, номер квартиры поменял и все.
Я думаю, тут еще кое чего не хватает — отправка формы регистрации/логина по Enter. Далеко не везде есть эта возможность, а ведь это важно. После ввода капчи/пароля всегда на автомате жму enter, и плохо себя чувствую.
Добавил в избранное. Многое взял на заметку.
Статья неплоха в качестве памятки, но надо использовать с умом.
Стоит дополнить, что после формы регистрации пользователь должен срузу быть аутентифицирован (жутко бесит когда после регистрации приходится еще раз вводить логин/пасс). Да же если нужно валидировать email, пусть будет рядом с именем плашка, что адрес не подтвержден и запрет на какие то функции. С валидацией вообще большая беда, когда запрещают аутентификацию если не подтвердил адрес, а потом пройда по ссылке в письме просят еще раз ввести логин/пасс.
Про адреса и GeoIP уже сказали.
Про формы требующие заполнения 100500 полей сразу. Лучше просить пользователя ввести нужную информацию по мере необходимости: карточку при оплате покупки, адрес при оформлении доставки и тп
И еще одно важное дополнение. Нужно делать анонимных пользователей (особенно если сервис или магазин) с сохранением всей введенной информации до регистрации, а после регистрации переносить эти данные в профиль.
Пример тур-сайт: зайдя на сайт я в первую очередь посмотрю туры для своего города, а если понравится зарегистрируюсь. Так вот данные о городе (даже без GeoIP) уже были введены, не нужно их спрашивать повторно.
Про адреса и GeoIP уже сказали.
Про формы требующие заполнения 100500 полей сразу. Лучше просить пользователя ввести нужную информацию по мере необходимости: карточку при оплате покупки, адрес при оформлении доставки и тп
И еще одно важное дополнение. Нужно делать анонимных пользователей (особенно если сервис или магазин) с сохранением всей введенной информации до регистрации, а после регистрации переносить эти данные в профиль.
Пример тур-сайт: зайдя на сайт я в первую очередь посмотрю туры для своего города, а если понравится зарегистрируюсь. Так вот данные о городе (даже без GeoIP) уже были введены, не нужно их спрашивать повторно.
Позвольте пользователям видеть их пароли
По-моему это два раза в статье написано.
Данная тема затронута в выступлении Ильи Бирмана на 404fest, советую посмотреть.
Я на всех своих сайтах делаю авторизацию через OpenID, с отсутствием штатной регистрации.
Не думаю что много потерял.
Не думаю что много потерял.
Самая простая регистрация, это одно поле ввода для почты, на которую потом приходит сгенерированный пароль и ссылка, которая сразу ведет уже на авторизированный сайт в ваш профиль, где вы его можете изменить и дополнить все ваши данные.
1. Никаких перезагрузок при регистрации, можно и капчу аяксом чекать, ничего страшного не случится.
2. Показать ссылку на восстановление пароля прямо в форме регистрации, когда введенный email оказывается занят.
3. На почту сразу слать логин и пароль, чтобы можно было юзать поиск вместо восстановления. Также отправлять ссылку автологина для лентяев.
2. Показать ссылку на восстановление пароля прямо в форме регистрации, когда введенный email оказывается занят.
3. На почту сразу слать логин и пароль, чтобы можно было юзать поиск вместо восстановления. Также отправлять ссылку автологина для лентяев.
Спасибо, полезная статья. Правда я бы еще добавил пункт об inline проверке полей при\после ввода в поле, как элемент юзабилити.
Напишу как делаю регистрацию я на массовом развлекательном ресурсе.
1) Пользователь вводит капчу.
2) Жмет «зарегистрироваться».
3) Всё!
Далее в процессе работы ему на видном месте выводится сообщение о том, что у него не заполнен имейл с предложением указать его. Если он указывает имейл на почту приходит автосгенеренный пароль со ссылкой на его смену (без авторизации). При вводе имейла есть галка «указать пароль» для того чтобы назначить пароль сразу.
1) Пользователь вводит капчу.
2) Жмет «зарегистрироваться».
3) Всё!
Далее в процессе работы ему на видном месте выводится сообщение о том, что у него не заполнен имейл с предложением указать его. Если он указывает имейл на почту приходит автосгенеренный пароль со ссылкой на его смену (без авторизации). При вводе имейла есть галка «указать пароль» для того чтобы назначить пароль сразу.
В чём плюс такого подхода? Пользователю всё равно придётся вводить и почтовый ящик и пароль, только позже.
Если его привлечет ресурс — да. Идея в том, чтобы увеличить коверсию и постепенно побуждать пользователей больше вовликаться в проект. Сначала — просто ввел капчу чтобы посмотреть что да как (проект — онлайн игра). Если игра понравилась он сможет ввести имейл и другие данные которые захочет. Таким образом мы не отсекаем любопытных, которым лень регистрироваться и даем игре дополнительную конверсию
А в чём регистрация заключается технически? :)
Любопытная заметка. Единственное, автору на вооружение необходимо взять следующее:
Правильный термин это «набирать», а не «печатать». Печатает принтер.
Правильный термин это «набирать», а не «печатать». Печатает принтер.
Статья интересная и полезная. Спасибо за перевод.
Спрашивать анкетные данные когда они нужны — согласен. Спрашивать имя при первом входе — вряд-ли такое целесообразно. Я только что заполнил форму регистрации и считаю что не нужно больше ничего заполнять.
Большинство пользователей привыкло к сложившемуся юзабилити при регистрации. Не раз уже на хабре встречались статьи-переводы да и не только, что отклонение привычной формы на немного от стандартной очень часто требует уже умственного напряжения регистрируемого. И бывает что влечет к уменьшению конверсии.
Не так давно была статья о повествовательных формах. Тоже безусловно интересно. Но вот я, например, сходу не готов использовать такие вещи на своих ресурсах. Попробовать тянет, конечно :)
Спрашивать анкетные данные когда они нужны — согласен. Спрашивать имя при первом входе — вряд-ли такое целесообразно. Я только что заполнил форму регистрации и считаю что не нужно больше ничего заполнять.
Большинство пользователей привыкло к сложившемуся юзабилити при регистрации. Не раз уже на хабре встречались статьи-переводы да и не только, что отклонение привычной формы на немного от стандартной очень часто требует уже умственного напряжения регистрируемого. И бывает что влечет к уменьшению конверсии.
Не так давно была статья о повествовательных формах. Тоже безусловно интересно. Но вот я, например, сходу не готов использовать такие вещи на своих ресурсах. Попробовать тянет, конечно :)
«и позволит пользователю проверить правильность введенного пароля» — не всегда, потому как визуально не каждый пароль определяется и проверяется, многие люди используют механические пароли, которые набирают на клавиатуре заученным движением пальцев, и визуальное представление пароля — владельцу пароля ничего не скажет. Я сам иногда удивляюсь той абра-кадабре, которой является мой пароль, когда по ошибке начинаю вводить его не в то поле.
> Спамботы не могут взаимодействовать с объектами Javascript на стороне клиента, это может сделать только пользователь.
Очень спорное утверждение. По работе приходилось однажды писать парсер цен с сайтов конкурентов. Первоначально использовался серверный скрипт, но подход оказался не эффективным. При малейшей смене дизайна приходилось править все парсера, настроенные на конкретный сайт.
Намучившись с серверными парсерами было решено применить гибридный подход. Суть заключается в следующем:
1. некий скрипт my.project/next.php загружает html целевой страницы
2. внедряет в html код тег с указанием его родного домена
3. внедряет javascript код, который выбирает нужные данные при помощи XPath и отправляет их на сервер через AJAX.
4. отдает всё это в броузер.
При загрузке скрипта my.project/next.php в броузере он автоматически подгружает страницу за страницей и спокойно парсит данные. При этом не ломается дизайн целевого сайта ибо срабатывают и его скрипты и CSS и всё остальное. Для защиты от возможных JavaScript ошибок внедряем также автоматическую перезагрузку страницы через 30 секунд.
Система была написана 2 года назад. Работает по сей день. Производительность довольно приличная. Единственным существенным минусом данного подхода является то, что нужно постоянно держать my.project/next.php открытым в броузере, но простота использования и надежность покрывают это с лихвой.
Данный подход применен, так сказать, в мирных целях, но ничто не мешает применить его для иного.
Очень спорное утверждение. По работе приходилось однажды писать парсер цен с сайтов конкурентов. Первоначально использовался серверный скрипт, но подход оказался не эффективным. При малейшей смене дизайна приходилось править все парсера, настроенные на конкретный сайт.
Намучившись с серверными парсерами было решено применить гибридный подход. Суть заключается в следующем:
1. некий скрипт my.project/next.php загружает html целевой страницы
2. внедряет в html код тег с указанием его родного домена
3. внедряет javascript код, который выбирает нужные данные при помощи XPath и отправляет их на сервер через AJAX.
4. отдает всё это в броузер.
При загрузке скрипта my.project/next.php в броузере он автоматически подгружает страницу за страницей и спокойно парсит данные. При этом не ломается дизайн целевого сайта ибо срабатывают и его скрипты и CSS и всё остальное. Для защиты от возможных JavaScript ошибок внедряем также автоматическую перезагрузку страницы через 30 секунд.
Система была написана 2 года назад. Работает по сей день. Производительность довольно приличная. Единственным существенным минусом данного подхода является то, что нужно постоянно держать my.project/next.php открытым в броузере, но простота использования и надежность покрывают это с лихвой.
Данный подход применен, так сказать, в мирных целях, но ничто не мешает применить его для иного.
> Боритесь со спамом, пряча при помощи JavaScript текстовое поле, вместо использования капчи
Не спасет от целенаправленного спама.
> Позвольте пользователям видеть их пароли
Я бы не доверял такому полю. Понятно, что можно запретить автозаполнение на input, но не лезть ведь каждый раз в код.
> Делайте кнопку «Подтвердить»…
Сделайте кнопку отправки…
(Make the “Submit” Button as Wide as the Text Fields)
Не спасет от целенаправленного спама.
> Позвольте пользователям видеть их пароли
Я бы не доверял такому полю. Понятно, что можно запретить автозаполнение на input, но не лезть ведь каждый раз в код.
> Делайте кнопку «Подтвердить»…
Сделайте кнопку отправки…
(Make the “Submit” Button as Wide as the Text Fields)
Очень понравилась статья. Пойду усовершенствовать блог. Длинные формы регистрации сама не люблю.
UFO just landed and posted this here
Хотелось бы взглянуть. Можно?
Лучше, наверное, что бы при клике на ссылку для подтверждения регистрации пользователя сразу перенаправляло на форму смены пароля, без авторизации. Таким образом пользователь будет использовать свой родной пароль без промежуточных страниц для авторизации и смены на родной пароль. И, конечно же, использование единой авторизации, для пользователя регистрируется и авторизоваться в 1 клик (первый раз в 2). И никаких промежуточных паролей. Так же пароль не лежит на почте в явном виде. При восстановлении пароля, так же, не присылать его на почту, а ссылку на смену, опять же, без промежуточных страниц. Очевидно что ссылка на смену пароля должна быть одноразовой.
присоединяюсь к oleg_fadeev. Можно?
Хорошая статья, все написанное — в точку, но есть один момент, с которым согласиться нельзя: кнопка входа должна быть размером с текстовое поле. Это не хорошо, а совсем наоборот — это плохо.
На телефоне кнопка вызова не бывает размером с экран или хотя бы набранный на экране телефона номер, кнопка вызова лифта чуть меньше его двери. Аргумент, что пользователь не будет уверен что делать с кнопкой на которой написано «Войти», после того как он только что ввел свои логин и пароль звучит по меньшей мере странно.
Большая кнопка придает уверенности, если это одинокая большая кнопка и рядом с ней нет других элементов форм. Причем большая кнопка не разрушающего действия (например, удаления). Большая кнопка в форме с обычными пропорциональными полями — гипертрофированный монстр и ее использовать нельзя.
На телефоне кнопка вызова не бывает размером с экран или хотя бы набранный на экране телефона номер, кнопка вызова лифта чуть меньше его двери. Аргумент, что пользователь не будет уверен что делать с кнопкой на которой написано «Войти», после того как он только что ввел свои логин и пароль звучит по меньшей мере странно.
Большая кнопка придает уверенности, если это одинокая большая кнопка и рядом с ней нет других элементов форм. Причем большая кнопка не разрушающего действия (например, удаления). Большая кнопка в форме с обычными пропорциональными полями — гипертрофированный монстр и ее использовать нельзя.
> Спамботы не могут взаимодействовать с объектами Javascript на стороне клиента, это может сделать только пользователь.
Ха-ха! Значит вы считаете что эволюционируют только средства защиты? Давно уже есть боты, эмулирующие браузер и рендерящие страницу с выполнением javascript. Да, если у вас не слишком популярный ресурс, то прокатит, но серьезных спамеров это не остановит.
Ха-ха! Значит вы считаете что эволюционируют только средства защиты? Давно уже есть боты, эмулирующие браузер и рендерящие страницу с выполнением javascript. Да, если у вас не слишком популярный ресурс, то прокатит, но серьезных спамеров это не остановит.
Вот из-за таких талантливых людей, как автор статьи, «простые пользователи», о которых он так много думает, напарываются на сайты типа basecamp, где есть какая-то уродская форма регистрации и входа на сайт, которые любимый пассворд менеджер простого пользователя в упор не видит. Довы(*;%лись.
Добавил бы еще один пункт
После регистрации на e-mail обычно приходит ссылка для активации аккаунта. Так пусть пользователь, перейдя по этой ссылке оказывается уже залогинен. Нет никакого смысла заставлять его опять вводить логин-пароль.
После регистрации на e-mail обычно приходит ссылка для активации аккаунта. Так пусть пользователь, перейдя по этой ссылке оказывается уже залогинен. Нет никакого смысла заставлять его опять вводить логин-пароль.
Статья безусловно полезная.
Тем более когда речь идёт о ленивой, или малообразованной в IT.
В моём проекте, пользователям от 35 до 65 лет. И хоть у них техническое образование, не всегда справляются с интерфейсами.
Для реализации моего задания, обязательно учту эти замечания.
Тем более когда речь идёт о ленивой, или малообразованной в IT.
В моём проекте, пользователям от 35 до 65 лет. И хоть у них техническое образование, не всегда справляются с интерфейсами.
Для реализации моего задания, обязательно учту эти замечания.
Интерфейсы для взрослых должны пестрить inline-подсказками о том, что они видят, что они могут сделать, куда и что им нажимать и что произойдет после всех их действий. Это гораздо полезнее UI-фич по типу большой кнопки или показывания пароля.
Показывание пароля как-раз для подобной категории важна. Человек плохо и медленно набирает, так еще и не видит, что же он набрал. Элементарная ошибка с неверной раскладкой создает ему серьезную проблему.
Я скорее имел в виду простоту интерфейса и самозаполнения
В процессе борьбы со спамом, я остановился на замене стандартных значений name в полях формы на нестандартные при помощи JavaScript. Например <input name="email" /> меняем скриптом на <input name="g6iv5e" /> Работает безупречно.
То же, кстати, относится и открытию символов в поле ввода пароля, где можно динамически менять type с password на text и обратно вместо заморочек с дополнительным текстовым полем.
То же, кстати, относится и открытию символов в поле ввода пароля, где можно динамически менять type с password на text и обратно вместо заморочек с дополнительным текстовым полем.
…после чего имеем на выходе проблемы с автозаполнением поля E-Mail средствами браузера.
Нет, если делать замену onsubmit, после ввода всех данных.
Вот ещё, кстати, похожий пример habrahabr.ru/blogs/design/120079/#comment_3938483
Там подобных вопросов вообще не стоит.
Там подобных вопросов вообще не стоит.
UFO just landed and posted this here
Не согласен с «Спрашивайте пароль только один раз»
а если у меня пароли — русские слова, написанные на английской раскладке?
как я буду уверен, что набрал на английской раскладке именно Привет, а не Пирвет (Ghbdtn и Gbhdtn соответственно)
а если у меня пароли — русские слова, написанные на английской раскладке?
как я буду уверен, что набрал на английской раскладке именно Привет, а не Пирвет (Ghbdtn и Gbhdtn соответственно)
Спамботы не могут взаимодействовать с объектами Javascript на стороне клиента
Не всегда.
Очень много полезных советов, благодарю.
А зачем диалог входа на странице, пусть даже AJAX-овый?
Мне лично очень нравится позиция ЖЖ и ещё ряда сайтов, когда поля входа ненавязчиво торчат в шапке, и при входе через них молча (таки вот тут AJAX уместен) заменяются ссылкой на профиль и выход.
Мне лично очень нравится позиция ЖЖ и ещё ряда сайтов, когда поля входа ненавязчиво торчат в шапке, и при входе через них молча (таки вот тут AJAX уместен) заменяются ссылкой на профиль и выход.
Хорошая статья, спасибо. Есть полезная инфа.
P.S для себя первым делом взял мысль о капче и пароле.
P.S для себя первым делом взял мысль о капче и пароле.
Мое решение по избавлению от капчи. Изначально в теге form атрибут action стоит на страницу с ошибкой («у вас отключен js»). Но js отслеживает когда пользователь нажимает клавишу Ввод (отправляет форму) или нажимает на кнопку submit, адрес отправки формы меняется на правильный.
Не все советы одинаково полезны. Отказ от двуз полей пароля к которым все давно привыкли — довольно странное решение. Еще и вместе с галкой «check password». «Что вообще означает это check password?!»
Иконка вопросительного знака у поля ввода однозначно говорит «наведи на меня и увидишь в попапе обьяснение поля ввода». Нафига мне обьяснение к паролю? А, ну может там скажут о требованиях к паролю… а где, блин ссылка на восстановление пароля?!
Иконка вопросительного знака у поля ввода однозначно говорит «наведи на меня и увидишь в попапе обьяснение поля ввода». Нафига мне обьяснение к паролю? А, ну может там скажут о требованиях к паролю… а где, блин ссылка на восстановление пароля?!
Sign up to leave a comment.
Упрощаем регистрацию и вход на сайт