passport - privilege - Часто задаваемые вопросы

> Вопрос: Как можно использовать систему управления привилегиями для того, что бы пользователи могли редактировать только свои сообщения в форуме?
[...]
> В таком случае, редактирование сообщения возможно, если текущий пользователь - владелец сообщения (что проверяется самим форумом) и у текущего пользователя есть привилегии на редактирование своих сообщений (проверяется подсистемой управления привилегиями).

Вопрос: как свести эти две проверки во времени (и в месте)? То есть, как сказать системе безопасности (которая изначально ничего не знает про структуру объектов сайта), что для выполнения какого-то действия кроме наличия привилегии нужно еще и выполнение некоего условия, зависящего от входных параметров

Предлагаю добавить понятие «условная привилегия», в комплекте к которой идет имя класса и функции, которая анализирует входные параметры, и результат этот функции учитывается при проверке привилегий.

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

Юрий Истомин (Screamer)

> Вопрос: Как можно использовать систему управления привилегиями для того, что бы пользователи могли редактировать только свои сообщения в форуме? [...] > В таком случае, редактирование сообщения возможно, если текущий пользователь - владелец сообщения (что проверяется самим форумом) и у текущего пользователя есть привилегии на редактирование своих сообщений (проверяется подсистемой управления привилегиями). Вопрос: как свести эти две проверки во времени (и в месте)? То есть, как сказать системе безопасности (которая изначально ничего не знает про структуру объектов сайта), что для выполнения какого-то действия кроме наличия привилегии нужно еще и выполнение некоего условия, зависящего от входных параметров Предлагаю добавить понятие «условная привилегия», в комплекте к которой идет имя класса и функции, которая анализирует входные параметры, и результат этот функции учитывается при проверке привилегий.

Нет, «условная привилегия» - это не совсем то. На самом деле можно говорить о наличии нескольких уровней в проверке привилегий.

Первый уровень, самый низкий - это собственно сама подсистема управления привилегиями. Эта подсистема ничего не знает о структуре всего остального сайта. Как очень упрощенный вариант, эту подсистему можно рассматривать как отвечающую на вопрос «записал ли кто-нибудь в список привилегий текущего пользователя такую-то строку?». «Такая-то срока» - это имя привилегии. Больше подсистема управления привилегиями ничего не проверяет.

Второй уровень - я его у себя называю «проверка возможностей». На этом уровне мы уже знаем структуру системы, для которой следует распределять привилегии. Раньше этого уровня у меня не было, но со временем оказалось полезным выделить его все же в отдельный уровень. Этот уровень так же занимается проверкой привилегий, однако по смыслу он уже не принадлежит подсистеме проверки привилегий, а принадлежит той системе, для которой распределяются привилегии. На этом уровне мы уже не говорим о проверке привилегий, а как бы задаем вопрос, может ли пользователь выполнить такое-то действие над таким-то объектом. Понятно, что на этот вопрос мы отвечаем с учетом проверки привилегий. Для каждго отдельного действия создается отдельная функция, которая проверяет возможность его выполнения. На этом уровне (внутри этих функций) мы:

• проверяем дополнительные условия (такие как является ли пользователь владельцем сообщения)

• задаем имена базовых привилегий

• формируем имена привилегий (задача формирования имени привилегии не всегда столь тривиальна, как это может показаться на первый взгляд)

• задаем, что для выполнения этого действия необходимо обладание одновременно_несколькими (какими?) или одной_из (каких?) привилегий.

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

Под словом «привилегии могут создаваться администраторами» я имел в виду, что в системе могут появиться привилегии, имена которых программист не знает. Действительно, как это предложено в вопросе о доступе к редактированию одного раздела новостей, именно администратор задает имя раздела новостей, которое будет подставляться в имя привилегии. Однако именно программист решает, что это имя новостей нужно прочитать из базы и на его основе сформировать имя проверяемой привилегии. Именно программист пишет функцию уровня «проверки возможностей», которая сопоставляет это имя раздела новостей тому действию, возможность выполнения которого проверяет эта функция.

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

Кстати, еще мысль: к группам пользователей указывать роли по умолчанию. Эти роли автоматически копируются пользователю при его добавлении в данную группу, после чего теряют связь с группой - можно как угодно менять их состав, при изменении состава ролей у группы у пользователей этой группы изменения не проводятся, при выводе пользователя из группы роли, добавленные в связи со входом в группу, не отбираются. То есть, банальная автоматическая копировалка

Можно, в общем-то.

Хотя, в текущей версии не составляет труда скоприровать один список привилегий в другой (как между пользователями, так и из роли - пользователю). При редактировании список привилегий рассматривается как обычный текстовый файл, и редактируется он в textarea. Ctrl-Insert, Shift-Insert и все дела.Вроде как

Гость: Анонимный Пользователь не может обладать привилегиями. Получается, что он даже смотреть ни на что не может?.. Юрий Истомин.

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

А при создании новой страницы надо автоматически создавать новую соответствующую привилегию?

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

Или что Вы имели в виду?

А как Вы собираетесь «говорить системе», что данное действие надо проверить на доступ?

Я рассматриваю случай, когда на входе в цмс стоит общая система безопасности, которая проверяет весь доступ

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

Все зависит от способа проверки привилегий. Если Вы распределяете доступ к иерархически организованному объекту, то имеет смысл проверять наличие «этой или любой родительской привилегии». В таком случае, если пользователь обладает привилегией page.a.b, то он автоматически получит доступ к папкам a/b, a/b/c, a/b/c/d, a/b/e и т.п.

Я уточню вопрос: хранятся ли в системе ВСЕ привилегии, соответствующие ВСЕМ объектам (для проверки валидности этих привилегий, например)?

В приведенном Вами примере следует храниьт только одну, родительскую привилегию.

для проверки валидности этих привилегий, например

имя привилегии считается валидным, если оно соответствует правилам составления имен привилегий.

Гость: Я хочу дать полные права на раздел news.a.b.c Мне нужно разрешать все привелегии вида news.*.a.b.c ?

Как возможный вариант - да.

Другой вариант - дополнительно требовать привилегию типа news.access.a.b.c для выполнения каждого действия. Тогда для полного доступа все привилегии (все news.*, кроме news.access[.*]) можно будет перечислить внутри одной из ролей, а привилегию news.access.a.b.c - давать администраторам отдельно, в зависимости от того, кто куда имеет доступ. Этот способ хорош еще и тем, что если мы не хотим им пользоваться, то просто разрешаем привилегию news.access, а разрешения на конкретные разделы задаем привилегиями news.*.a.b.c.