Pull to refresh

Comments 185

Правильно ли я понял, что вариант копипаста логина и пароля из письма даже не тестировался?
Все правильно. Вариант копипаста из письма не тестировался. Фокус группа состоящая из 10 клиентов, получала реквизиты доступа иным способом.
Группа тестеров, состоящая из 3х человек, которая проводила полное тестирование всего цикла подключения клиента, также не копипастила логин. И тут все еще интереснее.
В системе всегда используются одни и те же тестовые логины и у тестеров они просто запомнились в форме механизмом автозаполнения.
Вот такая получилась череда событий.
Вот не очень понятна логика браузеров (ну или это к ОС относится), зачем при двойном клике по слову выделять еще и пробел в конце выделяемого слова?
Да, было бы удобно, если первый и последний пробел любого выделяемого участка текста — обрезался автоматически
А вот в старой Опере (12.17) пробелы не выделяются.
В старой опере было настолько удобное выделение, что я иногда открываю страницу в ней только для того, чтобы выделить какой-то текст на сайте.
Столько нытья вокруг «старой Оперы»… Если это и впрям такой офигенный продукт, почему до сих пор никто не форкнул?
Не дело это хорошими продуктами разбрасываться…
Исходников-то нет. Делают otter browser, но не думаю, что выйдет что-то стоящее.
Вам немного поможет Alt. Выделяйте с зажатым Alt (как обычно, бонусом два клика — выделить слово, три клика — абзац).
(Сорри, если не помогло)
Про alt знаю, спасибо, но все-равно приходится точно нацеливаться на блок, чтобы не зацепить ВСЮ страницу.
Проверил в Chrome. Проблема воспроизводится только в Windows (7). На Elementary OS и OS X выделяется слово без пробелов.
Вы вместо выделения слова кликните по нему 2 раза, я всегда так пароли копирую. и всегда пробел удаляю вручную, вот зачем тоже не понимаю, наверно из Word пришло, там надо.
А я, по-вашему, выделяю слово, обводя его курсором? Речь именно про двойной клик. При обычном выделении может что-то лишнее зацепиться где-то, кроме особо хитрых форм?
да, ссори проверил на маке, только 1 слово без пробела
В OS X проблема так-же присутствует:

Давайте разбираться. Какой браузер? У меня Google Chrome 36.0.1985.125, хотя и 35 версия выделяла нормально. Safari 7.0.5 также выделяет без пробела. OS X 10.9.4.
Проблема обнаружена в FF 30 (ниже уже прочитал как решить), но вот часть софта также почему-то поступает аналогично, особенно это бесит в Еvernote клиенте под OS X. То-есть каждая программа обрабатывает эту ситуацию индивидуально и независимо от ОС.
В Safari не воспроизводится.
К счастью Safari не единственная программа в OS X. В Еvernote клиенте, FF (по умолчанию), в ряде специфических программ для работы с текстом — воспроизводится.
Прелессстно, прелесстно! (с)

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

Я сейчас хотел было поставить false, но тут вдруг понял, что переставлять слова в предложении станет гораздо сложнее.

(Предвкушая очевидный вопрос, отвечу: да, лично я действительно достаточно часто этим пользуюсь)
Настроил, удобно. Но, когда выделяю с клавиатуры через Ctrl+Shift+Right, рука автоматически нажимает Shift+Left, чтобы снять лишний пробел. Моторная память — сильная штука. А теперь придётся задумываться, в какой программе выделяешь.
У меня в OS X сборке по умолчанию было выключено.
UFO just landed and posted this here
В Thunderbird встречал, что при выделении слова в конце строки выделялся символ возврата коретки.
Вспоминается история со steam (если ничего не путаю) и их ценой пробела. Правда в их случае не понятно было, реально ли существовал такой баг, или просто попиарились немного.
Напомните пожалуйста, что за история.
Помню только ситуацию с видео-драйвером под linux и сносом пользовательских папок, но это вроде не Steam отличился.
Ниже комментарием привели ссылки на ту статью, дело было в XBox Live, а не в Steam.
Точно, мне именно тот случай вспомнился.
а ведь пробел мог быть до usr, а не после…
Тогда бы команда не отработала без --no-preserve-root.
хм, я ведь не рискну проверить :)
А из Гитхаба вышла неплохая имиджборда!
trim(), всегда, trim(), почему может быть иначе? :)
Тримать пользовательские пароли? Тогда ещё и кавычки поубирать, а то мало ли что.
UFO just landed and posted this here
Никогда не зайду на такой сайт.
потому что не смогу ввести пароль
Ну, логично же, что если при проверке пароля нам ним будут совершать какие-то операции, то и при вводе — тоже. Для вас это пройдет так же незаметно. Вам же не мешает зайти на сайт тот факт, что ваш пароль захэширован, например.
А вот не факт, была у меня пара случаев, когда я мог создать учётку со сложным паролем, но зайти уже с этим паролем не мог. Было это с приснопамятным Origin от электроников и жутко меня бесило. Ещё вроде аналогичная ситуация была с биоваревской учёткой для SW:TOR. Причина естественно в хитрых спец символах. Но какие символы нельзя, а какие можно приходилось выяснять методом научного тыка посредством сброса пароля, потому что нигде абсолютно про допустимые символы ничего сказано не было.
У rutracker такое бывает. Но не сразу. То есть сложный длинный пароль перестаёт работать через некоторое время.
Разные правила при задании и про проверке пароля — это совсем ужасно. А если уж приспичило поменять схему работы паролей, то надо либо сбрасывать принудительно, либо организовывать смену хэша при вводе/смене пароля. Вторая схема, конечно, сложнее, зато не доставит никаких неудобств пользователям.
А какая вам разница, тримается он или нет? Вы просто этого не узнаете.
>А какая вам разница, тримается он или нет? Вы просто этого не узнаете.
Это если он тримается с самого начала. А если сайт уже работает, пользователи ходят, а тут вдруг раз и трим на пароль! И ладно бы только трим, а то ещё чегонить поурезают! И всё. Не войдёшь.
И варианта два: либо хранить пароль в открытом виде, либо проверять на один запрос несколько комбинаций. И то и другое не очень. А альтернатива — потеря пользователя.

