Права доступа в MODX

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

• Не нужно использовать устаревшую библиотеку ExtJS. Она пугает многих новичков и раздражает опытных модыксеров. Да, MODX позволяет дополнению работать без этой библиотеки. Но таких юзкейсов единицы, информации по ним крайне мало. Так что начинающий разработчик дополнений не осилит данный подход.
• Перегруженный интерфейс. Даже если отказаться от ExtJs, всё равно пользователь получит жутко перегруженный интерфейс ненужными UI объектами и огромным количеством загружаемых файлов. Плюс всё равно придется использовать API админки сайта и следовать его требованиям.
• Дополнительный уровень безопасности. Например, на сайте с установленным минишопом менеджер, ограниченный минимальными правами, может легко получить полный доступ. Конечно, пользователь с определёнными знаниями. А если вы используете свою концепцию, то можете случайно открыть дырку и скомпрометировать админку. Ведь даже опытные разработчики на этом попадались. Что уж говорить про тех, у кого есть только базовые знания web-безопасности. А если менеджер сидит на фронте, то эта проблема вас беспокоить не будет. По крайней мере, не сильно.

Тут конечно, есть и минус данного подхода — разные точки входа. В админке все дополнения находятся в одном месте. Установил пакет и знаешь где его найти. Это удобно. А в данном случае предётся вручную их собирать где-то. Но так работают сайты на фреймворках. И их разработчики вам скажут, что это скорее плюс — даёт больше гибкости.

Управление доступом

Модель безопасности в MODX строится на концепции ABAC и использует такое понятие как список контроля доступа (ACL). Сейчас мы разберёмся, что это такое и как оно работает. Для этого обратимся к документации MODX.

Принципал

В MODX принципалом выступает не сам пользователь, а группа пользователя. И чтобы права сработали, пользователя нужно добавить в эту группу. Причём, пользователь может входить в несколько групп. В MODX из коробки есть 2 группы пользователя — «(аноним)» и «Administrator». Если со второй всё понятно, то первая группа виртуальная. Она предназначена только для определения прав доступа для гостей.

Цели

В MODX доступ ограничивают для пяти объектов

• контекст,
• группа ресурсов,
• категория элементов,
• медиаисточник,
• пространство имен (namespace)

Обратите внимание, все объекты единичные, а для ресурсов используется целая группа. Да, в MODX права задаются именно группе ресурсов, а не единичному ресурсу. Т.е. по аналогии с файловой системой на папки, а не на файлы. Ровно такой же принцип используется для настройки прав доступа к элементам MODX. Права определяются не к отдельному чанку или сниппету, а для категории элементов, которая как раз группирует элементы.

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

Полномочия

Ну и следующий важный элемент системы безопасности — полномочия. Это минимальный уровень, который разрешает пользоваться указанными политиками. В MODX это синоним роли. И тут есть определенная особенность, ломающая мозг. Чем ниже число, тем выше уровень полномочий. Просто запомните этот факт. Он неинтуитивен.

В MODX из коробки есть 2 роли: 0 с псевдонимом «Super User» и 9999 с псевдонимом «Member». Так вот, 0 — это максимальные полномочия. 9999 — минимальные. Создавать роли можно в этих пределах.

Ещё запомните, когда говорят про число, то используют определение «ранг». Когда про псевдоним, то «роль». Таким образом, роль «Super User» имеет ранг 0, а роль «Member» — ранг 9999. Просто в разных местах используют оба понятия, но значат они одно и тоже.

Списки контроля доступа ACL

Теперь сформулируем понятие ACL. Это набор прав, указанных в политике доступа, прикреплённых к определённому объекту (контексту, группе ресурсов, категории) для определённой группы пользователей с указанной ролью. Как видите, списки контроля включают все вышеописанные понятия.

Таким образом, чтобы ограничить доступ пользователя к определённому ресурсу, нужно создать группу ресурсов, добавить в неё нужный ресурс, создать группу пользователей, добавить в неё пользователя и этой группе указать политику доступа к группе ресурсов с нужным уровнем полномочий. Это и называется ACL.

Ещё важно отметить, что в MODX приоритет доступа allow/deny. Т.е. если для объекта не указан ACL, то доступ разрешён. Или вернее, права для него не проверяются. Например, из коробки в MODX для гостей контекста web задана политика доступа «Load Only» с ролью «Member». Соответственно, если вы создадите пользователя и залогините его на сайте, то должны получить ошибку 404. Причина — раз для контекста уже настроен контроль доступа, и текущий пользователь не прошёл проверку (ведь доступ разрешен только для гостей), то соответственно пользователю в доступе отказано. Поэтому вам придётся создать ещё один ACL для группы пользователя, предварительно её создав и добавив туда этого пользователя. Группе нужно дать доступ к контексту web и указать политику доступа «Load Only». Так как на сайте проверяется только эта политика для контекста.

Ну или второй вариант, удалить ACL для гостей. Тогда проверок не будет и пользователь получит доступ к странице. Именно такая логика задумана, что и подтверждается документацией. Но по факту это не так. Ибо есть баг, из-за которого проверка доступа к контексту не работает.

Системные настройки

Моделью безопасности можно управлять через настройки. Для этого есть специальный раздел «Авторизация и безопасность». И самое первое, на что мы обратим внимание — настройка principal_targets. В ней указаны объекты, для которых нужно проверять права. По-умолчанию, там перечислены все 5 — «modAccessContext,modAccessResourceGroup,modAccessCategory,sources.modAccessMediaSource,modAccessNamespace». Но это ещё не всё. Есть ещё 3 настройки, которые управляют доступом к отдельным объектам:

• access_category_enabled — Проверять доступ к категориям,
• access_context_enabled — Проверять доступ к контекстам,
• access_resource_group_enabled — Проверять доступ к группам ресурсов.

Почему их всего 3, а не 5? Не спрашивайте.

Кэширование

В MODX очень многие вещи кэшируются. И права не исключение. Как я сказал выше, ACL для групп пользователя кэшируются в сессии пользователя. И сбросить этот кэш можно только заставив пользователя перелогиниться. ACL для групп ресурсов (modAccessResourceGroup) хранятся в кэше ресурса в ключике «policyCache». Права доступа к контекстам (modAccessContext) хранятся в кэше контекстов в ключике «policies». Оба кэша можно сбросить через меню «Очистить кэш».

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

Заключение

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