popoff.donetsk.ua title

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

Управление одним разделом иерархического каталога

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

Просмотр одного раздела иерархического каталога

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

Списки друзей

Как можно реализовать такое: у пользователя «список друзей», у каждого свой. И добавляя новость, пользователь желает, что бы видели эту новость только друзья из этого списка.

Иерархия привилегий

Что такое «иерархия привилегий»? Для чего она нужна?

Иерархия ролей

Что такое «иерархия ролей»? Для чего она нужна?

Иерархия администраторов

Что такое «иерархия администраторов»? Для чего она нужна?

Иерархия объектов

Может ли эта система управления привилегиями разграничивать доступ к иерархическим объектам? Каким образом?

Выполнение нескольких ролей

Может ли пользователь выполнять одновременно несколько ролей?

Группы пользователей

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

Принадлежность нескольким группам

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

Разрешение конфликтных ситуаций

Как разрешается конфликт, если пользователь выполняет несколько ролей, и в одной из ролей привилегия разрешена, а в другой - запрещена?

Неопределённые состояния системы

Какие неоднозначности возможны при задании привилегий?

Загрузка памяти и кеширование

Какая информация загружается в память при проверке привилегий? Что кешируется при проверке привилегий?

В чём отличие «привилегии пользователей» от «привилегии администраторов»?

В некоторых местах используется один термин, а в некоторых - другой. Что это означает?

Пример использования системы

Как назначить ту или иную привилегию на то или иное действие?

Смотрите так же

Дополнительная информация

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

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

Поскольку все привилегии идентифицируются по именам, то и для каждого раздела новостей следует задать имя (добавить в базу данных новое поле, в котором будет храниться имя этого раздела новостей). Привилегия для управления новостями в любых разделах тогда имела бы имя, например, news.edit, а привилегия для управления новостями только в разделе “sport” имела бы имя news.edit.sport. То же самое касается и тем форумов.

Эта возможность не относится к системе управления привилегиями администраторов. Это свойство самой службы новостей, будет ли она требовать привилегию для просмотра, или не будет. Как один из простейших вариантов, можно добавить в базу данных службы новостей дополнительное поле - «требовать ли привилегию для просмотра?», и требовать привилегию в случае, если в этом поле записано «да». В более сложном случае для каждой новости (и/или раздела новостей) можно указать имя требуемой привилегии. Далее - по нарастающей, можно указать, какие имена текущий пользователь может указывать в этом поле. Например, для установки имени требуемой привилегии “personal.popoff”, можно потребовать у пользователя привилегию с именем, например, news.restrict.personal.popoff или любую родительскую привилегию, например, news.restrict (в случае, если пользователь может указывать любую привилегию в этом поле).

Это означает, что просмотр новостей ограничен привилегиями. Если ограниченные новости, например, находятся в разделе “personal.popoff”, то для просмотра новостей этого раздела требовалась бы привилегия, к примеру, с именем news.view.personal.popoff. В таком случае пользователь, о котором речь шла в вопросе - это администратор, обладающий привилегией admin.edit.news.view.personal.popoff (для управления этой привилегией у других пользователей) и привилегией admin.group.nogroup, для управления пользователями, которые не принадлежат ни одной группе (вновь зарегистрированные пользователи). Передав привилегию news.view.personal.popoff некоторому другому пользователю, администратор фактически включает этого другого пользователя в список своих друзей.

Следует отметить, что способов решения поставленной в вопросе задачи - очень много. Если, например, друзья из этого списка должны иметь возможность не только просматривать новости из соответствующего раздела, но и получать доступ куда-нибудь еще, то имеет смысл создать роль, в этой роли разрешить все необходимые привилегии, и далее разрешать «друзьям» выполнять эту роль. Если эта роль называется “popoff”, то в таком случае администратор должен как минимум обладать привилегией admin.edit.role.popoff (для управления этой привилегией у других пользователей) и привилегией admin.group.nogroup, для управления пользователями, которые не принадлежат ни одной группе (вновь зарегистрированные пользователи). Передав привилегию role.popoff некоторому другому пользователю, администратор фактически включает этого другого пользователя в список своих друзей.

Что такое «иерархия привилегий»? Для чего она нужна?

Иерархия привилегий соответствует иерархии объектов, к которым следует ограничить доступ. Иерархия привилегий полностью определяется иерархией имен привилегий.