Но и если он «с самого начала» урезается, но «втихоря», то что вы покажете пользователю на пароль из 20-ти пробелов? Ну или придуал «мега» пароль, а всё его «мего» — втихую режется на сервере и ты со своим «мега» паролем — барахтаешься в луже «легко подобрать».
Пример — пароль: " P p№P p&Pp 9%№9 " после убирания пробелов, «ненужных символов» и приведению в нижний регистр превращается в «pppppp99». Как при этом снижается сложность пароля — предлагаю проанализировать самостоятельно. И да, я молчу что до сих пор первый пароль не везде можно использовать.
Там ниже, уже по некоторым вариантам частично прошлись.
Но добавлю ещё один «пароль» с которым возникнут проблемы: "                 парольспробелами                        "
ну не обязательно. Можно в базу сунуть флажок — тримнутый ли пароль. Как только человек авторизуется — тримать его пароль, хешировать и ставить флажок в true. Вот только вопрос правильности остается открытым.
Да, действительно. Это похоже на выход для тех кто захочет внедрить в уже готовый проект.
trim (обрезка начальных и конечных пробелов) пароль " P p№P p&Pp 9%№9 " приведет к виду «P p№P p&Pp 9%№9», что, на мой взгляд, вовсе не критично для силы пароля.
Что касается пароля из 20 пробелов — проверка на пустую строку ставится после trim(), что автоматически не позволяет пользователю задать пароль из одних пробелов.
А если количество пробелов в начале или конце — это часть пароля?
Примеры: " 123   "; "123  "; "  123"; " 123 "
Просто проверкой, что trim убирает не больше скольки-то символов не отделаешься.

>trim (обрезка начальных и конечных пробелов)…
Знаю. Но обратите внимание:
>…после убирания пробелов, «ненужных символов» и приведению в нижний регистр…
Вед кому-то может прийти в голову «Мысль» — если уж можно менять пароль, то почему бы и не так? И вот последнее точно не хочется нигде встретить.
Мне кажется, что те, кто заботятся о безопасности своего пароля — это в первую очередь айтишники. А они в курсе, что на большинстве ресурсов логины и пароли автоматически тримаются по объективным причинам (очень весомая часть аудитории пробел за символ не считает и ошибки авторизации из-за лишнего пароля воспринимают как баг системы, изрядно раздражаясь). Соответственно, лично я бы не стал ставить пароль с пробелами в начале и/или в конце. В середине — возможно. Но им трим не повредит.

Что касается вырезания «ненужных символов» и приведения в нижний регистр — это конечно безумие, согласен.
Ну логин мне кажется, можно вполне безболезненно тримать (с учётом специфики ресурса, конечно). А вот про то, что массово тримают пароли — я узнал только тут.
А других вариантов в принципе и нет. Очень много пользователей допускают такую ошибку.
Всегда есть ещё один вариант: удалять только последний символ, если он: пробел, табулятор или перевод строки И не равен символу перед ним.
Пробелы встречаются и в начале.
Кроме пробела может быть перевод строки (т.е. И пробел И перевод строки) — смотря откуда копипастишь.
Хорошо, значит стоит рассмотреть именно такие частные сочетания.
Но «И пробел И перевод строки» — это ошибка источника. Собственно, в посте об этом и написано. Зачем ставить пробел перед переводом строки, если это не часть пароля?
И заметьте, что если пробел есть «И в начале И в конце» — то высока вероятность, что это — специально.
UFO just landed and posted this here
Ещё скажите что нельзя в пароле использовать @-$; и другие подобные символы. И ещё навесить ограничение на длину пароля, а ты потом гадай почему твой пароль с пробелом не проходит этот лимит. И пользователь с паролем из 20ти пробелов, неожиданно, не может зарегистрироваться.
Лучше чуть-чуть пожертвовать стойкостью паролей и тримать поля ввода. Экономит огромные усилия, потому что пароли часто оказываются введены с пробелами в начале, и при этом человек уверен, что ввёл правильно. А такая ситуация — прямой путь к раздражению.
Кстати, можно было бы проверять пароль as-is, и триманный, если первый не подошёл. Тогда и странные люди с паролями в начале и конце не будут обижены, и копипастеры не будут раздражаться.
Странные люди с паролями в конце ничего не заметят, если при задании пароля он тоже будет триммиться. Но случай, когда пароль состоит из одних пробелов, придётся обработать отдельно и предложить выбрать другой пароль.
Странные люди с паролями в конце ничего не заметят, если при задании пароля он тоже будет триммиться


