Xpoint
   [напомнить пароль]

метод распределения прав 2

Метки: [без меток]
2005-08-19 15:45:38 [обр] Иван Шумков(0/77)[досье]

Столкнулся с тем, что Роли - как метод распределения прав - слабоват для моего случая. Хотелось бы определять для обьекта не только Роль, но и группу пользователей, конкретных юзеров, проверять на владельца в конце концов.

Слышал умное слово ACL и видел его реализацию в NPJ.
Пришло в голову сделать несколько моделей доступа:

  1. Гость
  2. Роли
  3. Владелец
  4. Группы пользователей
  5. Конкретный пользователь

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

Оставшееся четыре модели обьеденить в одну большую модель - acl (в моем, наверно, понимании).

Тоесть у обьекта мы устанавливаем права на чтение: группе "Наш дом - Россия" и пользователю Васе и не разрешаем Коле (он у нас состоит в "Наш дом - Россия").

И модель acl (опятьже в моем понимании) проверяет:

  1. Владелец?
  2. Состоишь в группе "Наш дом - Россия"?
  3. Являешься Васей или Колей?

Насколько эта система правильная? Как нормальные люди реализуют подобные моменты? Прокомментируйте пожалуйста.

спустя 1 час 20 минут [обр] GRAy(0/259)[досье]
Роли и группы пользователей - не одно и то же! ;)
Роль - это объединение привилегий на какие-либо действия над какими-либо объектами.
Группа пользователей - это группа именно пользователей, отражающая совсем другую иерархию.
Техничиески между ними действительно мало разницы, но с точки зрения администрирования гораздо удобней разделять эти понятия, т.к. роли наследуются снизу-вверх (роль которой присвоена одна или несколько других наследует все их права) а группы пользователей сверху-вниз (пользователь или группа пользователей включённая в другую группу наследует все права группы). Практика (моя :) ) показывает, что отсутсвие в системе одной из этих абстракций становится неудобной при большом кол-ве объектов администрирования и большом кол-ве пользователей (порядка 1000 и 200 соотв.) Приходится рисовать дополнительные интерфейсы управления и вводить "псевдо" роли (группы с определённым назначением).
спустя 1 час 18 минут [обр] Иван Шумков(0/77)[досье]

GRAy[досье]

Практика (моя :) ) показывает, что отсутсвие в системе одной из этих абстракций становится неудобной при большом кол-ве объектов администрирования и большом кол-ве пользователей (порядка 1000 и 200 соотв.) Приходится рисовать дополнительные интерфейсы управления и вводить "псевдо" роли (группы с определённым назначением).

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

спустя 4 часа 30 минут [обр] GRAy(0/259)[досье]
Обойтись сможете ;) Но вот удобство администрирования теряется. Группы пользователей как правило отражают иерархию подчинения на каком-либо предприятии. Иерархия доступа к ресурсам не всегда совпадает (вернее даже как правило не совпадает) с иерархией подчинения в этом собственно и неудобство ;) а технически ничего невозможного нет.
Powered by POEM™ Engine Copyright © 2002-2005