Иерархия привилегий используется для того, что бы можно было указать, что пользователь имеет доступ к некоторому объекту и всем подчиненным объектам. Например, если пользователь может редактировать статьи в папке a/b/c и в любой вложенной папке, то пользователь должен обладать привилегией text.edit.a.b.c. Если же пользователь должен иметь возможность редактировать привилегии в любой папке, то он должен обладать привилегией text.edit.

То же самое касается и возможностей работы над статьями. Если, например, статьи можно редактировать (text.edit), просматривать (text.view), удалять (text.remove), переименовывать (text.rename) и т.п., то для того, что бы сказать, что администратор может делать что угодно с любыми статьями, для него достаточно разрешить привилегию text.

Что такое «иерархия ролей»? Для чего она нужна?

Если в системе мало администраторов и списки их привилегий изменяются редко, то в использовании ролей нет необходимости - для каждого администратора можно отдельно прописать список его привилегий.

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

Другая, не очевидная причина использования ролей состоит в том, что таким образом мы получаем возможность разрешать другим администраторам передавать/отзывать привилегиями пакетами: если администратор может управлять разрешением роли у другого администратора (и не может управлять отдельными привилегиями), то этот администратор не может разрешить или запретить только одну из привилегий - разрешая выполнять роль, он вынужден разрешить/запретить сразу все привилегии, разрешенные/запрещенные в этой роли.

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

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

Если же в системе появляется много разных «типов администраторов», то можно говорить о том, что в системе появляется много разных ролей. Может оказаться, что списки привилегий разных ролей пересекаются, то есть разрешают или запрещают доступ к некоторому общему объекту. В таком случае имеет смысл использовать иерархию ролей, в которой одни роли наследуют списки привилегий других ролей. Выгоды - такие же, как и при переходе к большому количеству администраторов: 1) нам не нужно искать, в каких ролях содержится та привилегия, которую мы хотим изменить; 2) нам не нужно редактировать несколько списков, достаточно отредактировать один; 3) нам не нужно вспоминать, что означает каждая отдельная привилегия при добавлении новых ролей; нам достаточно помнить только о том изменении, которое мы хотим внести.

Что такое «иерархия администраторов»? Для чего она нужна?

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

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

Если иерархии администраторов нет, то даже в простейшем случае, когда в системе два администратора, которые могут изменять привилегии других администраторов, может возникнуть следующая ситуация: я разрешаю некоторому администратору Х редактировать любые привилегии. Администратор Х, получив возможность редактировать любые привилегии, отбирает все привилегии у меня. Даже если я доверяю администратору Х, никто не гарантирует, что не появится некоторый администратор Y, которому администратор Х (например, по доверчивости) разрешит редактировать любые привилегии. Администратор Y, получив возможность управлять любыми привилегиями, отбирает все привилегии как у меня, так и у администратора Х.

Цель введения иерархии администраторов - защитить как себя, так и администратора Х от посягательств друг на друга и при этом все-таки дать им возможность управлять любыми привилегиями у других администраторов.

В простейшем случае, когда администраторов в системе мало, их можно было бы разбить на уровни (как это было сделано в предыдущей версии системы). Уровень - это некоторое число от 0 до 255. Если у меня уровень ниже, чем у администратора, привилегии которого я хочу изменить (передать или отозвать), то я не смогу изменить его список привилегий.

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

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

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

Может ли эта система управления привилегиями разграничивать доступ к иерархическим объектам? Каким образом?

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

Самый простой и родной для многих пример иерархического объекта - структура каталогов: мы должны иметь возможность разрешить некоторому администратору управлять содержимым только конкретных папок.

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

Далее, необходимо получить полный путь (Materialized Path) к управляемой вершине объекта. Например, если мы хотим управлять папкой a/b/c, то a/b/c и есть полный путь к управляемой папке. Далее, этот путь необходимо преобразовать в имя привилегии. В именах привилегий слова разделяются символом точка, поэтому для пути a/b/c будет соответствовать имя привилегия a.b.c. Полученное имя является суффиксом для какой-нибудь базовой привилегии. Базовая привилегия определяет, что администратор может делать, а этот суффикс - с какой именно папкой это действие можно производить. Например, если есть базовая привилегия text.edit, которая позволяет редактировать статьи, то привилегия text.edit.a.b.c будет использоваться для того, что бы редактировать статьи в папке a/b/c. Поскольку для редактирования статей требуется «эта или любая родительская привилегия», то обладание привилегией text.edit.a.b.c позволяет редактировать статьи в папке a/b/c и в любой вложенной папке. В этом же поддереве будут позволять производить редактирование привилегии text.edit.a.b, text.edit.a, text.edit и text. Следует отметить, что привилегия text.edit позволяет редактировать статьи во всех папках, а привилегия text позволяет делать что угодно со статьями в любых папках.