Я скорее из соображений того, что нет смысла делать пользовательский пароль слабее, чем он изначально был
Если сервис для обычных людей, а не для it-шников, это абсолютно не имеет никакого значения. Для них пробел — не символ, а пустое место, и в паролях не используется. А если у кого используется, то либо по ошибке, либо исключение, которым можно пожертвовать.
UFO just landed and posted this here
Привет!

Я немного итшник. Люблю двойным и тройным кликом копировать пароли из писем, страниц форумов, разных файликов. Без мышки, с клавы, могу выделять перед копированием сочетаниями Shift-End, Shift-Home и т.п. Все это происходит исключительно мимодумно.

При этом табы и пробелы попадают в буфер обмена непредсказуемо.
так делать не стоит, потому как тогда появится два валидных пароля. Даже не два, а целая куча паролей, которые отличаются от пользовательского, но которые система считает за правильные. Как уже тут указали, нужно с самого начала об этом думать, и сразу тримить пароль, и при регистрации, и при входе. А так как обычно ставят нижнюю границу длины пароля (хотя бы 4-6 символа, я думаю, нужно ставить всегда), то пароль из одних пробелов, или где пробелы имеют существенную часть пароля, просто не пройдут ещё при регистрации.
>…пароль из одних пробелов, или где пробелы имеют существенную часть пароля, просто не пройдут ещё при регистрации.
Есть исключения: "     123456 "; "123456      "; "      123456"
И во что превратится этот пароль, если его тримить?
об этом уже несколько раз обсудили в комментах вокруг. Имхо, такой пароль близок к ССЗБ.
И большей проблемой будет не наличие/отсутствие пробелов, а наличие нескольких валидных паролей.
Но только в том случае, если на сайте прямым текстом написано, что делают с паролем.
Указано, что убирают пробелы? Значит да, ССЗБ.
Не указано? А кто его знает — что там вообще делается? Может, вообще убираются все «лишние» символы, а остальные приводятся в нижний регитср? А чё, разработчику так «удобно».
Я кот таких поубивать хочу.У меня всегда сложные пароли содержат пробелы и не по одному штуке где попало. И Например долбаный майкрософт имеет ограничение и на длину пароля и на пробелы, vk помоему добавили, куча сервисов запрещают пробелв пароле. Объясните мне, зачем? Ваш довод про идиотов которые не понимают что пишут в текстфилд не канает, да и ниже указано как решать.
> Я кот таких поубивать хочу.У меня всегда сложные пароли содержат пробелы и не по одному штуке где попало.
Вы ставите пробелы в начале или в конце пароля?
Если да, то найдётся много таких кто захочет убить вас :)
Если да, то найдётся много таких кто захочет убить вас :)
За что и почему?
Потом что пробелы в начале и в конце это хорошо для одного, а плохо для сотни.
Желающих иметь пробел по бокам мало, тупящих от того что они случайно скопировали пробел и не могут попасть на сайт много.

Самое простое решение обрезать пробелы.
Тех кто идет против течения и хочет пробелы, создают проблемы.
А кто любит проблемы, ленивые программисты? :-)

А вообще уверен что люди у которых пробелы в пароле явно неординарные люди.
Просто прогресс к ним еще не готов :-)
У меня есть пробелы в некоторых паролях. Но исключительно внутри фразы. В начале-конце перестал их ставить еще в конце 90-х.
Спецсимволов уже не хватает чтоли? :)
Всегда строю пароли на основе только тех символов, которые не являются разделителями и не участвуют в xml и html разметке.
Если есть ограничения, то всегда найдётся недовольный. Вам достаточно спецсимволов, я настаиваю, чтобы мог быть пробел на конце, а есть люди, которые желают вводить бинарный 0 в середине пароля, или скажем, символы со старшим битом (по-русски, например).
простите, как ввести бинарный 0 в поле ввода пароля? с клавиатуры? или с телефона?

А, я кажется, иронию не распознал…
Правильно — поэтому ограничения надо отменить (трим — это не ограничение). Какая системе разница какой у меня пароль — это же мой пароль. Разве что вопрос криптографической надежности (если разгадают — у сервиса будут проблемы). Но можно было бы обойтись и предупреждением. Ведь мнение сервисов о надежности пароля часто ошибочно или очень узко. Есть способы обеспечить надежность безо всяких спецсимволов например.
Мда. Оставили бы одни цифры, слово «пароль» заменили на «пин-код».
В РЖДшном терминале вместо слова «пин» стоит расшифровка (не помню что там, но написано длинными словами, возможно «персональный идентификационный номер»), стоял и тупил перед ним, не понимая что он от меня требует (учитывая что у них на сайте есть вполне нормальная регистрация, и ещё есть бонусная система). Поэтому и тут будут вводить пин от карты или пароли делать в 4 символа.
Но ход мыслей я понял. В Одноклассниках тоже кажется (не заходил туда уже года три) нельзя такие символы использовать, из-за чего я постоянно попадаю на них через восстановление пароля.
Мне как-то удаётся запоминать. Но там существует принудительная смена пароля раз в сколько-то суток. И каждый раз, когда подходит срок и мне приходится выдумывать новый пароль, я крою матом всю эту их IT-богадельню во главе с IT-директором. Обезъяны какие-то, ей-Богу.
Всё проще. Вводите новый пароль — в середине строки пробелы сохраняются, по краям режутся. От оставшегося делается хеш, который и проверяется. Вводите потом пароль — он так же тримается.

