Разное

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

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

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

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

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

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

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

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

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

У нас в 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 Проблемы возникают только в ключевых модулях вроде каталога или статей - там уже без дополнительной работы не обойтись, так как иногда требуются права доступа на конкретные разделы каталога (но это тоже все решаемо).

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

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

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

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

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

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

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

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

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

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

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