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

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

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

Особо внимательные заметят, что в окне редактирования в названии группы скобок нет — «аноним». А также присутствуют вкладки «Пользователи» и «Настройки». Имейте ввиду, они чисто для «красоты». Ещё важно отметить, что у этих двух групп нельзя изменить название — поле задизейблено. Но у группы "(аноним)" название можно изменить в лексиконе, так как это перевод слова «anonymous». Можно заменить, например, на «Гости». Правда скобки убрать не получится.

Вернёмся к нашей задаче. Нам нужно создать группу пользователей. Нажимаем кнопку Новая группа пользователей и знакомимся с диалогом создания.

Кроме названия и описания группы нам в блоке «Мастер настройки доступа» предлагается сразу определить объекты-цели, доступ к которым необходимо настроить для данной группы. Формат мастера крайне неудобный — через запятую перечислять пользователей, группы ресурсов, категории элементов. Советую им не пользоваться, а все необходимые настройки делать в соответствующем интерфейсе. Кроме того, политики доступа в этом мастере ограничены только группой шаблонов «Admin». Поэтому доступны только 2 политики — «Administrator» и «Content Editor». Как вы понимаете, это политики для админки (контекст «mgr»). А мы настраиваем права доступа к сайту (контекст «web»). Кстати, изначально в мастере указан именно web контекст. Но я советую и его удалять. Иначе MODX создаст ACL для этого контекста с политикой «Content Editor», которая определяет 175 разрешений (привилегий). А нам для группы ресурсов нужно всего 2 — «Load» и «View».

Итак, от мастера настроек мы отказались. Осталось дать имя группе. Пусть она будет называться «Members». Сохраняем. Теперь приступим к её настройке. В списке групп кликаем на ней правой кнопкой мыши и выбираем «Редактировать группу пользователей». В открывшемся интерфейсе нас интересует вкладка «Права доступа». Как раз тут происходит управление доступом ко всем пяти объектам-целям. Для нашей задачи необходимо настроить доступ только к двум — контексту и группе ресурсов.

Доступ к контексту

Так как из коробки к контексту «web» уже настроен доступ для гостей, то при инициализации этого контекста MODX будет проверять права доступа всех пользователей. А так как залогиненный на сайте пользователь не принадлежит к группе "(аноним)", то доступ ему будет запрещён. В документации написано, что в этом случае пользователь получит ответ 404. Но мы из прошлой статьи уже знаем, что это не так и никакой проверки на самом деле нет. Поэтому, в принципе, доступ к контексту настраивать не нужно. Но мне для объяснения теории эта настройка нужна. Поэтому сделаем её.

На вкладке «Доступ к контекстам» нажимаем Добавить контекст и указываем контекст «web», минимальную роль «Member» и политику доступа «Load Only». Если с первым и последним пунктами всё понятно, то что такое минимальная роль большинство ответить не сможет. Об этой неочевидной логике я и говорил в начале статьи. Давайте разбираться.

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

Так вот, в MODX из коробки есть 2 роли — «Super User» с рангом 0 и «Member» с рангом 9999. Вы может создать ещё роли. Например, «Editor» с рангом 10 или «Sale manager» с рангом 100. А теперь представьте, что ранг — это высота планки. И чем ниже планка, тем меньше игроков сможет её преодолеть.

И тут важно знать ещё один момент. Права доступа мы определяем для группы пользователей. Но MODX-то проверяет именно пользователя. А значит его нужно добавить в группу. И когда вы попробуете это сделать, то увидите, что нужно указать не только пользователя, но ещё и роль. Таким образом, получается, что у группы пользователя указывается роль и у пользователя указывается роль. Вот тут мозги и заплетаются. Но всё просто. Роль у группы — это высота планки. А роль у пользователя — это высота, до которой он может прогнуться. Т.е. пользователь с рангом 0 — самый крутой и он может пройти под любой планкой — и 0, и 10, и 100, и 9999.