И овцы сыты, и волки целы.
А я немного посмтрев на классические дампы паролей и тулы для обработки которые пишутся на скорую руку для парсинга уверен что пароль с пробельными символами(в том чесле в начале и конце) при правильной работе меня спасёт. Пароль это пользовательские данные, зачем туда лезть? Что пришло то и ушло.
Пароль это пользовательские данные, зачем туда лезть? Что пришло то и ушло.
Это отличное рассуждение, которое годится примерно для 1% пользователей. Для программистов, собственно. Как известно программистами становятся люди, которые понимают что компьютер — это железка играющая в бисер и что никакого здравого смысла в нём нету.

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

А что при этом вам и мне становится сложнее с результатом работать — неизбежное зло.
А ограничения навроде «Пароль должен состоять только из латинских символов и цифр» — тоже для них?
юникод, лигатуры, а также shift-jis, big5 и мешок кириллических кодировок в зависимости от фазы луны и настроения браузера. как пароль проверять будем?
На нормальных системах раскладка в полях с паролем автоматом меняется на английскую.
Но мне вот интересно: что такого пиздецки важного «защищают» сложные пароли с не-ASCII символами?
В ASCII(даже в первой половине и даже после пробела) существуют не только латинские символы и цифры…

Другими словами — меня угнетает, что в борьбе с sql-иньекциями мне запрещают вводить апостроф в моём пароле.
Какой смысл пароль проверять на SQL-инъекцию если в базе хранится только его хэш? О_о

Я был уверен (ибо по-любому есть в спеках), но ради эксперимента попробовал вышеуказанные «проблемные» пароли на своих ресурсах — все замечательно работает (рельсы разных версий, в основном devise или clearance для юзеров). Кажись, проблема кроется в надмозге и очередных изобретателях велосипеда.
Т.е. ни один из клиентов не обратился в ваш саппорт, когда у него не подошёл пароль?
Т.е. если в поле логина есть пробел, система не выпускает фокус и в итоге люди не могли даже начать вводить пароль.
UFO just landed and posted this here
Ничего странного, если человеку не лень обращаться в тех поддержку, то он сам бы разобрался с пробелом, заметить который при копировании всё же не так сложно.
UFO just landed and posted this here
А может на фидбек форме такое же интеллектуальное поле для ввода мейла. :)
Для обратной связи мы используем только почту. Пользователь отправляет письмо на спецадрес. Далее youtrack заводит тикет и шлет алармы техподдержке с просьбой отреагировать. Если тех поддержка не может решить проблему, тикет эскалируется до разработчиков. По каждому изменению тикета, пользователю отправляются емэйлы о текущем статусе его обращения.
Тут все достаточно стандартно.
Перед валидацией, сначала делаем trim, потом регуляркой вычищаем все что может помешать.

А можете продемонстрировать пример работы Вашей регулярки, что было до и что стало после?
Трим пробелов в начале и конце логина/пароля вполне обоснован. Но мне почему-то кажется, что дополнительная коррекция логина-пароля способствует значительному снижению уровня защиты. По идее для логина регулярными выражениями можно контролировать является ли он форматом e-mail, а для пароля на наличие только разрешенных символов (к примеру (a-Z0-9_-))
Ограничивать набор допустимых символов в пароле — вот это снижает защиту. Особенно в предложенном вами варианте. Удаление пробелов по краям тоже снижает, но не значительно, т.к. использование пробелов в пароле редкий случай.
Мой вариант — это вариант «к примеру». Основная идея — задать заранее разрешенный в пароле набор символов, исключив потенциально проблемные (типа пробел, таб, 0xFF и прочие), и по нему производить первичную валидацию на допустимые символы. Вычищать какие-то ни было символы из введенного пользователем, кроме применения трима, чревато еще большими потенциальными проблемами в безопасности. Не так ли?
Эмм… даа, я понял. Если это применять при вводе логина/пароля — будут проблемы со снижением безопасности. Подбор пароля злоумышленнику будет облегчен. Тогда только трим.
Ох, как бесят сервисы, которые с одной стороны не хотят мой пароль со спецсимволами, а с другой — хотят чтобы обязательно был Upper/Lower и цифра… Как будто это надежнее…
По-моему на всех курсах по php практически в самом начале изучения форм предлагается такая конструкция:
$_POST['name'] = trim ($_POST['name']); $_POST['password'] = trim ($_POST['password']);
В случае с паролем, можно и пожертвовать пробелами в начале/конце, как уже было сказано
UFO just landed and posted this here
Проблема у вас ровно одна:
Т.е. если в поле логина есть пробел, система не выпускает фокус и в итоге люди не могли даже начать вводить пароль.

Кому вообще это могло прийти в голову?
В какой системе поля ввода ведут себя столь нестандартно?

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

Опишу почему сделали именно так а не сделали обработчик стандартно на сабмит формы:
Механизм валидации един в системе.Некоторые формы содержат порядка 40 полей ввода. И когда пользователь допускал ошибки хотя бы в 10(а это сплошь и рядом), он видел целый веер хинтов с предупреждениями. Это его пугало.

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

