Часто программисты считают, что администратор сайта по умолчанию будет если не программистом, то уж точно равным ему по уровню компьютерной грамотности. Но в реальности зачастую это оказывается совсем не так.
Во многих фирмах на администрирование сайта сажают секретаршу, все познания которой о компьютерных технологиях ограничиваются набором текста в программе Word и сохранением его «в компьютере».
Столь же часто встречается ситуация, когда администрирование поручают одному из сотрудников, который может быть великолепным бухгалтером или менеджером по персоналу, может прекрасно представлять себе политику фирмы и концепцию информационного наполнения сайта, но при этом ничего не понимать в Интернете и в компьютерах вообще. Как ни странно, не смотря на более чем десятилетнее повсеместное распространение компьютеров, многие специалисты, причем, неплохие специалисты в своих областях, имеют самое смутное представление об Интернете и компьютерах.
А неправильные действия администраторов иногда сопоставимы по тяжести последствий с хакерскими атаками.
Конечно, закрытая паролем, например, с помощью средств Apache — файла htaccess, система администрирования не будет доступна злоумышленнику, и там нет нужды так защищать переменные или проверять содержимое вводимого текста. Уж если хакер прорвется в «админку», он натворит там дел, даже весь вводимый текст будет тщательно фильтроваться и проверяться.
Система администрирования должна быть изнутри защищена не столько от злонамеренного действия, сколько от возможной безграмотности администратора.
Как правило, самые большие неприятности возникают при загрузке текстовых и архивных файлов или фотографий на сервер.
Первая причина сбоев – попытка администратора загрузить слишком большой по объему или по линейным размерам файл. В лучшем случае такие действия вызовут легкое недоумение посетителей сайта, у которых три картинки размером с почтовую марку будут открываться минут 15, так как их реальные размеры превышают 2000 пикселей, а до размера в пару сантиметров они ужаты уже на странице атрибутами height и width в тэге img. Не удивляйтесь, такие фотогалереи до сих пор встречаются в Интернете.
В худшем же случае такой файл просто окажется больше разрешенного настройками сервера предельно допустимого размера и «не пролезет в Интернет», а владельцы сайта начнут предъявлять программисту свои претензии относительно «плохой работы сайта».
Так что необходимо, как минимум, проверять размер загружаемого файла, а как максимум, если речь идет о графике, автоматически изменять размер до приемлемого значения. Причем проверять как на стороне пользователя, так и на стороне сервера. Лучше сразу дать пользователю понять, что файл таких размеров на сервер загружать нельзя, чем заставлять его ждать, пока файл будет передаваться на сервер и анализироваться там. Но и на сервере проверять размеры надо всегда, так как например, при стандартных настройках сервера с memory limit в 8 мегабайт, функция createfromjpeg не сможет «переварить» файл с габаритами более 1500 пикселей по ширине или высоте. Такая попытка вызовет fatal error из-за нехватки памяти на завершение операции.
Вторая причина сбоев – загрузка файлов, содержащих в названии недопустимые символы — пробелы, русские буквы, запятые. Современные пользователи Windows избавлены от необходимости задумываться над именами файлов. В Windows вполне допустимо имя «файл Васи Пупкина, хранящийся здесь, в компьютере.doc» И множество офисных сотрудников не видят ничего предосудительного в загрузке таких файлов на сервер. Но на сайте такой файл не откроется. Так что надо или запрещать закачку таких файлов, или автоматом все переименовывать.
Третья причина проблем с файлами – несоответствие расширений. Как и в случае с именами файлов, офисные пользователи Windows не слишком хорошо знакомы с этим вопросом. По умолчанию в Windows расширения вообще не видны, так что попытки закачать в качестве картинки файл с расширением doc, а в качестве текста – с расширением bmp — не такая уж и редкость. Естественно, это приведет к сбоям, так что тип загружаемого файла необходимо проверять. Причем, надо проверять не только расширение, но и MIME-тип файла, так как до сих пор встречаются пользователи, которые считают, что для конвертации файла из одного типа в другой достаточно сменить его расширение. И помните, что MIME-тип все браузеры передают немного по-разному.
Конечно, не все возможные ошибки администратора связаны с загрузкой файлов. При желании можно навредить даже при загрузке и редактировании текста. Например, бывает что «продвинутый» администратор пытается продемонстрировать свое знание HTML, редактируя тексты, которые для этого не предназначались. А уж как можно исказить дизайн сайта, загрузив пару таблиц и забыв закрыть в них тэг table – это можно не объяснять. Так что по возможности ограничивайте применение html администраторами, хотя полностью запрещать его, конечно, нельзя.
Кроме того, иногда сбои происходят, если от администратора требуется избыточно строгое следование некоему алгоритму. Например, при редактировании какого-нибудь раздела ему присваивается некий признак или наоборот, стираются какие-нибудь данные, а для приведения его в итоговое состояние администратор обязательно должен нажать на кнопку «ввод». Но администратор может передумать и нажать в браузере кнопку «назад» или вообще закрыть окно, а в базе останется недоработанный раздел. Такие вещи не часто, но все же встречаются в системах администрирования. Это явная и очень опасная избыточность. При современном уровне развития PHP и MySQL это просто не нужно.
Так что при создании административной части сайта необходимо всегда делать поправку на то, что администратор может обладать куда меньшим уровнем компьютерной грамотности, чем хотелось бы вам. И пусть лучше администратор в ответ на свои действия получит вежливый и подробный комментарий от сайта, чем будет гоняться за вами с постоянными вопросами «а почему тут ничего не работает?».
В системе управления сайтом, как и в его обычных разделах, учет возможных «нестандартных» ситуаций никогда не бывает лишним.