Наверх

Модель безопасности в MODX

В разделе «Репосты» расположены чужие статьи, которые мне понравились или показались полезными.

Модель безопасности в MODX не самая очевидная. Хотя в MODX присутствуют примитивы, присущие, например, модели безопасности SQL, их предназначение в MODX несколько отличается. При настройке безопасности конечной целью является дать каждому пользователю соответвующий набор привилегий – разрешить ему совершать определенные действия в системе. Действия могут совершаться над различными объектами: страницами (resource), контекстами (context), чанками (chunk), переменными шаблонов (TV) и т.д. Сами действия могут быть очень разными, в простейшем случае это создание, просмотр, редактирование и удаление. Таким образом, задача настройки безопасности сводится к заданию отношений между пользователями, объектами и привилегиями.

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

Предположим, мы хотим дать пользователю partner доступ к странице «Проекты» на редактирование. В этом примере объектом является страница «Проекты», привилегией – редактирование, а пользователем – partner. Но для того, чтобы реализовать такую схему безопасности, потребуется создать группу пользователей. Дело в том, что в MODX права назначаются именно группе, а не пользователю. Группа – это множество пользователей, обладающих схожими правами. Разумеется, пользователь может состоять в нескольких группах.

Группы страниц

Дать доступ непосредственно к странице «Проекты» тоже не удастся, т.к. система безопасности MODX оперирует только с группами страниц (resource groups), а не с отдельными страницами. Если точнее, то управлять доступом можно на уровне следующих объектов:
  • контексты,
  • группы страниц,
  • категории элементов,
  • медиа источники (media source).

Политики доступа

Не будет большой неожиданностью, что и привилегии в MODX объединяются в группы. Группы привилегий называются политиками доступа (access policy). Например, политика доступа может состоять из таких привилегий:
  • создание страниц
  • чтение страниц
  • редактирование страниц
  • удаления страниц.
Чтобы дать доступ на редактирование, потребуется создать политику доступа с привилегией «редактирование страниц». Конечно, чтобы пользователь смог редактировать страницу, ему понадобится и привилегия «чтение страниц». Учитывая всё вышесказанное, алгоритм настройки доступа в MODX можно представить так:
  1. выделить объекты, доступ к которым необходимо предоставить;
  2. если доступом к данным объектам нельзя управлять напрямую (например, это страница или чанк), создать группу страниц или категорию элементов и добавить туда интересующий объект;
  3. создать пользователя;
  4. создать группу, которая будет носителем прав доступа к интересующим объектам, и добавить пользователя в эту группу;
  5. создать политику доступа с набором привилегий, которые необходимо предоставить;
  6. присвоить политику доступа группе пользователей.

Шаблоны политик доступа

В MODX порядка 200 разных привилегий. Некоторые привилегии логически связаны, например, привилегии регулирующие доступ к страницам или привилегии, регулирующие доступ к чанкам. Для того, чтобы ориентироваться в таком количестве привилегий было проще, в MODX существуют шаблоны политик доступа. Шаблон состоит из набора привилегий, с которыми часто приходится работать вместе, например, если нужно дать доступ на просмотр страницы, велика вероятность, что понадобятся и привилегии на редактирование и создание. При создании политики доступа в MODX требуется указать шаблон политики доступа. Шаблон отличается от политики доступа тем, что шаблон только группирует привилегии, чтобы с ними было удобно работать в панели администрирования. Шаблон не даёт никаких привилегий, он лишь ограничивает количество привилегий, которые можно назначить политике. Сделано это для удобства: чтобы приходилось искать нужные привилегии не в списке из сотен пунктов, а в списке из пары десятков. Теоретически можно создать шаблон со всеми возможными привилегиями и пользоваться им, но на практике это не очень удобно. Стоит отметить, что каждая привилегия применима к определённому виду объектов. Например, привилегия на просмотр страниц не может быть использована для предоставления доступа на просмотр контекста, для этого есть отдельная привилегия. Шаблон объединяет привилегии относящиеся к одному типу объектов и, как следствие, определяет, к каким объектам будет применима политика доступа.

Роли