Поэтому сейчас «плохие» убираются на момент появления. Допустим если в поле для емейла пишем символы! и № они сразу убираются и пользователю показывается ая-яй.
Извините но показывать 40 полей форму за раз это кошмар для пользователя и так
Не обязательно, это может быть просто необходимо. Но в таком случае нельзя забывать про UX.
мягко намекать пользователю что здесь и сейчас у тебя некорректно написано

Ну это же делается по «onblur».

Допустим если в поле для емейла пишем символы! и № они сразу убираются и пользователю показывается ая-яй.

Плохой вариант в сценариях, где вполне возможны «копи-пасты». Лучше выводить пользователю предупреждение прямо по ходу, а то и указывать на недопустимые символы.

Некоторые формы содержат порядка 40 полей ввода. И когда пользователь допускал ошибки хотя бы в 10(а это сплошь и рядом), он видел целый веер хинтов с предупреждениями. Это его пугало.

Это просто серьезная проблема с юзабилити. Значит, ваши поля были неочевидными, в них не было необходимых хинтов, и так далее — то есть, не было чего-то, что предотвратит ошибки пользователей. Ну а решить проблему вы решили кардинально, поменяв заложенное в браузер поведение элемента, не «сообщив» об этом пользователю. С последствиями, впрочем, столкнулись и уже, уверен, сами все понимаете.
Вам бы UX-дизайнера, т.к. именно он должен в первую очередь заниматься решением таких проблем. Может быть можно сделать какое-то пошаговое заполнение формы? Почему пользователи допускают столько ошибок?

И отдельно про поля ввода: есть ведь очень много способов ввода текста. Ввод вручную, вставка (Ctr+V, Shift+Ins, из контекстного меню), перетащить текст из другого места, автокомплит и т.д. Вставить текст можно в конец, в середину, в начало строки, заменив N символов…

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

Если бы не было никому не нужной валидации и перехвата управления в поле логина, всё было бы гораздо менее печально.

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

Что, кроме того, просто преступление против юзабилити — может я раздумал и хочу добраться до кнопки «Отмена» посредством табов.
Мне нравится вариант с подсветкой поля ярко-красным, если данные некорректны. Это никак не мешает вводу, но бросается в глаза.
если у пользователя e-mail vasya!+ivanov@gmail.com — пользователю говорят что это не корректный e-mail? а ведь он вполне допустимый в e-mail.
про валидацию e-mail даже на хабре писали — habrahabr.ru/post/175375/ и

Конретно этот e-mail невалидный, потому что gmail.com пишет «Please use only letters (a-z), numbers, and periods». Причём, если точка — первый или последний символ, это тоже плохо. Или, если точек несколько: «A fan of punctuation! Alas, usernames can't have consecutive periods».
Он был бы неправ, отказываясь посылать письма на vasya!+ivanov@example.com. А так, он на своей территории и не нарушает стандартов.
Допустим, но это не значит, что адрес vasya!+ivanov@gmail.com невалиден. Это исключительно проблемы некоего почтового сервиса с доменным именем gmail.com, что внезапно абсолютно валидный адрес нельзя на нём зарегистрировать. Ещё раз, этот факт не делает указанный адрес электропочты невалидным.
Господа, а о чем разговор? Вы настолько точные регэкспы на проверки email пишете, что они проверяют порядок символов с учетом домена? Да, vasya!+ivanov@gmail.com — адрес невалидный, но в то же время vasya+!ivanov@gmail.com — адрес вполне рабочей почты.
Под невалидностью в данном я подразумевал невозможность занять такой адрес, а значит и получить по нему что-либо.
Это неправильное понимание слова «валидность».
К тому же, вы же не пытались предложить вести в веб-сервисе акутальную базу данных множеств возможных адресов для всех тысяч и тысяч существующих почтовых провайдеров ради подсказки пользователю при вводе адреса в форму?

Это совершенно глупо и ненужно. Для проверки адреса пользователя при регистрации используются письма-подтверждения.

