В UMI.CMS используется разграничение прав доступа к страницам сайта и к функционалу на уровне пользователей и групп пользователей. Разграничение доступа на страницы позволяет разграничивать доступ на просмотр и редактирование отдельных разделов сайта. Ограничение доступа на функционал используется для управления доступом к операциям, которые пользователь может совершить на сайте: отредактировать свои настройки, проголосовать и т.д..

Наследование прав

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

Важно

В целях оптимизации было добавлено следующее поведение: ни один пользователь не может иметь прав меньше, чем есть у пользователя "Гость"

Права на функционал

В UMI.CMS функциональной единицей является связка модуль/метод и функциональные права применяются именно к ней. Функциональные права выставляются в редактировании пользователя из административной части. На этой странице все права разбиты на модули и у каждого модуля есть набор прав, которые можно относительно него назначить пользователю. Это корневые права.

Корневые права доступа определяются в настройках модуля, в реестре. У каждого модуля module_name есть ключ в реестре вида "//modules/module_name/func_perms", где каждый ключ это корневое право на какое-либо действие. Например, для модуля "новости" это выглядит так: в реестре "//modules/news/func_perms" есть 2 ключа: view, lists и publish (это корневые права). В настройках пользователя это чекбоксы "Просмотр новостей", "Управление новостями" и "Возможность публикации". Если поставить пользователю галочку "view", то ему можно будет выполнять метод news::view(), если он существует.

Так как действие "Просмотр новостей" подразумевает, что при включенной галочке мы должны получить доступ не к одному методу, а к нескольким, введено такое понятие как подправа. Это права, которые логически объединяются в группу по корневому праву (например, по "view"). Каждый раз заносить подправа в реестр было бы утомительно, поэтому они обычно выносятся в файл "permissions.php", который размещается в папке модуля. Для модуля новостей это файл "~/classes/modules/news/permissions.php.

<?php
 $permissions = Array(
  'view' => Array('lastlist', 'listlents', 'rubric', 'related_links', 'rss', 'item', 'lastlents'), 
  'lists' => Array('add_item_do', 'del_item', 'edit_list', 'edit_list_do', 'del_list', 'subjects', 
    'subjects_do', 'add_item', 'add_list', 'add_list_do', 'edit_item', 'edit_item_do', 'last_lists', 'item.edit', 'rubric.edit', 'activity', 'add', 'edit', 'del')
 );
?>

Как видно, тут перечислены все подправа относительно корневых прав. В момент, когда система проверяет права, например на news::lastlist(), определяется корневое право в соответствии с permissions.php (в нашем случае это view) и проверяет права именно на корневой метод.

Замечание

Изменения в файле permissions.php действительны сразу после их внесения. Т.е. дополнительных действий не требуется

Замечание

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

Замечание

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

Права на методы необходимо выставить, в т.ч. для того, чтобы можно было отобразить страницу. Если мы пытаемся отобразить новость, то сначала проверяются права на базовый модуль/метод этой страницы (news::item()), а потом уже непосредственно доступ на чтение самой страницы.

Права на страницы

Права доступа на страницы определяют возможность просмотра или редактирования этих страниц. Так есть 3 уровня доступа к страницам: 0, 1, 2 - "нет доступа", "только чтение", "чтение и запись". Наследование прав пользователя от его групп работает так же, как и для прав на функционал.

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

В том случае, если права явно не задаются при создании страницы, они определяются следующим образом:

  1. Определяется базовый модуль/метод страницы (например, news::item())

  2. Берется список групп пользователей и пользователей вне групп

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

  4. Если есть доступ на выполнение, то ставится право на чтение

Замечание

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

Права на объекты

Непосредственно на объекты права не выставляются (т.е. 2 виртуальные копии одной страницы вполне могут иметь разные настройки прав, но ссылаться на один и тот же объект). Однако, существует механизм владения объекта.

Для объектов введен термин владелец объекта: владелец объекта — это пользователь, под которым был создан этот объект.

Замечание

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

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