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