MODX Revolution установка прав контент-менеджера
Сначала мне было довольно трудно понять систему назначения прав в Revo. На взгляд начинающего она трудна и не логична. Однако на самом же деле она исключительно комфортна. И в случае если располагать на руках хорошей инструкцией по настройке прав, то все будет прозрачным. Полагаю, организация учетной записи контент-менеджера, считается наиболее первоочередной и важной задачей. Вследствие этого обрисую процесс формирования такой, а равным образом все ошибки, с коими мне довелось соприкоснуться во время настройке.
Далее в статье имеется ссылка на источник, коим я воспользовался при настройке прав, кроме официальной документации ModxRevo. Рекомендую изучить это до чтения моей статьи, т.к. она считается скорее предписанием, и нужно осознать главную суть системы пред её применением.
Начинаем! Входим в меню «Безопасность—Контроль доступа»:
Далее вкладка «Политика доступа»:
Создаем новую политику для менеджера:
Имя политики: Manager, шаблон: AdministratorTemplate.
Сохраняем созданную политику. Она обязана появиться в списке политик ниже:
На страничке редактирования выводится перечень всех параметров. Для избранного шаблона AdministratorTemplate у нас отмечены все параметры. Нам нужно убрать излишние параметры, ограничив менеджера в правах.
В этом случае я пошел по обычному пути, убрав из админки все пункты меню и подменю, по коим менеджеру ходить нет необходимости. При данном сам доступ к редактированию системных опций я прикрывать не стал. Сомнительно, что менеджер станет подбирать ссылки на скрытые странички системных опций, чтобы что-то там изменить. Основное, чтобы случаем не нажал туда, куда ему жать не нужно, а от данного мы его избавим. Однако вы можете в свою очередь отключить доступ к тому, что считаете нужным.
Убираем доступ к страничкам и действиям, сопряженным с правами доступа, убрав галочку рядом с параметром access_permissions:
Точно так же проделываем с другими параметрами:
dashboards Возможность просмотра и управления панелями.
element_tree Просмотр дерева элементов в левой панели.
menu_reports Показ в верхнем меню пункт «Отчёты».
menu_security Показ в верхнем меню пункт «Безопасность».
menu_system Показ в верхнем меню пункт «Система».
menu_tools Показ в верхнем меню пункт «Инструменты».
new_static_resource Создание новых статичных ресурсов.
remove_locks Удаление всех блокировок на сайте.Дальше не забываем сохранить изменения.
Сейчас переходим на вкладку «Роли»:
Создаем новую роль для менеджера:
Ранг задается любой от 0 до 9999 не включая. Так как 0 применяется для роли администратора, а 9999 для роли типичного посетителя. Имя роли задаем: Manager. Хочется заметить, что дальше буду для всех объектов задавать имя Manager, для собственного комфорта, однако имя может быть любым. Сберегаем изменения и переходим на вкладку «Группы пользователей»:
Создаем новую группу для менеджера:
Имя группы: Manager.
Сохраняем группу, потом отыскиваем её в списке и выбираем для редактирования:
На вкладке где представлена общая информации видно, что эта группа располагает в качестве родительской группу администратора, так как мы организовали её внутри этой группы. Однако это применяется скорее для комфорта восприятия, вследствие этого, в случае если вынести её из родителя, ничего не изменится.
Переходим на вкладку «Доступ к контекстам»:
Прибавим свежий контекст:
Сохраняем созданный контекст. И прибавим ещё один:
Далее нужно сохранить контекст и все изменения на страничке группы ресурсов.
Далее переходим в меню «Безопасность—Управление пользователями»:
Создаём новго пользователя, задаем ему имя Manager. Это имя будет применяться для входа в админку. Выделяем пользователя как активного. В свою очередь внизу на вкладке где представлена общая информация можно задать средство организации пароля к учетной записи.
Пред тем как сохранять учетную запись заходим на вкладку «Права доступа» и добавляем нашего пользователя в прежде организованную группу менеджера: Manager, определив ему роль менеджера: Manager:
Судя по всему все. Можно выйти из под учетной записи админа и зайти в админ. панель как менеджер. Однако имеется еще момент!
Вначале в перечне источников лишь главный источник: Filesystem. Сначала нужно ограничит доступ к нему. Открываем страничку редактирования источника Filesystem. Дальше на вкладке «Права доступа» прибавим группу пользователей, которой желаем дать доступ:
Незамедлительно после сохранения абсолютно у всех пользователей, не имеющих отношение к указанной группе и роли, исчезнет доступ в источнику файлов Filesystem. Одновременно, данные пользователи не увидят этого источника в перечне на страничке инструментов!
Сохраним сделанный источник. Сейчас отыщем его в перечне и отредактируем его параметры.
На вкладке общих данных внизу имеется перечень параметров. Нас интересуют в данный момент первые 4. Другие параметры назначены по умолчанию исключительно хорошо, в частности для применения источника как хранилища изображений.
Первоначальная часть прописывается в «Опциях системы» ModxRevo. Однако её касаться не нужно, традиционно по умолчанию она стоит верная. Здесь вам необходимо сменить tpl_name на заголовок вашего шаблона для веб-сайта и сделать папку pictures.
В итоге, параметры baseUrlи basePath устанавливаются в значение:
manager/template/tpl_name/pictures/
Параметры basePathRelative и baseUrlRelativeв значение: «Да».
Пред установкой прав доступа для менеджера к источнику, нужно обратить внимание на том, что в последствии задания прав, источник не будет доступным для учетной записи админа, в том числе и для редактирования.
Однако самое основное не это, а то, что в случае если на какой-нибудь страничке применяется tv параметр с типом ввода «Изображение», тоесть tv, который конкретно обращается к какому-то источнику файлов, то для него нужно задать источник файлов PictureManager прежде, чем устанавливать права менеджера на него, иначе затем мы данное сделать не сможем.
Заходим в свойства необходимого нам tv параметра на вкладку «Источники файлов» и определяем для контекста web наш источник файлов, 2 раза кликнув на «Кэшированный код ресурса», сохраняем изменения.
И лишь после сего можно задать права доступа для источника файлов PictureManager:
Задаем группу пользователей: Manager, наименьшую роль: Manager-девять и политику: MediaSourceAdmin. Немедленно после сохранения источник файлов пропадет для администратора (метод возврата оговаривался ранее), а tv параметры с определенным источником файлов PictureManager перестанут быть редактируемыми из под учетной записи админа. При этом проявляется при попытке админом сохранить страничку, которая применяет данный tv, в силу чего значение tv сбрасывается и картинка исчезает со странички.
Из тех промахов, что я поймал под час пользования.
Во время использовании сниппета Articles, под час вывода списка статей с изображениями, в случае если изображения предназначались как tv параметры из под учетной записи менеджера (с применением его источника файлов), то эти изображения прекращали выводиться, при этом лишь в списке статей и лишь для сниппета Articles(тоесть getResources в чистом виде отрабатывает отлично). Сущность задачи в том, что ошибочно создается путь к изображению. А поточнее, он не создается абсолютно. Выводиться лишь его имя. Делему решил прибавлением костыля в виде сниппета image_path:
Будем надеяться у вас все будет функционировать и без этого. 
Политики
Что такое политика доступа?¶
Если вы настраиваете любую из вышеуказанных политик доступа по умолчанию, продублируйте и переименуйте их перед настройкой! Если вы этого не сделаете, при обновлении версии MODX все настройки будут утеряны, поскольку они будут переопределены сценарием установки.
Создание и редактирование¶
Чтобы создать Политику доступа в менеджере, перейдите к
В этом разделе вы можете добавить новые политики. Чтобы изменить Политику доступа в менеджере, просто щелкните правой кнопкой мыши Политику, которую вы хотите изменить.
Использование¶
Политики могут использоваться различными способами. Вот 3 примера использования по умолчанию в MODX:
Доступ к контекстам¶
Политики доступа могут быть назначены с помощью Списков контроля доступа (ACLs), для контекста или группы пользователей с указанием минимальной Роли. Это означает, что все пользователи в этой группе обладающие минимальной ролью, могут использовать разрешения в политике контекста, указанные в ACL.
По умолчанию в MODX присутствует политика доступа «Administrator» которая содержит все Разрешения которые можно использовать в контексте ACL. При создании пользовательской политики доступа, для пользователей с ограничениями, эту политику лучше всего продублировать.
Доступ к группе ресурсов¶
Доступ к ресурсам так же может быть разграничен с использованием ролей и групп ресурсов. По умолчанию MODX имеет Ресурсную политику, содержащую все основные разрешения, которые можно использовать в ACL групп ресурсов.
Примером может быть назначение политики «Resource» группе ресурсов под названием «Documents HR». Затем вы предоставили бы группе пользователей под названием «Отдел кадров» доступ к этой группе ресурсов через ACL ресурса:
Такая настройка разрешит доступ к ресурсам из группы «Documents HR» только пользователям из группы «Отдел кадров».
Доступ к элементам категории¶
Просмотр элементов также может быть ограничен с использованием ACL. Например, если у вас есть группа пользователей ‘Developers’, и вы хотите, чтобы пользователи в этой группе были единственной группой, которая может видеть элементы в категории ‘Gallery’, вы должны создать ACL в разделе «Доступ к категории элементов» (вкладка при редактировании группы пользователей):
Это позволит только пользователям, состоящим в группе «Developers» просматривать элементы в категории «Gallery».
Примеры¶
Пример пользовательской политики:
Права доступа в MODX
Если у вас не просто сайт-визитка, то вы обязательно столкнетесь с задачей разграничения доступа. Как правило, первое, с чем сталкиваются, это приватные страницы типа профиля пользователя. Это что касается сайта. Есть ещё задача управления этим сайтом. И тут кроме админа есть ещё контент-менеджеры, менеджеры по продажам и т.п. И все они работают через админку. Такая концепция MODX. Лично я уже давно считаю, что админка только для админа, а все интерфейсы дополнений необходимо выносить из админки. В этом есть определённые плюсы:
Тут конечно, есть и минус данного подхода — разные точки входа. В админке все дополнения находятся в одном месте. Установил пакет и знаешь где его найти. Это удобно. А в данном случае предётся вручную их собирать где-то. Но так работают сайты на фреймворках. И их разработчики вам скажут, что это скорее плюс — даёт больше гибкости.
Управление доступом
Составляющие ACL
Принципал
В MODX принципалом выступает не сам пользователь, а группа пользователя. И чтобы права сработали, пользователя нужно добавить в эту группу. Причём, пользователь может входить в несколько групп. В MODX из коробки есть 2 группы пользователя — «(аноним)» и «Administrator». Если со второй всё понятно, то первая группа виртуальная. Она предназначена только для определения прав доступа для гостей.
В MODX доступ ограничивают для пяти объектов
Обратите внимание, все объекты единичные, а для ресурсов используется целая группа. Да, в MODX права задаются именно группе ресурсов, а не единичному ресурсу. Т.е. по аналогии с файловой системой на папки, а не на файлы. Ровно такой же принцип используется для настройки прав доступа к элементам MODX. Права определяются не к отдельному чанку или сниппету, а для категории элементов, которая как раз группирует элементы.
Политики доступа
Полномочия
Ну и следующий важный элемент системы безопасности — полномочия. Это минимальный уровень, который разрешает пользоваться указанными политиками. В MODX это синоним роли. И тут есть определенная особенность, ломающая мозг. Чем ниже число, тем выше уровень полномочий. Просто запомните этот факт. Он неинтуитивен.
В MODX из коробки есть 2 роли: 0 с псевдонимом «Super User» и 9999 с псевдонимом «Member». Так вот, 0 — это максимальные полномочия. 9999 — минимальные. Создавать роли можно в этих пределах.
Ещё запомните, когда говорят про число, то используют определение «ранг». Когда про псевдоним, то «роль». Таким образом, роль «Super User» имеет ранг 0, а роль «Member» — ранг 9999. Просто в разных местах используют оба понятия, но значат они одно и тоже.
Списки контроля доступа ACL
Теперь сформулируем понятие ACL. Это набор прав, указанных в политике доступа, прикреплённых к определённому объекту (контексту, группе ресурсов, категории) для определённой группы пользователей с указанной ролью. Как видите, списки контроля включают все вышеописанные понятия.
Таким образом, чтобы ограничить доступ пользователя к определённому ресурсу, нужно создать группу ресурсов, добавить в неё нужный ресурс, создать группу пользователей, добавить в неё пользователя и этой группе указать политику доступа к группе ресурсов с нужным уровнем полномочий. Это и называется ACL.
Важно!
Необходимо знать одну особенность MODX. Он кэширует все права пользователя в сессию. Поэтому, когда вы добавляете пользователя в группу, исключаете его из группы, меняете права самой группы, то должны помнить, что после этого необходимо разлогинить всех пользователей, чтобы эти изменения применились.
Ну или второй вариант, удалить ACL для гостей. Тогда проверок не будет и пользователь получит доступ к странице. Именно такая логика задумана, что и подтверждается документацией. Но по факту это не так. Ибо есть баг, из-за которого проверка доступа к контексту не работает.
Системные настройки
Почему их всего 3, а не 5? Не спрашивайте.
Кэширование
В MODX очень многие вещи кэшируются. И права не исключение. Как я сказал выше, ACL для групп пользователя кэшируются в сессии пользователя. И сбросить этот кэш можно только заставив пользователя перелогиниться. ACL для групп ресурсов (modAccessResourceGroup) хранятся в кэше ресурса в ключике «policyCache». Права доступа к контекстам (modAccessContext) хранятся в кэше контекстов в ключике «policies». Оба кэша можно сбросить через меню «Очистить кэш».
Кэши остальных объектов я не нашёл. Вполне возможно, что их решили не кэшировать по причине того, что они используются только в админке, а значит нет проблем трёх секунд.
Заключение
Статья получилась большая и без картинок. В следующий раз мы поговорим о правах доступа в формате видео. Для наглядности я планирую снять целую серию с подробным разбором каждого случая.
Настройка прав доступа
В данном уроке мы по шагам настроим права доступа в MODX для контент менеджера сайта.
Шаг 1. Создание политики доступа для контент менеджеров.
Для того чтобы создать пользователя перейдите в «Настройки» (шестеренка в правом верхнем углу) > «Контроль доступа» и на открывшейся странице переходим во вкладку «Политики доступа«.
Далее копируем «Content Editor» (щелкаем пкм (правой кнопкой мыши) и выбираем копировать), редактируем (пкм — редактировать) новую политику и называем ее «Менеджер«, пролистываем страницу пониже и устанавливаем галочки на против следующих разрешений:
После этого сохраняете новую политику доступа.
Шаг 2 — Создание группы пользователей для контент менеджеров и устанавливаем для нее права
Теперь отредактируем данную группу. Для этого нажимаем пкм на «Контент менеджеры» выбираем «Редактировать«. После этого переходим на вкладку: «Права доступа» и на вкладке «Доступ к контекстам» редактируем по очереди mgr и за тем точно так же web
mgr, web > редактировать, устанавливаем «Политика доступа» как «Менеджер» + Сохранить
Шаг 3 — Создане нового пользователя и назначение ему прав
В открывшейся странице на вкладке «Общая информация» указываем имя — manager, указываем E-mail менеджера, ставим галки на против — «Активный » и «Я укажу пароль сам» и задаем пароль.
Переходим на вкладку «Права доступа» > «Добавить пользователя в группу» >»Контент Менеджеры«, Роль: «Super User» > Сохранить
Ну и потом еще раз «Сохранить» (сверху), чтобы сохранить пользователя.
После этого переходим в меню «Управление» > «Перезагрузить права доступа»
Шаг 4 — Добавление нового источника файлов
Переходим в «Медиа» > «Источники файлов» и копируем источник «Filesystem»
Отредактируем скопированный источник
Название: «images»; basePath и baseUrl: «assets/images/» и сохраняем его.
Переходим в меню: «Настройки» > «Контроль доступа» далее жмем правой кнопкой мыши по группе «Контент менеджеры» и выбираем редактировать. Переходим на вкладку: «Права доступа» > «Доступ к источнику файлов» и добавляем новый источник файлов: Источник: images, Минимальная роль: Member — 9999, Политика доступа: Media Source Admin и Сохранить;
Меню: «Управление» > «Очистить кэш»; Меню: «Управление» > «Перезагрузить права доступа»
Шаг 5 — Удаляем источник «Filesystem» для manager
Возращаемся в «Медиа» > «Источники файлов»
Filesystem > Редактировать. Далее переходим на вкладку: «Права доступа», нажимаем «Добавить группу пользователей», выбираем группу пользователей: «Administrator», Минимальная роль: «Super User — 0», Политика: «Media Source Admin» + Сохранить
И потом еще раз сохранить сверху в правом углу.
Теперь точно также изменим права доступа к источнику файлов «images».
Шаг 6 — Управление группами ресурсов
Переходим в меню: «Содержимое» > «Группы ресурсов»
Создать группу ресурсов
Имя: «Администратор», Контексты: «web,mgr»
Установить галку «Автоматически дать доступ группе Administrator» и сохранить.
Не скрывайте sitemap и robots во избежание проблем с поисковиками (ну по крайней мере у меня яша и гоша ругались что нет доступа к этим файлам, после их скрытия от менеджеров. Может глюк или баг. В любом случае я вас предупредил, а там решайте сами скрывать их или нет).
Ну и завершающий штрих: Меню: «Управление» > «Очистить кэш»; Меню: «Управление» > «Перезагрузить права доступа». Все ?
Да еще бывают глюки у менеджеров с tv полями картинок, так что лучше используйте не стандартное tv изображение, а дополнение mixedImage (можно установить из репозитория modstore).
Понравилась статья? Можно поблагодарить автора: отправив ему донат на
Статья, в которой рассмотрим, как в MODX Revolution организована система прав доступа, а также некоторые типовые инструкции по настройки разрешений для пользователей.
Система прав доступа в MODX
MODX Revolution не позволяет напрямую назначать права пользователю. В этой системе данное действие осуществляется через группы пользователей.
Другими словами, для того чтобы пользователю предоставить некоторые права, необходимо:
Но нахождения пользователя в группе не означает то, что он получит все её привилегии. Права, которые получит пользователь, будут определяться с помощью отведённой ему в этой группе роли. Роль (ранг) пользователя в группе определяется с помощью числа от 0 до 9999. Это значение определяет, какие пользователь получит привилегии группы, а какие нет.
Другими словами роль – это некий механизм, который позволяет в пределах одной группы разным пользователям назначить разные права.
Разберём небольшой пример.
Политика доступа в MODX
Установление привилегий группе в MODX Revolution осуществляется с помощью политики доступа. Она (политика доступа) назначаются группе применительно к определённым сущностям MODX, а именно к контексту, группе ресурсов, категории элементов, источнику файлов и пространству имён. Кроме этого указывается ещё минимальная роль, которая нужна пользователю этой группы, чтобы иметь эти привилегии.
Политика доступа – это набор прав, предоставляемый пользователю для совершения действий на сайте, работающем под управлением CMS MODX Revolution.
Почему это реализовано именно так? Это связано с тем, что прав в MODX очень много и их более удобно назначать группами (другими словами с помощью политики доступа), а не по одному.
Например, политика доступа Load, List and View имеет следующий набор разрешений:
Как создать свою политику доступа
При установке разрешений группе пользователей вы не ограничены только существующими (предустановленными) в системе MODX политиками. При необходимости вы можете создать новые. Создание политики в MODX осуществляется на основании шаблона политики доступа. Шаблон политики доступа – это сущность MODX Revolution, которая определяет максимальный список разрешений, доступный при создании политики доступа.
Таким образом, для того чтобы создать политику доступа с нужными разрешениями необходимо:
При создании политики доступа, всегда начинайте с назначения минимального количества прав, достаточных пользователю для совершения определённых действий в системе. При необходимости вы всегда сможете расширить предоставляемые пользователю разрешения.
Анонимный пользователь
В MODX Revolution любой не авторизированный посетитель сайта является анонимным и принадлежит к группе (аноним). В этом легко убедится, если создать следующий сниппет, поместить его вызов в шаблон ресурса, а затем открыть страницу.
Php код сниппета GetUser:
Вызов сниппета на странице:
Действия анонимных пользователей на сайте в MODX регулируются посредством настройки разрешений группы (аноним). При необходимости вы можете этой группе дать дополнительные привилегии или ограничить их.
Типовые инструкции по настройке разрешений
В этом разделе рассмотрим инструкции, которые можно использовать, когда вам необходимо:
Ограничение доступа к определённым ресурсам
Рассмотрим пример, в котором ограничим доступ анонимным пользователям к определённым ресурсам (например, к личному кабинету, к странице «Изменения пароля» и т.п.). Доступ к этим ресурсам предоставим только зарегистрированным пользователям.
Чтобы это осуществить необходимо:
После этого, любой анонимный или другой пользователь (у которого нет прав) получит 404 ресурс (т.к. у него нет даже права load), если он попытается открыть какую-ту страницу из этой группы.
Если же вы хотите анонимных пользователей, при открытии защищённых страниц, пересылать на какую-то другую (например, авторизации), то необходимо выполнить дополнительно ещё следующее (а именно дать право load для этой группы ресурсов):
Настройка прав для контент менеджера
В этом примере создадим группу «Managers», пользователи которой смогут в админке загружать изображения в директорию и работать с определёнными ресурсами.
Чтобы это осуществить можно, например, воспользоваться следующей инструкцией:
1. Создать новую политику доступа Manager с необходимыми правами:
2. Скрыть ресурсы, к которым менеджеры не должны иметь доступ в админке:
3. Предоставить доступ к директории, в которую пользователь будет загружать картинки.
Источник файлов, не имеющий связанной с ним группы пользователей, будет доступен всем пользователем бэкэнда. Поэтому чтобы для пользователей группы Managers не показывались другие источники файлов, которые не связаны не с одной группы, их, например, можно назначить группе пользователей Administrator.
4. Создать новую группу пользователей и назначить ей необходимые права.
5. Создать пользователя и добавить его в группу «Manager». В качестве значения роли установить ему число 9999 (Member). Данной роли ему будет достаточно, чтобы получить все разрешения данной группы. Это связано с тем, что для этой группы мы не назначали политики доступа для которых потребовалось бы роль больше чем 9999.