Если подобные ограничения кажутся вам слишком жестокими, не запрещайте устанавливать такой пароль, но все-таки проверьте его подобным образом, предупредите пользователя о том, что его пароль слишком простой, его не трудно угадать/подобрать, и рекомендуйте усложнить пароль.
Подумайте и о возможности перехвата пароля при входе или смене. Раз уж кто-то может слушать трафик пользователя (например, недобросовестный админ прокси, провайдер либо сосед пользователя по сети (если они на хабах, а не на свитчах)), то, ясное дело, применение MD5 и тому подобных алгоритмов избавления от необходимости передавать пароль открытым текстом не имеют смысла (потому что
злоумышленник подставит зашифрованный или захеширванный пароль в запрос на вход и, даже не зная пароля, войдет). Остается шифровать само HTTP-соединение, то есть использовать HTTPS.
Никогда не отправляйте пароли методом HTTP/GET. Только POST. Во-первых, они сохраняются в логах Apache, во-вторых, в зависимости от настроек браузера, могут попасть в историю посещения, в логи другого сервера или хуже того в публичную статистику через Referer.
Представьте себе такие ситуации:
Пользователь не завершил сеанс и закрыл браузер. После его ухода можно запустить браузер и пройтись по нескольких URL из истории. Нетрудно догадаться, что если системе никто не объяснил, что пользователь с таким IP, с таким User-Agent, с такими Cookie и т.п. сеанс не завершил, то он продолжится как ни в чем не бывало.
Еще хуже, если человек вовсе не закрыл браузер и тем самым передал все свои права в руки любого имеющего доступ к компьютеру.
Человек торопится уходить, но еще есть время поработать в вашей системе. За пять минут до его ухода происходит авария и электропитания в здании нет. Запасного тоже нет (у машины не было бесперебойника). Человеку некуда деваться (ждать нельзя), он уходит. Через час электропитание восстановлено. Включаем компьютер, запускаем браузер и опять получаем в свое распоряжение тот самый сеанс.
Если ситуация из последнего примера кажется вам чересчур надуманной, смотрите пункт 18 (про маньяков и закон подлости).
Вывод: должен быть тайм-аут. Делается просто. При входе и успешном выполнении любого допустимого действии, которое выполняется авторизованным пользователем, для его логина или id записывается текущее время (то есть время последней активности). А до выполнения такого действия текущее время сравнивается со временем, записанным в вышеописанной таблице для данного пользователя. Если разница превышает тайм-аут, то пользователю работать дальше запрещается, а его сеанс завершается. Здесь же заодно подходящее место для вывода формы входа.
Рассмотрите варианты, как можно организовать отладочный режим:
Приложение отлаживается на сервере, недоступном снаружи (самый безопасный вариант).
Недокументированная настройка переключение в отладочный режим.
Доступ к отладочной информации имеют пользователи либо по IP, либо только определённые учетные записи.
Итак, что же я понимаю под отладочной информацией.
Время выполнения всего скрипта или его части (функции или куска кода).
Количество SQL-запросов, их текст, время их выполнения.
Нагрузка на процессор скриптом, базой, расход памяти.
Сообщения об ошибках и предупреждения интерпретатора в браузер, а не в лог.
Дампы выполнения вспомогательных команд, вызывавшихся во время исполнения скрипта.
Трассировка стека.
Дамп переменных окружения, HTTP-запроса.
На страницы вместе с информацией из базы выводятся внутренние идентификаторы (например, id пользователей, сессий, новостей, статей, событий, да, в принципе, любые идентификаторы данных, которые порой очень облегчают разбор происходящего без лишних подглядываний в базу).
Пара слов о реализации. Я предпочитаю заводить переменную вроде $DEBUG. В разработке она = 1, иначе это релиз. И теперь можно писать либо так:
Так можно подсчитывать количество запросов к БД, замерять длительность их выполнения, сообщать о повторяющийся запросах.
Либо так:
Например, в отладке в списках можно к тексту элемента дописывать его ID в базе. Или добиться, чтобы в отладке проект не выдавал предупреждений на JavaScript при выходе или удалении информации, так как вам это скоро надоест, а данные тестовые их не жалко в случае чего (да и бэкапы вы всё равно делаете, не так ли?).
Internal Server Error знакомо? Пусть в релизе так и остаётся. Так как уж очень интересные вещи порой Perl может поведать взломщику. Максимум, что тут можно сделать, так это назначить в apache
ErrorDocument
500 /500.html
и написать там по-русски об ошибке с учетом того, какое у вас приложение. А технические детали вы в логах почитаете.
Вроде красиво, вроде безопасно но так неудобно отлаживать приходится все время читать хвост error_log. Есть способы выводить многие ошибки в браузер. Почему не все? Дело в том, что ошибка может возникнуть ещё до выполнению приведенных ниже трюков, и они просто не успеют отработать.
Итак, направить ошибки в браузер в режиме отладки можно либо по-старому:
либо с использованием более легкого, чем CGI.pm модуля Котерова: