Произошла курьезная и очень болезненная ситуация одновременно.
У нас много зарегистрированных клиентов и много из них тех, кто ни разу не входил в систему.
Писать клиентам по таким вопросами бесполезно — мало кто из обиженных клиентов ответит почему он обиделся.
Поэтому мы не поленились и начали тупо всем звонить и спрашивать, почему, мол, так и не зашли?
Ответ был почти у всех одинаковый:
— Мы не смогли ввести логин пароль.
Результат расследования отправил всех в глубоких шок.
Чтобы понять причину этого, мы нашли лояльных клиентов из числа тех, кто ни разу не смог войти, и до последних мельчайших деталей воспроизвели всю последовательность событий.
Форма авторизации настроена так, что если пользователь вводит неправильный символ в поле «логин», система выдает об этом сообщение и не дает пользователю покинуть это поле пока не будет исправлена ошибка. По этой логике пользователь всегда понимает какой именно символ был введен неправильно.
Логин и пароль на доступ в систему приходил электронным письмом. Люди копипастили логин из письма и вместе с ним копировался лишний пробел на конце!
Т.е. если в поле логина есть пробел, система не выпускает фокус и
в итоге люди не могли даже начать вводить пароль.
Проблеме этой было примерно 3-4 месяца. На вскидку, из-за того что примерно 120-150 человек из тех кто хотел платить деньги за сервис просто не смогли зайти и жестко обиделись, этот пробел нам стоил примерно 500 т.р. Плюс минус 90 т.р.
Проблемы было две:
1. в шаблоне почтового уведомления после логина стоял лишний пробел:
Логин для входа: %3$s
Проблемное место вот здесь"%3$s "
Решили просто правкой шаблона. Теперь лишних пробелов при копипасте нет.
2. В форме авторизации не было обработки на ввод строки с некорректными символом
Тут для решения проблемы решили сделать так: Перед валидацией, сначала делаем trim, потом регуляркой вычищаем все что может помешать. К моменту проверки корректности самого логина(а в качестве логина используется e-mail) мы имеем полностью очищенную строку. А задача валидартора уже дать оценку похоже это на email и есть ли он в нашей базе.
Т.е получается так что сначала строка нормализуется а только потом валидируется. Этот подход решено было внедрить везде. Валидаторы всех форм и полей ввода были снабжены функциями предварительной нормализации, в зависимости от типа данных конечно.
Все члены команды разработки mm24.com занимаются вебом не менее 10 лет. И тем глупее мы выглядели в своих же глазах.
Ситуация никогда не проявилась бы, если в шаблоне уведомления не было лишнего пробела. Или в форме авторизации было предусмотрено более информативное сообщение, которое точно показывало на причину сообщения об ошибке.
Возможно наш печальный пример кому-то окажется полезным.
Оригинал статьи на Хабре (2014 год)
К лучшим публикациям Хабра за сутки