А вот когда сервис отметает совершенно валидный, существующий, рабочий и принадлежащий данному пользователю почтовый адрес просто из-за недалёкости кодера и даже письмо-подтверждение послать не даёт — это отвратительно.
первое не означает второго
в случае конкретно gmail (И google apps for your domain) (и некоторых других серверов) если у нас vasya@gmail.com то мы получим почту которая отправлена и на vasya+!YourService@gmail.com. но не у всех серверов почтовых это так. на gmail это можно использовать например для сортировки почты по источнику которому давали адрес…
Google не дает регистрировать такие адреса, но это совсем не значит, что подобные адреса нельзя использовать. Это subaddressing(RFC5233) и многие сервисы вполне корректно с ним работают. И именно потому, что они используют subaddress и невозможно зарегистрировать email вида vasya+ivanov@gmail.com, так как это subaddress email'а vasya@gmail.com. А вот отправлять сообщения на адрес вида vasya+ivanov@gmail.com вполне можно и этот адрес считается корректным согласно RFC5322
Показывайте хинт по уходу фокуса, без его блокировки. Так в общем-то все и делают. В итоге ни сомнительной блокировки, ни 40 хинтов.
Ребят, то, что вы написали этот пост и осознали свою глупость — уже неплохой шаг наверх! Но принципиальная ошибка у вас не в пробеле или каких-то валидациях, а в том, что вы слишком много решаете за пользователя! Ведёте себя как какие-то боги системы — то не делай, это не пиши, сюда не переходи…
Вам знакомо раздражающее чувство, когда во время вашего вождения жена указывает вам как рулить? :) Вот это именно то, чем вы занимаетесь на формах — умничаете больше, чем того требует ситуация.
Пользователь ИМЕЕТ ПРАВО вводить всё, что вздумается. Пример: надо ввести емэйл, но текст с адресом юзер скопировал из другого текста и в строку попал всякий мусор. Что делает нормальный человек? Спокойно пастит строку и подправляет. Вы же со своей назойливой валидацией тыкаете его как котёнка «тут неправильно!».
Уберите к чертям этот авторитарный режим! Дайте им воодить так, как им хочется и аккуратно, без диких цветов и огромных баннеров, пометьте невалидные поля (рамки вполне достаточно).
С регэкспами у вас такой же перебор — trim'а вполне достаточно.
А если бы юзеру писалась внятная ошибка «Пользователя "vasya " не существует» (моноширинный шрифт и кавычки!), то и пробел вы бы тоже сразу отловили. Вы разве не говорите юзеру, что его логин неправильный??
Где-то ещё видел такую реализацию визуализации ошибок: после отправки формы, если возникли какие-то ошибки или забыли ввести данные, то обратно приходит форма, где запрашивается только то, что неправильно — без остальных полей.
Очень полезная статья! Наконец-то я понял, почему иногда у меня копируется ровно одно слово — а иногда приходится удалять пробел в конце…
на самом деле проблема в хроме.
В FireFox такое же поведение. Вообще, много где по двойному клику выбирается слово с пробелом (в Windows как минимум). Это печально.
На некоторых сайтах встречал такую «фичу»: если копипастить пароль в поле ввода, то он не принимается, а если вводить руками, то ок. И дело тут не в пробеле, всё скопипащено правильно.
Может перевод строки попасть.
А часто копипаст пароля и вовсе запрещён (событие вставки поле не принимает), вот это бесит жутко. Особенно если пароль на 25 символов и хранится в KeePass
Встречал один или два раза такое. Число «звездочек» с числом символов в пароле совпадало, обычно по этому можно определить, что попадает что-то лишнее в поле. Но до поисков истинной причины дело не дошло.
Помоему классическая проблема. Сталкивался с такой, час гадал в чем дело :)
Это круто. 10 лет заниматься разработкой и не очищать данные перед проверкой.
UFO just landed and posted this here
При нынешних законах о раскрытии информации, я вообще начинаю терять смысл иметь какие-либо пароли ;)
Так сильно, по видимости, люди хотели им пользоваться, если не могли даже вручную ввести данные, для проверки.
Конечно, проще обидеться, чем еще раз набрать на клавиатуре лишние десять символов.
Печально это.
UFO just landed and posted this here
Была похожая шляпа в свое время с QIP'ом, кажется. Стоял у меня длинный пароль. И в форме логина он вполне себе принимался. Но вот сменить его в клиенте было нельзя: нужно ввести старый пароль, но на длину этого пароля стояло некое ограничение.
UFO just landed and posted this here
В linux по двойному щелчку выделяется без пробела, по тройному с пробелом.
Эм, что? Тройной щелчок же всегда выделял абзац. Что за линукс у вас, и где конкретно такое поведение проявляется?
А вот в старой Опере (12.17 которая) тройной щелчок выделяет предложение. Чтобы выделить абзац надо сделать четверной щелчок.
Честно говоря, сегодня утром я был уверен именно в таком поведении. Но проверил на всем, что под руку попалось, и решил, что это мне приснилось. Причем не в опере с этим сталкивался точно.

PS: в моем понимании старая Опера — это до 10.50, а годная опера — это 9.62.
>Форма авторизации настроена так, что если пользователь вводит неправильный символ в поле «логин», система выдает об этом сообщение и не дает пользователю покинуть это поле пока не будет исправлена ошибка. По этой логике пользователь всегда понимает какой именно символ был введен неправильно.

Вы решили несуществующую проблему и сами себе нажили проблем. Не надо считать пользователя инвалидом и держать его за руку! Может быть я хочу сначала ввести пароль, а потом логин? Отключение ожидаемой реакции на действия (перевод фокуса в данном случае) — уже само по себе большая ошибка. Предупреждения с описанием проблемы было бы вполне достаточно.
Перехват и удержание фокуса — преступление. (Безотносительно проблем с пустыми символами.)

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

Впрочем, свои ошибки вы искупили и заплатили за них, это хорошо.
вспоминается моя работа в техподдержке… :)

— у меня ошибка 691
— скажите, пожалуйста, ваш логин
— ps123456
— [grep что-то там ps123456 -> ...'ps123456 '...] у вас после логина стоит пробел, уберите его, пожалуйста
— нету у меня никакого пробела, какой пробел, вы что?
— вы его не видите, но он точно есть, поставьте курсор сразу после логина и нажмите кнопку backspace
— что такое курсор?
— …
Ой ти, подумаешь. Что такое курсор.
У меня недавно одна особа с уровня руководства долго утверждала, что «её не пускает на страницу». А там обычная basic auth по http. Все перепроверили, ну не может не пускать. Перешли к тяжелой артиллерии — начали по шагам. Диалог примерно такой:
— Вы открываете страницу, там предлагается ввести логин-пароль. Выводится?
— Да
— Вы вводите логин и пароль, нажимете enter, какая ошибка отображается.
— А я ничего не ввожу, мне же пароль не дали!
— %№"";%!№%!!!

