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