Таким образом, указывая группе пользователей минимальную роль с рангом 9999, вы как бы говорите, что все пользователи, добавленные в эту группу с рангом 9999 и ниже, будут иметь доступ. Как нетрудно догадаться, в данном случае доступ будут иметь все пользователи. А если вы укажите для группы роль с рангом 100, то всем пользователям группы, добавленных в неё с рангом выше 100 (например, 9999), в доступе к контексту будет отказано. Пройдут только те, у кого ранг 100 и ниже. Вот такая логика. Что это даёт?

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

Эту задачу можно решить двумя способами. Первый — для разных пользователей создать отдельные группы пользователей — «Users» и «Moderators» и для группы ресурсов с профилем добавить обе группы пользователей, а для группы ресурсов, к которым должны иметь доступ только модераторы, добавить только группу «Moderators». В этом случае на роли можно не заморачиваться. Достаточно указать везде 9999. В данном случае права доступа определяются через группы.

А вот для второго варианта роли важны, так как права проверяются уже на уровне пользователя. А группа может быть всего одна. Для примера возьмём группу «Users». Для неё создаём ACL для каждой группы ресурсов. Для той, что содержит страницу с профилем, указываем стандартную роль «Member» с рангом 9999. А для группы ресурсов, предназначенных для модераторов, указываем роль «Super User» с рангом 0. И на следующем шаге добавляем в эту группу всех пользователей, но для простых указываем роль «Member» (9999), а для модераторов — роль «Super User». Таким образом, одна и также группа пользователей имеет доступ к разным группам ресурсов, но с разным уровнем доступа. И этот уровень определяет, какие пользователи пройдут, а какие нет. И в качестве критерия используется роль (ранг) пользователя — пользователи с рангом 9999 не смогут зайти на страницу, для доступа к которой указан ранг 0, а для пользователей с рангом 0 доступ на страницы с рангом 9999 открыт.

Лично для меня первый вариант выглядит значительно проще и интуитивнее. Так работают права в операционных системах. Зачем придумали ещё и второй вариант непонятно.

Доступ к группе ресурсов

Итак, вернётся к нашей задаче. Чтобы дать доступ пользователям к группе ресурсов, нужно сначала её создать. Выбираем меню «Содержимое / Группы ресурсов» и нажимаем кнопку Создать группу ресурсов. Вводим имя группы — «Private» и очищаем все поля мастера настроек. Сохраняем. Теперь в эту группу нужно добавить страницы, к которым мы хотим ограничить доступ. Например, страница профиля пользователя, которая была создана заранее.

Дальше возвращаемся в интерфейс групп пользователей и редактируем нашу группу. Переходим на вкладку «Доступ к группам ресурсов» и нажимаем кнопку Добавить группу ресурсов. В диалоге выбираем только что созданную группу, указываем контекст «web», минимальную роль «Members» и политику доступа «Load, List and View». Эта максимально подходящая для нашей задачи политика. В принципе, можно создать свою с правами «Load» и «View». Это на ваш выбор.

Заключение

Всё, настройка закончена. Теперь только указанные в группе «Members» пользователи будут иметь доступ к страницам, входящим в группу ресурсов «Private».

Вообще, пользователь не ограничен одной группой. Его можно добавить в множество групп с разными ролями. И в этом случае роли также имеют значение. Они определяют приоритет. Для такого пользователя MODX формирует права в порядке убывания ранга. Т.е. пользователю сначала применяются права для ранга с наибольшим числом. Затем на них накладываются права с рангом ниже (т.е. важнее) и т.д. И в конце применяются права с рангом 0. И опять тут есть скрытая логика, неописанная в документации. Как только вы добавляете пользователя в группу с рангом 0, эта группа считается для пользователя главной. Её id записывается в поле primary_group таблицы «users». И именно права этой группы применяются в самом конце. В интерфейсе вы нигде не сможете посмотреть эту информацию. Для этого придётся лезть в БД.

После того, как права для пользователя сформированы, они записываются в сессию и при каждом запросе зачитываются из неё. И пока пользователь залогинен, никакие изменения прав доступа в записях ACL на них не повлияют. Только при перелогинивании MODX заново сформирует права пользователя и опять запишет в сессию.

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

P.S.

Статья получилась просто огромная. Но в дальнейшем мы наглядно разберём каждый случай в видео. Так что следите за новостями.