К слову, пароль ей выдалвали примерно за сутки до этого. И что вы думаете? Я еще и оказался виноват! =) Сформулировано это было примерно так: «А что сразу нельзя было сказать, что надо вводить пароль?!»
А это руководитель, типа. Отделом… Довольно крупным.
Курсор-то и правда фиг с ним. Иногда было так, что мучаешься-мучаешься, наконец объясняешь человеку как подключиться и у него получается! А потом он спрашивает «а что дальше-то делать?». И после пары вопросов ты понимаешь, что он вообще не врубается, зачем ему интернет и как им пользоваться. Ну вообще ноль, совершенно никакого представления
Это решается просто: ведёшь человека на Rндекс и говоришь ему: введи в поисковой строке «что делать если» — он просто офигеет, что можно делать в интернете, «если»! :)
Знакомая история. Давным-давно, когда только-только в наш город пришел DSL, я бегал по квартирам и колымил с настройкой (провайдер не парился по этому поводу). Роутер настроить, провод по квартире проложить, и всё в этом духе.

После настройки разумеется показываю клиенту, что всё работает. Знаете, сколько раз мне задавали вопрос «а дальше что делать»? Наверное, каждый четвёртый клиент. Приходилось проводить небольшой 10-минутный ликбез.
да-да, я тем же промышлял, было дело :)
Курсор — это у мышки, а в поле ввода — каретка :)
Вы меня, конечно, извините, но исключительно Caret — это в названиях некоторых функций. А в документации это вполне может быть text cursor (если по английски) или текстовый курсор (если по русски).
Проблема может быть не только с копипастой, клавиатура Android (по крайней мере, стандартная на устройствах Sony) после выбора слова из словаря, что особенно часто встречается при вводе логина, автоматически добавляет пробел. Trim необходим.
Ох, как обычно на хабре раздули проблему из ничего.
А можно было бы просто в письме логин и пароль заключить в «кавычки».
Тогда некоторый процент пользователей копировал бы пароль вместе с кавычками.

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

Только хардкор, только одноразовый токен.
Трагедия, трагедия!
Ужас то какой. И всего один .Trim()…
Не буду говорить за всех, но во всех моих приложениях все что вводится, у меня пропускается в нужную переменную только после Trim(). Хоть то WPF, хоть Console, хоть Asp.Net.

Может потому что этот урок я усвоил еще в школе во времена развлечений с Basic'ом, когда развлекался со строками и сейчас это у меня происходит на автомате…
в сбере онлайн такая же фигня. только они еще не тримят пробел, который в номере на их же картах стоит
А сколько еще лет нужно заниматься разработкой, чтобы перестать высылать пароль в открытом виде на почту?
А почему бы и не высылать? Это же не значит, что хранить его не хешированным. Мне например бывает очень удобно, когда забыл пароль, порылся в почте, нашел.
Бывает очень удобно, если забыл пароль, посмотреть его на стикере, приклеенном к монитору, ага?

Это небезопасно по ряду причин.
>>Это же не значит, что хранить его не хешированным.
Ну вот же, в почте у пользователя пароль будет храниться в открытом виде.

Самый простой пример: злоумышленник получил доступ к почте — и сразу же ко всем остальным сервисам, у которых такое отношение к информационной безопасности.
Или банально, из-за плеча на монитор посмотрят и увидят. Это только вершина айсберга.

Бывает очень удобно, если забыл пароль, посмотреть его на стикере, приклеенном к монитору, ага?
Вы серьезно сейчас сравниваете листочек, доступный всем, и мою пользовательскую директорию, к которой имею доступ только я?
Самый простой пример: злоумышленник получил доступ к почте — и сразу же ко всем остальным сервисам, у которых такое отношение к информационной безопасности.
Как только злоумышленник получил доступ к почте — он автоматом получил доступ ко всем сервисам, которые зарегистрированы на эту почту. И не важно хранится пароль от сервиса на почте или нет, ибо его можно восстановить.
Или банально, из-за плеча на монитор посмотрят и увидят. Это только вершина айсберга.
Тогда вообще нужен девайс, позволяющий вводить силой мысли пароль. А то вдруг кто-то через плечо посмотрит, и запомнит все клавиши, которые я нажимаю при вводе пароля.
>>Вы серьезно сейчас сравниваете листочек, доступный всем, и мою пользовательскую директорию, к которой имею доступ только я?
В действительности разница не очень велика. Доступ к листочку тоже имеют только ваши коллеги или домочадцы, к примеру. А доступ к почте потенциально еще имеют инженеры службы почты. А к тому конкретному письму с паролем, еще и инженеры службы поддержки сервиса. А доступ к самим данным еще все те инженеры, которые обслуживают каналы передачи данных.

>> И не важно хранится пароль от сервиса на почте или нет, ибо его можно восстановить.
Тут встает вопроc о скрытом получения доступа или открытом. Если злоумышленник восстановил пароль, вы это узнаете, т.к. не сможете воспользоваться сервисом со старым паролем. Хотя не удивлюсь, что при вышем подходе к безопасности, вы бы хотели, чтобы вам сервис присылал старый пароль, так же удобнее.
Опять же, все больше критичных сервисов при смене пароля запросит еще дополнительную проверку, через мобильный телефон, например. Возьмите интернет-банк, получив доступ к почте, злоумышленник сможет туда попасть, восстановив пароль? Если да, у меня для вас плохие новости, лучше откажитесь от такого интернет-банкинга.

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

