Модель безопасности в MODX
Модель безопасности в MODX не самая очевидная. Хотя в MODX присутствуют примитивы, присущие, например, модели безопасности SQL, их предназначение в MODX несколько отличается.
При настройке безопасности конечной целью является дать каждому пользователю соответвующий набор привилегий – разрешить ему совершать определенные действия в системе. Действия могут совершаться над различными объектами: страницами (resource), контекстами (context), чанками (chunk), переменными шаблонов (TV) и т.д. Сами действия могут быть очень разными, в простейшем случае это создание, просмотр, редактирование и удаление. Таким образом, задача настройки безопасности сводится к заданию отношений между пользователями, объектами и привилегиями.
Группы пользователей
Предположим, мы хотим дать пользователю partner доступ к странице «Проекты» на редактирование. В этом примере объектом является страница «Проекты», привилегией – редактирование, а пользователем – partner. Но для того, чтобы реализовать такую схему безопасности, потребуется создать группу пользователей. Дело в том, что в MODX права назначаются именно группе, а не пользователю. Группа – это множество пользователей, обладающих схожими правами. Разумеется, пользователь может состоять в нескольких группах.
Группы страниц
Дать доступ непосредственно к странице «Проекты» тоже не удастся, т.к. система безопасности MODX оперирует только с группами страниц (resource groups), а не с отдельными страницами. Если точнее, то управлять доступом можно на уровне следующих объектов:
Политики доступа
Не будет большой неожиданностью, что и привилегии в MODX объединяются в группы. Группы привилегий называются политиками доступа (access policy). Например, политика доступа может состоять из таких привилегий:
Учитывая всё вышесказанное, алгоритм настройки доступа в MODX можно представить так:
Шаблоны политик доступа
В MODX порядка 200 разных привилегий. Некоторые привилегии логически связаны, например, привилегии регулирующие доступ к страницам или привилегии, регулирующие доступ к чанкам. Для того, чтобы ориентироваться в таком количестве привилегий было проще, в MODX существуют шаблоны политик доступа. Шаблон состоит из набора привилегий, с которыми часто приходится работать вместе, например, если нужно дать доступ на просмотр страницы, велика вероятность, что понадобятся и привилегии на редактирование и создание.
При создании политики доступа в MODX требуется указать шаблон политики доступа. Шаблон отличается от политики доступа тем, что шаблон только группирует привилегии, чтобы с ними было удобно работать в панели администрирования. Шаблон не даёт никаких привилегий, он лишь ограничивает количество привилегий, которые можно назначить политике. Сделано это для удобства: чтобы приходилось искать нужные привилегии не в списке из сотен пунктов, а в списке из пары десятков. Теоретически можно создать шаблон со всеми возможными привилегиями и пользоваться им, но на практике это не очень удобно.
Стоит отметить, что каждая привилегия применима к определённому виду объектов. Например, привилегия на просмотр страниц не может быть использована для предоставления доступа на просмотр контекста, для этого есть отдельная привилегия. Шаблон объединяет привилегии относящиеся к одному типу объектов и, как следствие, определяет, к каким объектам будет применима политика доступа.
Роли
До сих пор мы не касались понятия роли, однако, на практике при попытке настроить права доступа, вы обязательно столкнётесь с ролями. В простых конфигурациях безопасности можно игнорировать роли и везде указывать одну и ту же роль (например, «Super User»), но разобраться в принципе работе ролей всё же стоит. Роли позволяют ограничивать привилегии пользователя внутри группы. Образно говоря, роли позволяют создать внутри группы пользователей «уровни доверия».
Каждая роль имеет ранг: чем меньше числовое значение ранга, тем больше доверия соответствует этой роли. По сути, роль и ранг – почти одно и то же, роль – это ранг, которому присвоено некоторое имя, например «Super User». Когда пользователь добавляется в группу, ему назначается определённая роль. Если ранг роли равен нулю, пользователю оказывается максимально возможное для этой группы доверие, он получает доступ ко всем привилегиям группы.
У каждой политики доступа, назначенной группе пользователей, задаётся минимальная роль, которой должен обладать пользователь, чтобы получить привилегии из этой политики. Здесь есть небольшая путаница: под минимальной ролью имеется в виду, что роль пользователя должна иметь ранг не выше указанного, чтобы он имел доступ к привилегиям из данной политики.
Предположим, есть два пользователя partner и bestpartner с почти идентичным набором привилегий, но bestpartner помимо всех привилегий partner, может ещё редактировать страницу «О компании». Можно просто скопировать настройки доступа partner и присвоить копию пользователю bestpartner, добавив туда недостающую привилегию:
При настройке безопасности конечной целью является дать каждому пользователю соответвующий набор привилегий – разрешить ему совершать определенные действия в системе. Действия могут совершаться над различными объектами: страницами (resource), контекстами (context), чанками (chunk), переменными шаблонов (TV) и т.д. Сами действия могут быть очень разными, в простейшем случае это создание, просмотр, редактирование и удаление. Таким образом, задача настройки безопасности сводится к заданию отношений между пользователями, объектами и привилегиями.
Группы пользователей
Предположим, мы хотим дать пользователю partner доступ к странице «Проекты» на редактирование. В этом примере объектом является страница «Проекты», привилегией – редактирование, а пользователем – partner. Но для того, чтобы реализовать такую схему безопасности, потребуется создать группу пользователей. Дело в том, что в MODX права назначаются именно группе, а не пользователю. Группа – это множество пользователей, обладающих схожими правами. Разумеется, пользователь может состоять в нескольких группах.
Группы страниц
Дать доступ непосредственно к странице «Проекты» тоже не удастся, т.к. система безопасности MODX оперирует только с группами страниц (resource groups), а не с отдельными страницами. Если точнее, то управлять доступом можно на уровне следующих объектов:
- контексты,
- группы страниц,
- категории элементов,
- медиа источники (media source).
Политики доступа
Не будет большой неожиданностью, что и привилегии в MODX объединяются в группы. Группы привилегий называются политиками доступа (access policy). Например, политика доступа может состоять из таких привилегий:
- создание страниц
- чтение страниц
- редактирование страниц
- удаления страниц.
Учитывая всё вышесказанное, алгоритм настройки доступа в MODX можно представить так:
- выделить объекты, доступ к которым необходимо предоставить;
- если доступом к данным объектам нельзя управлять напрямую (например, это страница или чанк), создать группу страниц или категорию элементов и добавить туда интересующий объект;
- создать пользователя;
- создать группу, которая будет носителем прав доступа к интересующим объектам, и добавить пользователя в эту группу;
- создать политику доступа с набором привилегий, которые необходимо предоставить;
- присвоить политику доступа группе пользователей.
Шаблоны политик доступа
В MODX порядка 200 разных привилегий. Некоторые привилегии логически связаны, например, привилегии регулирующие доступ к страницам или привилегии, регулирующие доступ к чанкам. Для того, чтобы ориентироваться в таком количестве привилегий было проще, в MODX существуют шаблоны политик доступа. Шаблон состоит из набора привилегий, с которыми часто приходится работать вместе, например, если нужно дать доступ на просмотр страницы, велика вероятность, что понадобятся и привилегии на редактирование и создание.
При создании политики доступа в MODX требуется указать шаблон политики доступа. Шаблон отличается от политики доступа тем, что шаблон только группирует привилегии, чтобы с ними было удобно работать в панели администрирования. Шаблон не даёт никаких привилегий, он лишь ограничивает количество привилегий, которые можно назначить политике. Сделано это для удобства: чтобы приходилось искать нужные привилегии не в списке из сотен пунктов, а в списке из пары десятков. Теоретически можно создать шаблон со всеми возможными привилегиями и пользоваться им, но на практике это не очень удобно.
Стоит отметить, что каждая привилегия применима к определённому виду объектов. Например, привилегия на просмотр страниц не может быть использована для предоставления доступа на просмотр контекста, для этого есть отдельная привилегия. Шаблон объединяет привилегии относящиеся к одному типу объектов и, как следствие, определяет, к каким объектам будет применима политика доступа.
Роли
До сих пор мы не касались понятия роли, однако, на практике при попытке настроить права доступа, вы обязательно столкнётесь с ролями. В простых конфигурациях безопасности можно игнорировать роли и везде указывать одну и ту же роль (например, «Super User»), но разобраться в принципе работе ролей всё же стоит. Роли позволяют ограничивать привилегии пользователя внутри группы. Образно говоря, роли позволяют создать внутри группы пользователей «уровни доверия».
Каждая роль имеет ранг: чем меньше числовое значение ранга, тем больше доверия соответствует этой роли. По сути, роль и ранг – почти одно и то же, роль – это ранг, которому присвоено некоторое имя, например «Super User». Когда пользователь добавляется в группу, ему назначается определённая роль. Если ранг роли равен нулю, пользователю оказывается максимально возможное для этой группы доверие, он получает доступ ко всем привилегиям группы.
У каждой политики доступа, назначенной группе пользователей, задаётся минимальная роль, которой должен обладать пользователь, чтобы получить привилегии из этой политики. Здесь есть небольшая путаница: под минимальной ролью имеется в виду, что роль пользователя должна иметь ранг не выше указанного, чтобы он имел доступ к привилегиям из данной политики.
Предположим, есть два пользователя partner и bestpartner с почти идентичным набором привилегий, но bestpartner помимо всех привилегий partner, может ещё редактировать страницу «О компании». Можно просто скопировать настройки доступа partner и присвоить копию пользователю bestpartner, добавив туда недостающую привилегию:
- создать группу bestpartner-group;
- назначить новой группе те же самые политики доступа, что были у группы partner-group;
- создать новую политику с недостающими привилегиями и назначить её группе bestpartner-group.
- назначить partner роль Member в группе пользователей partner-group;
- назначить bestpartner роль Super User в группе пользователей partner-group;
- для политик доступа, которые нужно назначить обоим партнёрам, установить минимальную роль Member;
- для политики доступа, специфичной для bestpartner, установить роль Super User.
Комментарии: 3
спасибо! Но что такое контекст в modx? понять не могу
можно представлять контекст как корневую папку в дереве страниц.
обычно на сайте одна такая папка и называется она (т.е. контекст) web
но контекстов может быть и несколько
такое решение можно использовать, например, для многоязычного сайта,
тогда у каждого языка будет свой контекст и своё дерево страниц
также в контексте можно задать или переопределить значения системных переменных —
это те, которые доступны посредством синтаксиса [[++my_context_setting]]
обычно на сайте одна такая папка и называется она (т.е. контекст) web
но контекстов может быть и несколько
такое решение можно использовать, например, для многоязычного сайта,
тогда у каждого языка будет свой контекст и своё дерево страниц
также в контексте можно задать или переопределить значения системных переменных —
это те, которые доступны посредством синтаксиса [[++my_context_setting]]
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.