Может ли пользователь выполнять одновременно несколько ролей?

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

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

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

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

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

Дополнительные привилегии администратор может получить, если он выполняет некоторую роль.

Сравните понятие групп и ролей в контексте рассматриваемой системы c тем, как это предложено в статье «Доступ в программах»:
http://www.citforum.ru/programming/digest/access.shtml

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

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

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

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

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

Какие неоднозначности возможны при задании привилегий?

Какая информация загружается в память при проверке привилегий? Что кешируется при проверке привилегий?

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

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

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

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

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

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

В некоторых местах используется один термин, а в некоторых - другой. Что это означает?

Это означает, что «администратор» является частным случаем «пользователя», и, вообще говоря «привилегии администратора» - это то же самое, что и «привилегии пользователя».

Если речь идёт о привилегиях, то предпочтение отдаётся фразе «привилегии администратора». Фраза «привилегии пользователей» практически не используется, слово «пользователь» может использоваться, если речь идёт не о привилегиях, а о чём-нибудь другом, присущем всем пользователям системе и, поэтому, являющемся общим как для администраторов, так и для пользователей.

Например, в фразе «массив с логинами и uid пользователей, которые обладают заданной привилегией» - речь идёт об уникальных идентификаторах, которые являются общими для всех пользователей системы, как администраторов, так и не администраторов. Именно поэтому в фразе используется слово «пользователь». Если фразу написать так: «массив с логинами и uid администраторов, которые обладают заданной привилегией», то может сложиться впечатление, что для администраторов ведутся какие-то другие идентификаторы, отличные от идентификаторов обычных пользователей (не администраторов).

Как назначить ту или иную привилегию на то или иное действие?

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

Пусть, имя базовой привилегии будет news.confirm. Динамические привилегии будут получаться, если к базовым добавлять имена разделов. В данном случае динамические привилегии используются для того, чтобы администратор, распределяющий привилегии, мог указать, в каких разделах главный редактор может подтверждать новости, а в каких - не может.

Все функции уровня проверки возможностей в системе popoff.donetsk.ua/light располагаются в модулях can, например, в случае службы новостей - в модуле news.can.

В качестве аргумента нашей функции будет передаваться путь к каталогу, в котором разделителями имён файлов является слеш, например, main/psy. Имя корневого каталога новостей - всегда пустая строка.

Функция passport_privilege_has - это функция подсистемы управления привилегиями администраторов, которая выполняет проверку привилегий.


<?php function news_can_confirm($s_theme='')
{
  if(strlen($s_theme))
    return passport_privilege_has('news.confirm.'.str_replace('/','.',$s_theme));
  return passport_privilege_has('news.confirm');
}
?>

Шаг 3. Выводим ссылку, кликнув по которой администратор подтвердит новость.

При выводе ссылки известно, какой раздел каталога новостей администратор просматривает. Перед выводом ссылки вызываем функцию news_can_confirm(), и передаём в неё путь к текущему разделу каталога новостей. Если функция возвращает истину (администратор может подтверждать новости в этом каталоге новостей), то показываем ссылку, если ложь (не может подтверждать) - не показываем.

Шаг 4. Программируем функцию обновления базы данных.

С точки зрения базы данных, подтверждённая новость отличается от неподтверждённой значением одного флажка, и функция подтверждения новости состоит в том, что мы просто устанавливаем этот флажок. При подтверждении новости известно, в каком разделе каталога новостей находится подтверждаемая новость. Перед установкой флажка вызываем функцию news_can_confirm(), и передаём в неё путь к текущему разделу каталога новостей. И, соответственно, устанавливаем или не устанавливаем флажок подтверждённости новости в зависимости от возвращённого значения.

Обсуждение системы управления привилегиями в форуме

Кеширование привилегий в переменных сессии vs моментальное применение изменений в списке привилегий
http://popoff.donetsk.ua/forum/EstOdno.html

Система управления привилегиями - чем она похожа на систему прав в Windows XP и phpGACL?
http://popoff.donetsk.ua/forum/takogo.html

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

Система привилегий и владельцы объектов