Разное

Добрый вечер, дорогие форумчане.

Сижу я тут, пишу как обычно свой сервис. Затронулась тема организации администрации на сайте. Ничего рекламировать и пропогандировать я здесь не собираюсь. Хочется поговорить на больную на данный момент тему для меня — организация администрирования на сайте.

У меня уже организована система, но она мне не нравится. Секретов таить не буду, идеи всего две:
1) Организация двух групп: главные администраторы и помощники. Каждая группа имеет те или иные возможности. Естесственно, помощники могут меньше, нежели главные администраторы.
2) Просто добавление администраторов и уже каждому из них приписываются те или иные возможности (т.е. составляется список, права выбираются через chekbox).

Сложность не написать код. Сложность — придумать ещё более простую, но функционально-гибкую систему администрирования. Простую не только для самих администраторов, но и для обычных пользователей, чтобы они могли разобраться к кому и по каким вопросам можно обратиться, что каждый из администраторов может сделать. Плюс ко всему, нужно будет визуально изобразить (дерево, линейно, ещё как-то) всех администраторов по их возможностям.

Вот такой вопрос, дорогие читатели-писатели. Что скажете?

Хм... мы делаем так - идем по второму варианту, весь сайт разбивается на модули (это удобно, можно вынуть один модуль, не затрагивая других или вставить), каждый администратор может управлять одним, несколькими или всеми модулями (т.е. можно дать права на один модуль или все). В рамках каждого модуля имеются ряд действий: чтение (например, чтобы ответить на запрос), редактирование (внести какие-то изменения), удаление/бан (чтобы произвести деструктивные действия). Здесь также при помощи флажков можно наделить администратора одним или всеми тремя свойствами. Бывают приложения, которые сложны в организации, например, каталоги - тут разбивка прав доступа идет уже по конкретным уровням или конкретным каталогам.

Спасибо, буду иметь ввиду.

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

<?php   //админ редактирует и страницы, и новости   if($status == 'admin')   {      switch($page)      {         case 'news' : include('news.inc'); break;         case 'pages' : include('pages.inc'); break;         default : print "Запрещенная зона";      }   }   //менеджер редактирует только новости   if($status == 'manager')   {      switch($page)      {         case 'news' : include('news.inc'); break;         default : print "Запрещенная зона";      }   } ?>

Мне нравится такой подход. При желании можно легко добавить нового пользователя. Еще удобно то, что с правами заморачиваться придется только в 1 файле.
Необходимое условие: необходимо запретить исполнение модулей отдельно вне системы. Как вариант, можно использовать расширение файла (.inc). Только нужно запретить просмотр кода таких файлов через браузер в .htaccess.

Спасибо, буду иметь ввиду.

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

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

Может здесь в значении «incubation» )

>если не секрет, почему файлы с расширением inc? чем это обосновано?

В книжке Веллинга и Томпсона советовали подключаемым модулям давать расширение .inc (included - включен). А так, расширение можно любое поставить, главное запретить просмотр кода. Традиция, наверное, из другого языка идет. Cheops, может быть, знает.

я делаю расширение .inc.php и браузером не откpоется и от остальных РHР-скриптов
отличается

Будет от всех отличаться, если просто в особую папку положить )

хм. ясно.
мы обычно такие файлы именуем с нижним подчеркиванием впереди

На вкус и количество соли, как говорится )

>В книжке Веллинга и Томпсона советовали подключаемым модулям давать расширение .inc

Если интересно, нашел этот момент в книжке (стр 118):

Расширение имен файлов и оператор require()

PHP не обращает внимание на расширение запрашиваемого файла. Следовательно, файл можно называть как угодно, если только он не будет вызываться непосредственно. При использовании оператора require() для загрузки файла, файл фактически становится частью PHP-файла и будет выполняться как таковой.
Обычно PHP-операторы не должны выполнятся, если они находятся в файле, названном, например, page.html. Как правило, PHP вызывается только для анализа файлов с определенными расширениями, такими как .php. Однако если загрузить файл page.html через оператор require(), любые хранящиеся внутри него PHP-операторы будут обработаны. Следовательно, для включенных файлов можно использовать любые расширения, однако имеет смысл придерживаться практичного соглашения и использовать расширения наподобие .inc
При этом следует иметь в ввиду, что если файлы, имеющие расшрирение .inc или какое-либо другое нестандартное расширение, сохраняются в дереве документов Web, и пользователи непосредственно загружают их в браузеры, они смогут посмотреть код в виде простого текста, что распространяется и на любые пароли. Поэтому важно либо хранить включаемые файлы вне дерева документов, либо использовать стандартные расширения.

В этом-то и не удобство, что файл .htaccess, закрывающий доступ к ним может быть случайно удален или не работать, если дело происходит под управлением IIS - в общем добавляется дополнительный фактор риска. Помоему стандартом стало расширение .inc.php, которое показывает что файл включаемый и изначально ведет себя как PHP-файл.

Больше размышлений не будет?

Что ж, спасибо.