В моей прошлой заметке про пароли некоторые пользователи высказали мнение, что пользователь имеет право ставить любой пароль, хоть из одной буквы. Мол, он сам будет отвечать, если его аккаунт взломают.

На одном местечковом форуме под старенькой phpBB второй версии последнее время участился хитрый спам: спамеры взламывали аккаунты пользователей и редактировали их сообщения многолетней давности, заменяя на SEO-тексты с порноссылками. Редактирование старых сообщений долгое время оставалось незамеченным для администрации, но не для поисковых машин. Парой запросов в базу удалось выяснить, что взламывали аккаунты с паролями двух типов: с паролем «12345» и с паролем, совпадающим с логином. Оказалось, пароль 12345 поставили 13 пользователей, пароль-логин — 16 пользователей, всего порядка 1500 пользователей. То есть каждый 50-й аккаунт мог быть так взломан. Причём, так как спамеры перебирают пользователей, а не пароли, нельзя автоматически заблокировать определённого пользователя, пароль которого пытались подобрать много раз.

Администраторы, запретите устанавливать простые пароли, если вы ещё этого не сделали. Капча на логин — штука спорная, но может пригодиться. Пользователи, не возмущайтесь, когда вам не дают установить простой пароль :-)

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

1. // getRectangleArea(x1, y1, x2, y2) или
2. // getRectangleArea(width, height)
3. function getRectangleArea(x1, y1, x2, y2) {
4.   if(arguments.length==2) return x1*y1;
5.   return (x2-x1)*(y2-y1);
6. }

* This source code was highlighted with Source Code Highlighter.

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

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

С ограничением длины снизу всё понятно, но кому нужно ограничение сверху? Пусть пользователь вводит хоть 200 символов, если ему хочется, фрику будет приятно. Жалко байтиков в POST-запросе? Место в базе данных? Но вы же (я надеюсь!) храните хэш от пароля, который всегда постоянной длины! Считаете, что хэширование 200-символьных паролей убьёт производительность сервера? Не смешно.

При всём при этом создатель сайта заставляет пользователя:

• Воспринять и осмыслить лишнюю информацию;
• Поволноваться, не превышает ли его любимый пароль указанное ограничение;
• Дважды пересчитать символы в 12-символьном пароле, чтобы убедиться, что всё нормально;
• Придумать новый пароль, если любимый оказался длиннее (не всем живым людям придёт в голову чисто компьютерное решение убрать последние символы пароля: он может стать неблагозвучным).

На фоне всяких рассуждений о национальных доменах, которые делают для удобства запоминания и ввода названия, вспомнился метод создания паролей, когда смотришь на русскую раскладку, но вводишь латинскими буквами. Можно ли зарегистрировать доменное имя на том же принципе? Идея кажется ещё интереснее, если вспомнить, что точке соответствует русская буква «ю». Беглый перебор популярных доменов верхнего уровня дал один перспективный вариант — .kz, который в русской раскладке выглядит как «юля». Скажем, мог бы существовать кулинарный сайт «Кастрюля» с доменным именем rfcnh.kz. Довольно страшно выглядит, но легко запоминается. Логотип сайта может подсказывать способ ввода:

Да, я знаю, что кнопка с «Ю» выглядит не так, но в логотипе такой вариант нагляднее.

Сомневаюсь в перспективности идеи, но вдруг кому пригодится :-)

В работе мне нередко случается реализовывать долгие процессы, где не обойтись без прогресс-индикатора. Проблемы начались, когда процессы стали слишком сложными, но при этом хотелось иметь один непрерывный прогресс-индикатор для всего процесса. К примеру, процесс может состоять из вызовов функций Asub, Bsub и Csub, каждая из которых выполняется довольно долго (скажем, примерно 10%, 20% и 70% общего времени). Пусть Asub содержит два цикла, идущих подряд, Bsub несколько вложенных циклов, а Csub один цикл, но при этом в середине этого цикла вызывает Asub. Решая задачу в лоб, можно довести код до такого состояния, что треть всех строчек будет вычислять текущий процент и определять, пора ли его обновлять в UI, а функция Asub принимать дополнительные параметры, чтобы определить, какой диапазон процентов ей отображать (от 0 до 10, если вызвана из основного процесса или какой-то другой, если вызвана изнутри Csub). В результате код теряет читаемость, а поддерживать его становится сложнее. И нас ждут приятные минуты, когда мы захотим повторно использовать Bsub в другом месте, но уже не в середине, а в конце общего процесса, так что выводимые ей проценты от 10% до 30% будут не к месту. Я пришёл к выводу, что с этим надо что-то делать.

В 1999-м году в браузере IE 5 Микрософт впервые реализовал автозаполнение текстовых полей форм, что позволило вам не вводить текст, который вы уже вводили ранее в поле с данным именем (в том числе на другом сайте). Тогда же появилось нестандартное расширение тега <input>: атрибут autocomplete, установление которого в off позволяло отключить эту функциональность для конкретного поля. Сейчас все популярные браузеры (подсказали, что кроме Оперы) поддерживают автозаполнение и этот атрибут. Он также введён в стандарт HTML 5. Тем не менее, разработчики веб-сайтов зачастую им пренебрегают.