Разное

Вечер добрый, дорогие друзья.

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

Тема следующая:
«Как правильно и рационально организовать администрирование на своём сайте».

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

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

Очень хочется послушать ваши варианты. Спасибо.

Ну... это здорово зависит от проектов и его целей. Одно дело открытый проект вроде Wikipedia, другое дело коммерческий проект, где от работы администратора зависит все дело. В любом случае много администраторов - это зло, каждый начинает надеяться на другого, в результате дело либо стоит, либо все сваливается на одного человека. Четкого алгоритма нет, это зависит от проекта и наличия адекватных людей (которых не так много на самом деле).

> как определить какому звену что доступно

Я создавал иерархию по цифрам. Т.е. в БД, где хранятся данные пользователя, есть поле, в котором стоит цифра... Каждой цифре соответствует "должность". После этого в скрипте использую обычный if(){да}else{нет}.

На самом деле, высказавшись, вы ничего не сказали.

Допустим, есть такие уровни:
Главный администратор, Администратор, Главный редактор, Редактор, Журналист, Пользователь.

Количество действий, которые может совершать человек, уменьшается слева направо.
Т.е. Главный админ имеет доступ к админке, может добавлять/удалять все остальные группы пользователей, может всё и вся. Администратор может добавлять все нижестоящие группы. Главный редадактор, также, может добавлять удалять редакторов и журналистов. Редактор же может только редактировать, к примеру.

Плюс ко всему, есть еще какие-то функции на сайте (например, журналист не может редактирвоать комментарии, а редактор может).

Допустим самую простую ситуацию, когда, чем выше уровень пользователя, тем больше у него прав (т.е. все, что может человек с более низким уровнем + что-то свое), тогда все довольтно просто - например, главный админ имеет в цифровом отображении доступ 10000, просто админ 9000.... пользователь - 100.

Тогда проверяем if ($lvl > 1000) .. действие.

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

На самом деле, тоже интересует этот вопрос. Скоро столкнусь с ним лбом ко лбу - однако пока не было времени поразмыслить подробнее на эту тему.

Если речь идет только о правах доступа, лучше никаких иерархий не создавать - только лишние проблемы. Лучше ввести для блоков какие-то универсальные действия (просмотр, редактирование, удаление) и формировать для каждого пользователя свой набор действий (напрмер, новости - просмотр и редактирование, каталог - просмотр, редактирование и удаление). Создание пользователей - это тоже блок с таким же набором прав - кто имеет к нему доступ (как правило, главный администратор - вот для него можно ввести исключительные права), тот и создает новых пользователей с нужными правами. Если пользователей меньше 50 то с группами лучше вообще не связываться.

К этим выводам я лично уже пришел.

Меня, например, интересует, как организовать хранение этих настроек, и их обработка на самом сайте.
Т.е. входные условия получаются такие: n групп, у каждой группы k свойств (прав), и на сайте, при генерации контента, надо учесть группу, к которой пренадлежит данный пользователь, и права, доступные данной группе.

У нас в CMS сложилась уникальная ситуация - каждый блок хранится в отдельной директории, а на каждое действие имеется свой собственный файл, поэтому можно ввести файл .htdir (напомню, что файлы начинающиеся с .ht являются невидимыми из под Apache) примерно такого содержания (который по структуре суть ini-файл)

; Название и описание блока [title]   name = "Каталог"   description = "Создание, редактирование и удаление подкаталогов" ; Управление правами доступа [edit]   ; Файлы для которых требуются права доступа на редактирование   1001 = catadd.php   1002 = catdown.php   1003 = catedit.php   1004 = cathide.php   1005 = catshow.php   1006 = catup.php   2001 = posedit.php   2002 = poshide.php   2003 = posshow.php   3001 = typadd.php   3002 = typdown.php   3003 = typedit.php   3004 = typhide.php   3005 = typshow.php   3006 = typup.php   3007 = typdiffposition.php   3008 = typparadd.php   3009 = typpardown.php   3010 = typparedit.php   3011 = typpargrp.php   3012 = typparpar.php   3013 = typparsyn.php   3014 = typparup.php   4001 = imgadd.php   4002 = imgdown.php   4003 = imgedit.php   4004 = imghide.php   4005 = imgshow.php   4006 = imgup.php   5001 = comedit.php   5002 = comhide.php   5003 = comshow.php [read]   ; Файлы для которых требуются права доступа на чтение   1001 = index.php   2001 = position.php   3001 = type.php   3002 = typpar.php   4001 = image.php   5001 = comments.php   5002 = commentslist.php [delete]   ; Файлы для которых требуются права доступа на удаление   1001 = catdel.php   2001 = posdel.php   3001 = typpardel.php   4001 = imgdel.php   5001 = comchkdel.php   5001 = comdel.php

Когда появляются новые подсистемы - их легко можно добавить в конфигурационный файл. В результате можно создать такую систему которая автоматически подцепляет программные блоки, читая настройки (в том числе и по организации прав доступа) из .htdir-файла. Удалил директорию с модулем - он автоматически удалился из системы, скопировал папку с модулем - он автоматически внедрился в систему. Не надо ничего прописывать и регистрировать. Перед редактированием прав доступа система удаляет старые права, сканирует модули и назначает права на них. А уже когда пользователь стучится в модуль вступаютв в действия настройки из .htdir-файла.

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

Ситуация действительно уникальная :)
Но взять суть, я думаю, вполне возможно.

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

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

Кажется я эту проблему решил, но пока домозговываю!

Посмотрите в сторону Zend_Acl

Не на то сообщение ответил, сори.

Спасибо за линк.

Я уже очень давно мучаюсь, как было бы можно создать таких администраторов, которые были бы очень гибки. Т.е. не администраторы, конечно, а система администрирования. И знаете — получилось. Сумел организовать и базу данных, и функции написать по проверке пользователей в качестве администраторов. А спасибо, наверное, стоит мне сказать neadekvat'у. Благодаря его двум-трём словам из его большого сообщения, я смог додумать свои идеи.

Всё что нужно: создать 2 дополнительные таблицы в БД, а в других создавать только по одному нужному дополнительному полю, которое отвечает за права. И сверять допущенные права с созданными таблицами.