Как закрыть администраторский раздел? Apache с .htaccess против PHP-сессий

28.02.2007

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

Нашлось два распространенных варианта:
* закрыть доступ к папке с администраторскими скриптами средствами Apache с помощью .htaccess и .htpasswd,
* воспользоваться PHP-сессиями и хранением пароля в базе данных.

Альтернатива с .htaccess показалась проще, к тому же у хостера был веб-интерфейс для ограничения доступа к папкам.

Плюс варианта с базовыми средствами Apache? Приемлемый уровень надежности с минимальными временными затратами.

Потом я постепенно стал знакомиться с разным web based ПО, и первое время с удивлением отмечал, что множество разработчиков пользуется сложными схемами с PHP-сессиями. Понемногу я стал понимать, в чем дело.

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

Теперь неочевидное преимущество. При организации управления контентом сайта со сложной структурой при выборе варианта с .htaccess всю эту структуру придется повторить в админке. И, скорее всего, это будет выглядеть как-то по-другому, нежели копирование страниц сайта с добавлением ссылок на редактирование и удаление.

Когда администраторский раздел закрывается средствами языка, ссылки на добавление новых записей, редактирование и удаление существующих можно вписать в сайт, ничего не дублируя.

Если на страницу заходит привилегированный пользователь, то под каждым информационным блоком ему можно показывать ссылки на управление содержимым. Увидел опечатку в описании товара, кликнул по ссылке «Редактировать», тут же исправил и вернулся на страницу с описанием.

При использовании .htaccess процесс будет выглядеть по-другому: администратор увидел опечатку, создал в браузере новую вкладку, там загрузил администраторскую панель, нашел там товар, отредактировал, вернулся на первую вкладку и посмотрел, всё ли теперь в порядке.

С точки зрения безопасности оба варианта вполне приемлемы.

Резюме

Если структура сайта простая, администраторов мало — меньше проблем доставит вариант с .htaccess.

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

Комментарии

Mr. Mishin Oleg, 28.02.2007 11:50

Редактирование данных на внешней (читай - публичной) части сайта возможно, но в ограниченных количествах. Допустим вместо удаления какйо-то информации с сайта через внешнюю часть достаточно поставить ссылку "Скрыть с сайта". Это убьет двух зайцев: позволит давать доступ не самым опытным модераторам и защитит данные от стирания. Информация скрыта = сайт приведен в должный вид, но всегда можно все вернуть на круги своя.
А внутри, особенно на сложных проектах, представление принципиальным образом отичается, потому как на передний план выходят задачи Управления, в том числе обработки потоков/выборок данных. Да и система распределения доступа там на порядок сложнее нежели на внешней части, где обычно хватает гость+пользователь+модератор. В админке же по хорошему должны быть разные группы пользователей с настройкой не только доступа к разделам, но и видов доступа (чтение/запись), и в том числе настройка внешнего вида форм управления, как то доступ на чтение/запись отдельных полей в каждых типах данных.

Кроме того, как показывает опыт - очень полезно иметь в системе управления систему отката любых действий - очень помогает =)

Mr. Mishin Oleg, 28.02.2007 11:57

Забыл написать, что в админке доступ временами требуется разным группам на разные действия, к примеру одна группа пользователей может тольео добавлять новости на сайте (Корреспонденты), а вторая группа - в которую входит главный редактор - изменяет/удаляем новости и разрешает к публикации.

Mr. Mishin Oleg, 28.02.2007 11:58

И еще одно сообщение - теперь меня можко квалифицировать как жестокого спамера =))))

Павел, 06.12.2008 17:13

Учите .htaccess. Есть поддержка групп, реализованная отлично. Всё дело только в ваших навыках - даже шифрацию можно организовать средствами сервера.

Павел, 06.12.2008 17:19

Ах, да, вот ссылка в помощь :)
http://pear.php.net/manual/en/package.filesystem.file-htaccess.php

Дмитрий Сергеев, 28.02.2007 12:23

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

Никогда не видел администраторской панели, полностью интегрированной со страницами сайта. Показателен пример с форумами, когда модераторам удобно «расправляться» с неугодными постами и пользователями на месте, а администраторы создают группы, настраивают разделы, задают разные параметры в администраторской части. При этом в этой «администраторской части» зачастую есть и более мощная реализация «интегрированной функциональности».

Кочанов Сергей, 12.03.2007 23:51

Посмотри как-нибудь как Битрикс работает. Там как раз админка очень сильно интегрирована со страницами.

Дмитрий Сергеев, 13.03.2007 00:52

На счет "Битрикса" у меня предубеждение :) А админка сильно интегрирована со страницами в том же PHPBB.

drumrock, 17.03.2007 14:49

А вы посмотрите на свежие версии Битрикса - четвёрка была сильно неуклюжая по сравнению с пятой версией. А в 5.1-й ещё и переписали ядро, так что тормозов ощутимо меньше.

Насчёт .htaccess. У него есть ещё одна проблема - невозможно реализовать логаут средствами на сайте. Единственный вариант - принудительная очистка сессий авторизации пользователем в настройках браузера. Это критично, если предполагается использование админки и в интернет-кафе, скажем.

Дмитрий Сергеев, 17.03.2007 15:15

Да, слышал что «пятерка» получше. Всё равно рано или поздно столкнусь, так что попробую на досуге.

А описанный недостаток авторизации с помощью .htaccess видел: у нас в университете была система дистанционного обучения. Так вот приходишь на пару, заходишь на сайт и попадаешь в чужой аккаунт.

Изюминка в том, что вкладка с настройками IE закрыта администраторами «в целях безопасности». И выйти крайне проблематично, а значит и под своим именем не зайти.

Mr. Mishin Oleg, 28.02.2007 11:51

а на счет .htaccess - рекумендуется только на очень простых проектах, потому что уровень защиты минимальный =(

Дмитрий Сергеев, 28.02.2007 12:30

Мне кажется, если хостер толковый и пароль длинный, то вполне нормальный уровень защиты.

Хотя логин и пароль не шифруются при передаче. Да и грамотных хостеров не так уж и много.

Так что есть, конечно, проблемы :)

Mr. Mishin Oleg, 28.02.2007 12:42

особенно, проблема с неконтролируемым и быстрым(в смысле - без задержек) подбором такого пароля =)

Дмитрий Сергеев, 28.02.2007 12:52

Ну если он действительно длинный, его нет в словаре и он содержит разные апострофы и решетки, то сложно подобрать :)

Вася Триллер, 01.03.2007 20:17

Не всяк сервер .htaccess поддерживает

Дмитрий Сергеев, 02.03.2007 10:04

Кстати, да :)

Но судя по табличке в Википедии, почти все так или иначе поддерживают Basic Authentication Scheme.