Добре время суток. Возник такой вопрос, как лучше сделать. Кажеться, что я сильно все усложняю. В общем ситуация. Есть разделы в CMS. В каждом разделе данные посортированы по папкам. Нужно: 1) Скрыть некоторые данные от пользовалей (доступны только для привелийованых) 2) Запретить добавление некотрых данных в некоторые папки. ---------- Сделал вот что: для каждого пользователя выставляютсся парва (от 0 до 10) 10 это обычнй пользователь 0 админ. Дальше возникает куча идей но все они мне не нравяться либо слишком сложно либо нелогично и можно запутаться. -- 1. Решил для каждой папки выставлять два атрибута Права для просмотра и права для записи (добавления) Скажем, если выставить 10/5 Пользователи могут только видеть содержимое папки, добавлять только модераторы (припустим у модераторов права 5) Если выставить 5/10 то пользователи видеть содержимое не смогут, зато смогут добавлять новые элементы. Нужно для того, чтобы иметь возможность просмотреть модераторам что добавили, и только потом (если нужно) перенести в общедоступную папку. Все-равно как-то заумно выглядит. Дальше (к примеру галерея). Существуют такие категории Код (Text): Города/Мосва/2008 Города/Москва/2009 Города/Полтава/Лето Города/Полтава/Зима Папка "Москва" общедоступна, а "полтава" хочу сделать доступной только для моих знакомым. Ставлю права для чтения 8. Тоже есть варианты: либо скрыть пообще это папку, либо скрыть ее только содержимое. [sql]SELECT * from folders where parent='города' and permission=>$user['permission'][/sql] Если скажем выполнить выборку всех фоток, которые сделал Вася [sql]Select * from fotos left join folders on (folders.permission=>$user['permission']) where folos.autor='Вася'[/sql] Выборка всех фоток по автору "Вася" если они леат в "доступной" папке. А если скажем эта фотка не в папке Полтава а в Полтава/лето Так нужн "отслеживать" атрибуті для всех дочерних папок, чтоб они были не выше, чем в родительской... В общем запутался, не знаю в какую сторону идты, подтолкните в нужном направлении, если это не тяжело.
http://en.wikipedia.org/wiki/Role-based_access_control http://en.wikipedia.org/wiki/Access_control_list и вообще http://en.wikipedia.org/wiki/Computer_security_model
Не нужно. Есть два варианта. Права родительского узла выше прав потомка. (если у нас есть право записи в корень, то мы можем записать в любую точку дерева) Права потомка выше прав родительского узла. (если у нас есть право записи в конкретную точку, то на права родителя нам наплевать) И два подхода. Все что не разрешено - запрещено. Все что не запрещено - разрешено.
То есть даже администратор сможет выставлять атрибуты для корневых папок? А трибуты дочерних папок полностью наследуют атрибуты родительских папок? ------- Но все равно выборка из БД типа: [sql]SELECT * FROM fotos WHERE author={$_GET['author']}[/sql] Не учитывает права доступа. Ведь фотография может лежать в папке, к которой запрещен доступ прльзователей.
да, это один из вариантов. Сделай чтобы учитывала. В чем сложность? Ты не путай две вещи. Папки на сервере и виртуальные папки в CMS. Последние могут существовать только в виде функций приложения без физической привязки к конкретному месту. site.ru/photo/user/Vasya/list Никаких папок photo, user, Vasya, list может не быть. А есть например файл photo.php который получает параметр user=Vasya, view=list
[sql]Create table folders (id integer primary key, name text, parent text, title text, createdate text default CURRENT_DATE, permission integer....[/sql] Создаю папку с определенными правами: [sql]INSERT INTO folders (name, parent, title, permission) VALUES (folder, NULL, Папка, 7);[/sql] Теперь, если я захочу создать подпапку в данной папке есть два варианта заблокровать опцию выбора атрибутов и автоматически прописывать в качестве атрибута атрибуты "верхней" папки, или не писать ничего. 1) В первом случае, если я изменю права на родительскую, нужно будет менять права и на все дочерние папки. Вариант мне не нравиться, но очень удобно выбрать записи. [sql]Select * from fotos left join folders on (folders.permission=>{$user['permission']}) where fotos.autor='Вася'[/sql] Запрос в даном случае верен? 2) Оставлять поле прав "пустым" так как они полностью такие же как и у родителя. Но тогда даже не представляю, какой должен быть запрос к БД? [sql]Select * from fotos left join folders on (folders.permission=>{$user['permission']}) where fotos.autor='Вася'[/sql] Не прокатит, так как права (folders.permission) могут быть пустыми [sql]INSERT INTO folders (name, parent, title, permission) VALUES (folder, NULL, Папка0, 7); INSERT INTO folders (name, parent, title, permission) VALUES (1, folder, Папка1, NULL); INSERT INTO folders (name, parent, title, permission) VALUES (2, 1, Папка2, NULL); INSERT INTO folders (name, parent, title, permission) VALUES (3, 1, Папка3, NULL); INSERT INTO fotos (parent, filename, author) VALUES (folder, aaa.jpg, VASIA); INSERT INTO fotos (parent, filename, author) VALUES (2, bbb.jpg, VASIA);[/sql] Что получилось: фотка aaa.jpg оказалась в папке с установленными атрибутами, а фотка bbb.jpg в папке "без атрибутов"поэтому вышеприведенный запрос по автору не сработает. Конечно, если я захочу отобразить содержимое по категориям тут проблем не возникнет [sql]SELECT * FROM folders WHERE permission>={$user['permission']}[/sql] в результате папка folder не будет выбрана из БД, если права пользователя этого не позволяют... Тут проблем нет, все довольно-таки ясно..
Можно меня избавить от конкретики запросов? Напрягаться и вникать не хочется а не читать их я не могу Что касается логики создания подпапки 1. Читаем аттрибуты родителя. 2. Выводим форму создания подпаки с инициализированными! аттрибутами (значения мы взяли у родителя). 3. Пользователь может поменять аттрибуты, а может оставить как есть. 4. Получаем данные и записываем (включая аттрибуты).
Обычно самый простой вариант. Тем более для админки, когда происходит редактирование, производительность не критична. А чтение много проще - что важно так как читать права будут все модули кому не лень