До сих пор мы не касались понятия роли, однако, на практике при попытке настроить права доступа, вы обязательно столкнётесь с ролями. В простых конфигурациях безопасности можно игнорировать роли и везде указывать одну и ту же роль (например, «Super User»), но разобраться в принципе работе ролей всё же стоит. Роли позволяют ограничивать привилегии пользователя внутри группы. Образно говоря, роли позволяют создать внутри группы пользователей «уровни доверия». Каждая роль имеет ранг: чем меньше числовое значение ранга, тем больше доверия соответствует этой роли. По сути, роль и ранг – почти одно и то же, роль – это ранг, которому присвоено некоторое имя, например «Super User». Когда пользователь добавляется в группу, ему назначается определённая роль. Если ранг роли равен нулю, пользователю оказывается максимально возможное для этой группы доверие, он получает доступ ко всем привилегиям группы. У каждой политики доступа, назначенной группе пользователей, задаётся минимальная роль, которой должен обладать пользователь, чтобы получить привилегии из этой политики. Здесь есть небольшая путаница: под минимальной ролью имеется в виду, что роль пользователя должна иметь ранг не выше указанного, чтобы он имел доступ к привилегиям из данной политики. Предположим, есть два пользователя partner и bestpartner с почти идентичным набором привилегий, но bestpartner помимо всех привилегий partner, может ещё редактировать страницу «О компании». Можно просто скопировать настройки доступа partner и присвоить копию пользователю bestpartner, добавив туда недостающую привилегию:
  1. создать группу bestpartner-group;
  2. назначить новой группе те же самые политики доступа, что были у группы partner-group;
  3. создать новую политику с недостающими привилегиями и назначить её группе bestpartner-group.
Используя роли, можно решить эту задачу так:
  1. назначить partner роль Member в группе пользователей partner-group;
  2. назначить bestpartner роль Super User в группе пользователей partner-group;
  3. для политик доступа, которые нужно назначить обоим партнёрам, установить минимальную роль Member;
  4. для политики доступа, специфичной для bestpartner, установить роль Super User.
Как видно из примера, одну и ту же задачу можно решить как с применением механизма ролей, так и без него. При выборе того или иного способа, стоит руководствоваться простотой конечного решения.
Оригинал: https://modx.pro/security/3776-the-security-model-in-modx/

7 комментариев

  1. Александр Белкин 30 ноября 2015, 14:50 # 0
    Илья, о безопасности… какие права следует ставить на папки modx?

    У меня вот так:

    assets 755
    connectors 755
    core 755
    css 755
    images 755
    manager 755
    modx-2.3.3-pl 755
    upload 755

    На этот файл что рекомендуете? /home/user43092/auto/core/config/config.inc.php 644

    Не знал где спросить, поэтому… спросил тут. Спасибо!
    1. Илья Уткин 30 ноября 2015, 15:03 # 0
      Я на все папки ставлю 700, на файлы 644, а на конфиг можно 444, но тогда его из админки не получится отредактировать, если что.

      Если папка /core/ закрыта от внешнего доступа, то думаю, и на конфиг можно ставить 644.

      Но я в безопасности не очень подкован. Можно спросить еще и в комментариях к оригинальной статье: https://modx.pro/security/3776-the-security-model-in-modx/
      1. Александр Белкин 30 ноября 2015, 17:05 # 0
        Благодарствую душевно! И мой конфиг теперь 444!
    2. Александр Белкин 02 декабря 2015, 10:15 # 0
      Илья, ваш блог мне помог. Плюс я нашел у вас крутые штуки в «Дополнениях» такие как бесплатный чат. Пока я новичек и могу всего лишь подкинуть идеи.

      1. Мне бы хотелось иметь плагин который шлет смс-ки с заказами и сообщает о письмах на мыло… ч/з смс-ру например.

      2. Я видел предложение заработать партнерские за создание плагина в Единой Кассе…

      Всего вам добрейшего :)
      1. Илья Уткин 02 декабря 2015, 10:21 # +1
        Вам пора познакомиться с магазином дополнений ModStore.pro:
        modstore.pro/packages/alerts-mailing/mssms
        modstore.pro/packages/payment-system/msmerchant

        Ну, и добавляйте в закладки сайт сообщества: modx.pro, если вы его еще не видели.
      2. Александр Белкин 02 декабря 2015, 16:12 # 0
        Конечно, я весной задавал там не умные вопросы.

        Модуль Володи друг пробывал, он работает, скоро поставлю!
        Но модуля МодХ нет на сайте кассы! А инфо про партнерские есть… Свято место :)

        А у вас оплата на модуле msmerchant?
        1. Илья Уткин 02 декабря 2015, 17:35 # +1
          Нет, я не стал его ставить, написал по инструкциям из документации. Мне-то надо было, чтобы можно было любую сумма ввести.

        Авторизация

        через сервис Loginza:

        Подписка или RSS

        Буду присылать новые статьи — никакого спама



        Шаблоны MODX

        1 2 Дальше »

        Объектная
        модель
        MODX