Да, поэтому не стоит вводить пароль, когда кто-то стоит рядом и смотрит на клавиатуру. Нужно просить отвернуться. Почему, вы думаете, банкоматы оснащены панельками, которые скрывают действия руки? Почему пароли закрываются звездочками при вводе?

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

Ок, допустим, вы ответственный человек и храните доступ к вашей почте как зеницу ока. Всегда пользуетесь защищенными соединениями и каналами связи. И вообще вы «неуловимый Джо».
Но все ли люди так делают? Сломался у человека ноутбук, он отдал в сервис. Ноутбук починили, но недобросовестные люди потом прошлись скриптиком по архиву почты в аутлуке и выдернули десяток пар логин-пароль.
Примеров можно приводить очень много. Притом из жизни.
>> В действительности разница…
Если кто-то имеет доступ к письму, то очевидно что он имеет доступ к почте. Следовательно может восстановить пароль и воспользоваться сервисом.

>> Тут встает вопроc о скрытом получения доступа…
Про скрытый доступ — спорное утверждение. Я одинаково не хочу, чтобы кто-то имел доступ к моему аккаунту. Не важно скрыто или открыто.

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

>> Да, поэтому не стоит вводить пароль, когда кто-то стоит рядом и смотрит на клавиатуру…
Я вообще то этот аргумент привел в ответ на то, что некий Вася через плечо увидит как я копипасчу jCW839dfJ38 из письма в почте.

>> От шпионских программ, делающих снимки экрана
Вот с этого примера посмеялся, спасибо.

Ну а по поводу сервиса и ноутбука — это вообще отдельный разговор. Можно подумать что пароль от какого-нибудь вконтактика — это самые конфиденциальные данные, которые есть на компьютере, и если этих данных нет — можно смело нести ноут в сервис.
Ну параноики, что с них взять? Даже не спорь с такими, переубедить невозможно.
Если пароль лежит в явном виде в почте, то ему не надо будет на всех этих сервисах жать кнопку «Восстановить пароль» и менять его везде (иногда всё же пароли отличаются от ящиковых) и таким образом он может дольше оставаться необнаруженным.
Хотя бы потому, что ВСЕ почтовые конторы — под ногтём АНБ. Какого чёрта мне присылают на публичный емэйл мои приватные данные?? Я даже фамилию светить не хочу, не то, что пароли! И где гарантия, что очередной обиженный админ гугла не сольёт письма хакерам?

А вот вам ещё прикол: у меня накрылся винт — жужжит, но не виден в BIOS. Сдал по гарантии, думал починят — фик два! Забрали и выдали новый. А теперь банальный «мальчик на сервисе» меняет плату и спокойно считывает то, что я бережно копил от чужого глаза, включая регистрации на всех сайтах. Нормал?!
А вот вам ещё прикол: у меня накрылся винт — жужжит, но не виден в BIOS. Сдал по гарантии, думал починят — фик два! Забрали и выдали новый. А теперь банальный «мальчик на сервисе» меняет плату и спокойно считывает то, что я бережно копил от чужого глаза, включая регистрации на всех сайтах. Нормал?!
Ну тут либо шашечки, либо ехать. Можно было дождаться окончания гарантийного периода, и только после этого записывать конфеденциальные данные на винт, либо нести в соответствующий сервис по ремонту, который подписывает NDA с вами.
Винт и куплен под данные, зачем чего-то ждать?
Сервис по ремонту — да, но не в моём окружении — ещё хуже испортят.
Смысл в том, что мои частные данные ушли неизвестно кому — и с почтой происходит то же самое — «кто владелец сервера — тот и бог всех данных».
Я думаю конфиденциальных данных на винте — кот наплакал. Они могли очень свободно умещаться на старом винте, нет? Или чего вы ожидали от гарантийного сервиса? Да и раз записали туда очень ценные данные — никто не заставлял нести по гарантии. Полно платных сервисов, которые подписывают NDA с клиентом. (И мне кажется вы даже могли попробовать подписать NDA с гарантийной мастерской, но это надо смотреть договор гарантийного обслуживания).
То же самое и с сервером. У вас очень ценные данные, которые даже АНБ не хотите светить? Пожалуйста, интернет свободная система, поднимайте свой почтовый сервер, храните данные на нем.
А вот вам ещё прикол: у меня накрылся винт — жужжит, но не виден в BIOS. Сдал по гарантии, думал починят — фик два! Забрали и выдали новый. А теперь банальный «мальчик на сервисе» меняет плату и спокойно считывает то, что я бережно копил от чужого глаза, включая регистрации на всех сайтах. Нормал?!

Если храните критичные данные — шифруйте разделы, если информация на винте стоит намного дороже винта при ее попадании в чужие руки, то винты в случае выхода из строя уничтожаются физически так, чтоб считать эту информацию было невозможно ни какими средствами. Регистрации от сайтов хранят в keepass или других криптоконтейнерах. А тут классический случай ССЗБ.
Sign up to leave a comment.

Articles