http://habrahabr.ru/post/230401/

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

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

-Мы не смогли ввести логин пароль.

Результат расследования отправил всех в глубоких шок.

Чтобы понять причину этого, мы нашли лояльных клиентов из числа тех, кто ни разу не смог войти, и до последних мельчайших деталей воспроизвели всю последовательность событий.
Форма авторизации настроена так, что если пользователь вводит неправильный символ в поле «логин», система выдает об этом сообщение и не дает пользователю покинуть это поле пока не будет исправлена ошибка. По этой логике пользователь всегда понимает какой именно символ был введен неправильно.

Логин и пароль на доступ в систему приходил электронным письмом. Люди копипастили логин из письма и вместе с ним копировался лишний пробел на конце!

Т.е. если в поле логина есть пробел, система не выпускает фокус и
в итоге люди не могли даже начать вводить пароль.

Проблеме этой было примерно 3-4 месяца. На вскидку, из-за того что примерно 120-150 человек из тех кто хотел платить деньги за сервис просто не смогли зайти и жестко обиделись, этот пробел нам стоил примерно 500 т.р. Плюс минус 90 т.р.

Проблемы было две:
1. в шаблоне почтового уведомления после логина стоял лишний пробел:
<td align="right"> Логин для входа: </td> <td class="value">%3$s </td>
Проблемное место вот здесь"%3$s "
Решили просто правкой шаблона. Теперь лишних пробелов при копипасте нет.

2. В форме авторизации не было обработки на ввод строки с некорректными символом
Тут для решения проблемы решили сделать так: Перед валидацией, сначала делаем trim, потом регуляркой вычищаем все что может помешать. К моменту проверки корректности самого логина(а в качестве логина используется e-mail) мы имеем полностью очищенную строку. А задача валидартора уже дать оценку похоже это на email и есть ли он в нашей базе.

Т.е получается так что сначала строка нормализуется а только потом валидируется. Этот подход решено было внедрить везде. Валидаторы всех форм и полей ввода были снабжены функциями предварительной нормализации, в зависимости от типа данных конечно.

Все члены команды разработки занимаются вебом не менее 10 лет. И тем глупее мы выглядели в своих же глазах.
Ситуация никогда не проявилась бы, если в шаблоне уведомления не было лишнего пробела. Или в форме авторизации было предусмотрено более информативное сообщение, которое точно показывало на причину сообщения об ошибке.

Возможно наш печальный пример кому-то окажется полезным.