Modx права доступа: MODX — Настройка прав доступа

Настройка прав доступа в MODX Revo

Автор Алексей На чтение 4 мин Просмотров 2.7к. Опубликовано 22.02.2017 Обновлено 23.10.2018

В данном уроке мы по шагам настроим права доступа в MODX для контент менеджера сайта.

Шаг 1. Создание политики доступа для контент менеджеров.

Для того чтобы создать пользователя перейдите в «Настройки» (шестеренка в правом верхнем углу) > «Контроль доступа» и на открывшейся странице переходим во  вкладку «Политики доступа«.

Далее копируем «Content Editor» (щелкаем пкм (правой кнопкой мыши) и выбираем копировать), редактируем (пкм — редактировать) новую политику и называем ее «Менеджер«, пролистываем страницу пониже и устанавливаем галочки на против следующих разрешений:

• directory_chmod — Изменять права доступа (chmod) к каталогам
• directory_create — Создавать каталоги в файловой системе
• directory_list — Получать список подкаталогов для каталога в файловой системе
• directory_update — Переименовывать каталоги в файловой системе
• file_create — Создавать файлы
• file_list — Смотреть список файлов в определенном каталоге
• file_manager — Использовать диспетчер файлов
• file_remove — Удалять файлы
• file_tree — Видеть дерево файлов в левой навигационной панели
• file_update — Изменять файлы
• file_upload — Загружать файлы в папку
• file_view — Просматривать содержимое файла
• packages — Использовать пакеты в системе управления пакетами
• search — Использовать страницу «Поиск»

После этого сохраняете новую политику доступа.

Шаг 2 — Создание группы пользователей для контент менеджеров и устанавливаем для нее права

Теперь снова идем в «Настройки» > «Контроль доступа«, переходим во  вкладку: «Группы пользователей & Пользователи» и создаем новую группу пользователей с именем «Контент менеджеры«. Устанавливаем в окне новой группы пользователей контексты — web, mgr; политика бэкэнда — Менеджер и сохраняем.

Теперь отредактируем данную группу. Для этого  нажимаем пкм на «Контент менеджеры» выбираем «Редактировать«. После этого переходим на вкладку: «Права доступа» и на вкладке «Доступ к контекстам» редактируем по очереди 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).

Понравилась статья? Можно поблагодарить автора: отправив ему донат на

YooMoney

или

Qiwi

. Либо поделившись статьей ☟

Разрешения — Политики | MODX документация

Что такое Разрешения?¶

«Разрешения» в Revolution — это единый контроль доступа, который разрешает или запрещает выполнение какой-либо задачи. Вы можете представить разрешения как чекбокс: может ли пользователь выполнить действие или нет? Пример такого разрешения — «content_types» — если пользовательская политика не содержит это разрешение, тогда пользователь не сможет выполнить данное действие. В этом случае, пользователь не может просмотреть Тип Контента страницы.

Обычно вам не придется настраивать разрешения индивидуально, а в группах под названием Политики Доступа. Политика Доступа — это список индивидуальных доступов (так же называют Список Контроля Доступа или СКД). Например, если вы хотите назначить пользователям необходимые разрешения для редактирования содержимого в панели управления, вы можете назначить им политику «Content Editor». Разрешения MODX всегда аддитивны: если в разрешении назначена «Политика Доступа А» и не назначена «Политика Доступа Б» и вы хотите добавить обе политики пользователю, еффективнее всего будет коллекция всех разрешений, определенных в обеих Политиках. Добавление большего количества политик никогда не удалит разрешения для пользователя. Например, если вы добавите ограничетельную политику «Load Only» к администратору, то администратор все еще будет иметь доступ ко всем действиям назначеных в политике «Администратор».

Применение¶

На практике, Политики Доступа связанные с Группами Пользователей (не с индивидуальными пользователями). Политики Доступа связанные с Групой пользователей и пользователи могут быть добавлены в группу.

Политики Доступа (ПД) определяют списки разрешений (смотрите «Меню» —> «Контроль доступа»). Эти списки содержат группы разрешений, которые относятся друг к другу.

1. Права Доступа — Политика Администратора
2. Права Доступа — Политика Ресурса

Смотрите также¶

1. Пользователи
2. Группы пользователей
3. Группы Ресурсов
4. Роли
5. Политики
   1. Права Доступа
      1. Права Доступа — Политика Администратора
      2. Права Доступа — Политика Ресурса
   2. КД
   3. Шаблоны Политик
6. Уроки безопасности
   1. Предоставление доступа «User Manager»
   2. Создание «Member-Only» страниц
   3. Создание второго «Super Admin» пользователя
   4. Ограничение Элементов от пользователей
   5. Подробнее о группе анонимных пользователей
7. Закалка MODX Revolution
8. Стандарты безопасности
9. Поиск проблем в безопасности
   1. Сбрость пароля пользователя в ручную

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

Создание профиля контент-менеджера в ModX Revolution | by Vladimir

Переходим в: “Настройки” — “Контроль доступа” — Вкладка “Политика доступа”. Выбираем профиль “Content Editor”, копируем его и называем “Менеджер”.

В списке разрешений проставляем дополнительно следующие параметры:

• Установить галку “Изменять права доступа (chmod) к каталогам”;
• Установить галку “Создавать каталоги в файловой системе”;
• Установить галку “Получать список подкаталогов для каталога в файловой системе”;
• Установить галку “Переименовывать каталоги в файловой системе”;
• Установить галку “Создавать файлы”;
• Установить галку “Смотреть список файлов в определенном каталоге”;
• Установить галку “Использовать диспетчер файлов”;
• Установить галку “Удалять файлы”;
• Установить галку “Видеть дерево файлов в левой навигационной панели”;
• Установить галку “Изменять файлы”;
• Установить галку “Загружать файлы в папку”;
• Установить галку “Просматривать содержимое файла”;
• Установить галку “Использовать пакеты в системе управления пакетами”;
• Установить галку “Использовать страницу «Поиск»”.

Сохраняем изменения.

Переходим в: “Настройки” — “Контроль доступа” — Вкладка “Группы пользователей & Пользователи”.

Создаем новую группу пользователей и называем ее “Менеджеры”.

Устанавливаем в окне новой группы пользователей контексты web, mgr.

Устанавливаем в окне новой группы политику бекенда — Менеджер.

Сохраняем изменения.

Редактируем группу пользователей “Менеджеры”.

Вкладка “Доступ к контекстам” редактируем контексты web и mgr. Устанавливаем “Политика доступа” на значение “Менеджер”.

Сохраняем изменения.

Переходим в: “Управление” — “Пользователи”. Создаем нового пользователя.

Задаем необходимое имя. Указываем e-mail. Устанавливаем пароль вручную. Ставим чекбокс “Активный”. Далее переходим на вкладку “Права доступа”. Добавляем пользователя в созданную группу “Менеджеры”. Роль: “Super User”.

Сохраняем изменения.

“Управление” — “Перезагрузить права доступа”.

Переходим в: “Медиа” — “Источники файлов”. Копируем “Filesystem”. Редактируем копию. Переименовываем в “Images”, для параметра basePath меняем следующие параметры:

• Словарь — “baseUrl:”,
• Значение — ”assets/images/”

Важно! Создать в папке assets папку images.

Переходим в: “Настройки” — “Контроль доступа”.

Редактируем группу пользователей “Менеджеры”. Переходим на вкладку “Права доступа” — “Доступ к источнику файлов”. Добавляем новый источник. Images, Минимальная роль: Member-9999. Политика доступа: Media Source Admin.

Сохраняем изменения.

“Управление” — “Очистить кэш”. “Управление” — “Перезагрузить права доступа”.

Переходим в: “Медиа” — “Источники файлов”. Редактируем “Filesystem”. Переходим на вкладку “Права доступа”. Добавляем группу пользователей. Группа пользователей “Administrator”. Минимальная роль: Super User-0. Политика доступа: Media Source Admin.

Сохраняем изменения.

Переходим в: “Медиа” — “Источники файлов”. Редактируем “Images”. Переходим на вкладку “Права доступа”. Добавляем группу пользователей. Группа пользователей “Administrator”. Минимальная роль: Super User-0. Политика доступа: Media Source Admin.

Сохраняем изменения.

Переходим в: “Содержимое” — “Группы ресурсов”. Создать группу ресурсов. Имя: Администратор. Контексты: web, mgr. Чекбокс: Автоматически дать доступ группе Administrator.

Сохраняем изменения.

“Управление” — “Очистить кэш”. “Управление” — “Перезагрузить права доступа”.

MODX настройка прав контент-менеджера — aboro.net

Настройка прав для контент-менеджера в Modx Revo

В первый раз мне было достаточно сложно осознать систему назначения прав в Revo. На взгляд новичка она запутана и не логична. Но на самом деле она весьма удобна. И если иметь на руках хорошую инструкцию по настройке прав, то все становится прозрачным.  Думаю, создание учетной записи контент-менеджера, является наиболее первоочередной  и актуальной проблемой. Поэтому опишу процесс создания таковой, а также все ошибки, с которыми мне пришлось столкнуться при настройке.

  Внизу статьи есть ссылка на источник, которым я пользовался при настройке прав, помимо официальной документации Modx Revo. Советую ознакомиться с этим до прочтения моей статьи, т.к. она является скорее инструкцией, и необходимо понять основную суть системы перед её использованием.  Итак начнем! Заходим в меню «Безопасность—Контроль доступа»:

Затем во вкладку «Политики доступа»:

Создадим новую политику для менеджера:

Имя политики: 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.

Сохраняем группу, затем находим её в списке и выбираем для редактирования:

   На вкладке общей информации видно, что данная группа имеет в качестве родительской группу администратора, т.к. мы создали её внутри данной группы. Но это используется скорее для удобства восприятия, поэтому, если вынести её из родителя, абсолютно ничего не изменится.

Перейдем на вкладку «Доступ к контекстам»:

Добавим новый контекст:

   Контекст mgr определяет права для работы с админкой. В данном случае мы задаем требуемую минимальную роль для него: Manager — 9 и политику доступа Manager, созданную ранее, которая и определяет список прав менеджера. 

Сохраним созданный контекст. И добавим ещё один:

   Контекст web определяет права доступа к ресурсам (страницам). Сюда относится редактирование, создание, сохранение изменений, удаление и прочее. Минимальная роль —Manager — 9, а политика доступа — Administrator (т.е. любые действия с ресурсами разрешены).

Сохраняем контекст и все изменения на странице группы ресурсов.

Далее переходим в меню «Безопасность—Управление пользователями»:

Создадим нового пользователя:

В качестве имени зададим: Manager. Данное имя будет использоваться при входе в админку. Отметим пользователя как активного. Также внизу на вкладке общей информации можно задать способ создания пароля к учетной записи.

Перед тем как сохранять учетную запись зайдем на вкладку «Права доступа» и добавим нашего пользователя в ранее созданную группу для менеджера: Manager, назначив ему роль менеджера:Manager:

Затем сохраняем пользователя и запоминаем пароль, который вывелся на экране. 

   Вроде бы даже и все. Можно было бы выйти из под учетной записи администратора и зайти в админку в качестве менеджера. Но есть еще один момент!

  В данном случае менеджер имеет доступ к файловой системе, а именно — ко всем файлам данного сайта на сервере. Чтобы ограничить доступ к ним, необходимо создать новый источник файлов исключительно для менеджера. 

   Для этого необходимо зайти в меню «Инструменты—Источники файлов»:

   Изначально в списке источников только основной источник: Filesystem. Для начала надо ограничит доступ к нему:

   Откроем страницу редактирования источника Filesystem. Далее на вкладке «Права доступа»добавим группу пользователей, которой хотим предоставить доступ:

   Назначим группу: Administrator, минимальную роль: SuperUser — 0 и политику: Media Source Admin.

   Сразу после сохранения у всех пользователей, не относящихся к указанной группе и роли, пропадет доступ в источнику файлов Filesystem. Вместе с этим, эти пользователи не увидят данного источника в списке на странице инструментов!

  Далее вернемся к списку источников и создадим новый источник для менеджера —PicturesManager. Допустим в этом источнике будут сохраняться картинки к статьям:

Сохраним созданный источник. Теперь найдем его в списке и отредактируем его параметры:

   На вкладке общей информации внизу есть список параметров. Нас интересуют сейчас первые четыре. Остальные параметры назначены по умолчанию весьма удачно, в частности для использования источника в качестве хранилища изображений.

   Необходимо задать основной путь (basePath) к источнику и основной путь для ссылок на файлы источника (baseUrl). При этом пути задаются с учетом параметров basePathRelative иbaseUrlRelative, которые в значении «Да» отвечают за вставку в начало пути — пути к папке сайта на сервере. Т.е. конечный путь состоит из двух частей:

/var/www/site_name/  и manager/template/tpl_name/pictures/

Первая часть прописывается в «Настройках системы» Modx Revo. Но её трогать не стоит, обычно по умолчанию она стоит правильная. В нашем случае вам нужно заменить tpl_name на название вашего шаблона для сайта и создать папку pictures.

Итого, параметры baseUrl и basePath устанавливаются в значение:

 manager/template/tpl_name/pictures/ 

А параметры basePathRelative и baseUrlRelative в значение: «Да».

   Перед тем, как задать права доступа для менеджера к созданному источнику, необходимозаострить внимание на том, что после задания прав, источник перестанет быть доступным для учетной записи администратора, в том числе и для редактирования. 

   Единственный способ исправить это — зайти в меню «Безопасность — Контроль доступа». Открыть на редактирование группу менеджера: Manager и во вкладке «Источники файлов» найти и удалить источник PictureManager. Только тогда мы сможем вновь редактировать данный источник из под администратора.

   Но самое главное даже не это, а то, что если на какой-либо странице используется tv параметр с типом ввода «Изображение», т.е. tv, который непосредственно обращается к какому-либо источнику файлов, то для него необходимо задать источник файлов PictureManager прежде, чем назначать права менеджера на него, иначе потом мы это сделать не сможем. 

   Поэтому заходим в свойства нужного нам tv параметра на вкладку «Источники файлов» и задаем для контекста web наш источник файлов, два раза кликнув на область «Кэшированный код ресурса», не забываем сохранить изменения:

И только после этого смело задаем права доступа для источника файлов PictureManager:

  Задаем группу пользователей: Manager, минимальную роль: Manager-9 и политику: Media Source Admin. Сразу после сохранения источник файлов исчезнет для администратора (способ возврата оговаривался чуть выше) , а tv параметры с назначенным источником файлов PictureManagerперестанут быть редактируемыми из под учетной записи администратора. Причем это проявляется при попытке администратором сохранить страницу, которая использует этот tv, вследствие чего значение tv сбрасывается и картинка пропадает со страницы.

разрешений — Политики | Документация MODX

Что такое разрешение? ¶

Разрешение в Revolution — это единый элемент управления доступом, который разрешает или запрещает выполнение одной задачи. Вы можете думать о разрешении как о флажке: может ли пользователь выполнить действие или нет?

Примером разрешения является «content_types» — если политика пользователя не содержит этого разрешения, то пользователь не сможет выполнить это действие. В этом случае пользователь не может просматривать страницу типов контента.

Обычно разрешения обрабатываются не индивидуально, а в группах, называемых политиками доступа. Политика доступа — это список индивидуальных разрешений (также называемый списком контроля доступа или ACL). Например, если вам нужно предоставить пользователям разрешения, необходимые для редактирования содержимого в диспетчере, вы можете назначить им использование политики «Редактор содержимого».

MODX всегда являются аддитивными: если разрешение существует в «Политике доступа A», а не в «Политике доступа B», и вы добавляете обе политики пользователю, действующая политика представляет собой совокупность всех разрешений, определенных в обеих политиках.Добавление дополнительных политик никогда не приведет к удалению разрешений для пользователя. Например, если вы добавите ограниченную политику «Только загрузка» пользователю-администратору, пользователь-администратор по-прежнему сможет выполнять все действия, определенные в политике администратора.

Использование¶

На практике политики доступа связаны с группами пользователей (а не с отдельными пользователями). Политики доступа связаны с группой пользователей, и пользователи могут быть добавлены в группу.

(ACL) определяют списки разрешений (см. Меню -> Контроль доступа).Эти списки содержат группы разрешений, которые принадлежат друг другу.

1. Разрешения — Политика администратора
2. Разрешения — Политика ресурсов

См. Также

1. Пользователи
2. Группы пользователей
3. Группы ресурсов
4. Роли
5. Политики
   1. Разрешения
      1. Разрешения — Политика администратора
      2. Разрешения — Политика ресурсов
   2. ACL
   3. Шаблоны политики
6. Учебники по безопасности
   1. Предоставление доступа к менеджеру пользователей
   2. Создание страниц только для членов
   3. Создание второго суперадминистратора
   4. Ограничение доступа к элементу для пользователей
   5. Подробнее о группе анонимных пользователей
7. Закалка MODX Revolution
8. Устранение неполадок безопасности
   1. Сброс пароля пользователя вручную

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

политик — безопасность (ACL) | Документация MODX

Что такое политика доступа? ¶

Политика доступа — это набор разрешений, содержащий одно или несколько разрешений, как определено в диспетчере.По умолчанию MODX поставляется с предварительно настроенными политиками доступа:

• Администратор : Политика администрирования контекста со всеми разрешениями по умолчанию.
• Редактор контекста : Политика администрирования контекста с ограниченными разрешениями, связанными с редактированием контента, но без разрешений на публикацию.
• Контекст : стандартная политика контекста, которую можно применять при создании контекстных списков управления доступом для базового доступа для чтения / записи и просмотра неопубликованных в контексте.
• Элемент : Политика элемента MODX со всеми атрибутами.
• Только загрузка : минимальная политика с разрешением на загрузку объекта.
• Загрузка, список и просмотр : Предоставляет только разрешения на загрузку, список и просмотр.
• Администратор источника мультимедиа : Политика администрирования источника мультимедиа.
• Пользователь источника мультимедиа : Политика пользователя источника мультимедиа с базовым просмотром и использованием — но без редактирования — источников мультимедиа.
• Объект : Политика объекта со всеми разрешениями.
• Ресурс : Политика ресурсов MODX со всеми атрибутами.

Если вы настраиваете любую из вышеперечисленных политик доступа по умолчанию, продублируйте (и переименуйте) их перед настройкой! Если вы этого не сделаете, все настройки будут потеряны при обновлении MODX до более новой версии, так как они будут отменены установочным скриптом.

Создание и редактирование¶

Чтобы создать политику доступа в диспетчере, перейдите к

Безопасность -> Контроль доступа -> Политики доступа

Оттуда вы можете добавлять новые политики.Чтобы отредактировать политику доступа в диспетчере, просто щелкните правой кнопкой мыши политику, которую вы хотите изменить.

Использование¶

можно использовать множеством разных способов. Вот 3 примера использования по умолчанию в MODX:

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

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

MODX поставляется с политикой администратора по умолчанию, которая содержит все разрешения, которые можно использовать в контекстном ACL. Лучше продублировать эту политику при создании настраиваемой политики доступа для ограничения пользователей-менеджеров.

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

Они также могут быть списками управления доступом к ресурсам, которые ограничивают доступ к ресурсам на основе ролей и групп ресурсов. MODX поставляется в комплекте с политикой ресурсов по умолчанию, которая содержит все основные разрешения, которые можно использовать в ACL группы ресурсов.

Примером может быть назначение политики «Ресурс» группе ресурсов под названием «Документы HR». Затем вы должны предоставить группе пользователей под названием «Отдел кадров» доступ к этой группе ресурсов через ACL ресурса:

Это ограничит все ресурсы в группе ресурсов «Кадровые документы» только для пользователей из группы «Отдел кадров».

Доступ к категории элементов¶

Элементы могут быть ограничены для просмотра ACL по категориям. Например, если у вас есть группа пользователей под названием «Разработчики», и вы хотите, чтобы пользователи в этой группе были единственной группой, которая может видеть элементы в категории «Галерея», вы должны создать такой ACL в «Доступ к категории элементов. вкладка при редактировании группы пользователей:

Это позволит только пользователям из группы пользователей «Разработчики» просматривать элементы в категории «Галерея».

Примеры¶

Вот пример настраиваемой политики:

и его разрешения:

Любой пользователь, имеющий доступ к этой Политике, будет иметь разрешения «view_accounts» и «save_accounts».

См. Также

1. Пользователи
2. Группы пользователей
3. Группы ресурсов
4. Роли
5. Политики
   1. Разрешения
      1. Разрешения — Политика администратора
      2. Разрешения — Политика ресурсов
   2. ACL
   3. Шаблоны политики
6. Учебники по безопасности
   1. Предоставление доступа к менеджеру пользователей
   2. Создание страниц только для членов
   3. Создание второго суперадминистратора
   4. Ограничение доступа к элементу для пользователей
   5. Подробнее о группе анонимных пользователей
7. Закалка MODX Revolution
8. Устранение неполадок безопасности
   1. Сброс пароля пользователя вручную

Политика администратора — Разрешения | Документация MODX

ролей — безопасность (ACL) | Документация MODX

Что такое роль? ¶

Роль — это должность или статус, занимаемый в определенной ситуации.В MODX его можно использовать для группировки пользователей по должности или статусу в группе пользователей, например «Редактор» или «Интерфейс только для чтения».

Роли в MODX используют целочисленное значение, называемое «Полномочия». Меньшие числа представляют более сильный авторитет. Например. Роль с полномочиями 10 будет наследовать все групповые политики, назначенные себе и любым ролям, определенным с полномочиями 11, но роль пользователя с полномочиями 11 НЕ наследует никакие групповые политики от роли 10.

Обязательно уточняйте свой язык, когда говорите об авторитете, потому что эта обратная связь может привести к некоторым сбивающим с толку предложениям.

Это помогает думать о «Авторитетах» как о порядковых числах: первое, второе, третье и т. Д. Авторитет = 1 является первым авторитетом и превосходит Авторитет = 2 (т.е. второй авторитет).

Как правило, следует избегать дублирования авторитетных номеров.

Использование¶

Один из распространенных примеров — создание ролей, имитирующих базовую структуру должности сотрудника. Допустим, мы создаем следующие уровни ролей и полномочий:

• Администратор — 0
• Директор — 1
• Координатор — 2
• Руководитель — 3
• Сотрудник — 9999

Затем мы можем создать группу пользователей под названием «Отдел кадров».Внутри этой группы пользователей мы назначим пользователей этим ролям (у вас также может быть несколько пользователей для каждой роли).

Теперь предположим, что у Джона есть роль координатора. Марк выполняет роль супервайзера. Мы собираемся предоставить группе пользователей Марка «Отдел кадров» политику доступа (которая представляет собой набор разрешений) под названием «AccountPolicy», в которой есть следующие разрешения доступа:

• view_accounts
• save_accounts

Мы назначили эту Политику контексту «Интернет» для нашей группы пользователей «Отдел кадров».Затем мы устанавливаем его минимальное значение роли на «Супервизор»:

Это означает, что у Марка есть эти Разрешения, поскольку он входит в группу пользователей, и он имеет как минимум роль «супервизора» (а именно роль, которую он выполняет).

Но этот также означает, что Джон также имеет эти Разрешения, поскольку он «Координатор», который имеет более сильный уровень Полномочий, чем «Супервайзер». Итак, Джон как Координатор «унаследовал» Разрешения, чем Марк как Супервизор.

См. Также

1. Пользователи
2. Группы пользователей
3. Группы ресурсов
4. Роли
5. Политики
   1. Разрешения
      1. Разрешения — Политика администратора
      2. Разрешения — Политика ресурсов
   2. ACL
   3. Шаблоны политики
6. Учебники по безопасности
   1. Предоставление доступа к менеджеру пользователей
   2. Создание страниц только для членов
   3. Создание второго суперадминистратора
   4. Ограничение доступа к элементу для пользователей
   5. Подробнее о группе анонимных пользователей
7. Закалка MODX Revolution
8. Устранение неполадок безопасности
   1. Сброс пароля пользователя вручную

Разрешения и пользователи — Веб-дизайн и услуги

Содержание

Вероятно, вам потребуется предоставить разные типы доступа для разных типов пользователей.Администраторам потребуется полный доступ ко всему. Другим пользователям потребуется доступ только к определенным частям сайта, и им может потребоваться ограничить виды действий, которые они могут выполнять.

Пользователи

MODx имеет два типа пользователей:

1. Пользователи менеджера: человек, которые могут использовать интерфейс менеджера MODx для создания и редактирования контента
2. Интернет-пользователи: человек, которым не нужен доступ менеджера, но которым необходимо войти в другие функции веб-сайта, например, для комментирования блогов.

Это различие исчезнет в версии 0.9.7 и выше, но на данный момент различие все еще существует.

Для создания менеджера пользователь

Перейдите в Безопасность> Пользователи диспетчера , затем нажмите «Новый пользователь».

Интернет-пользователи

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

Роли

У каждого пользователя-менеджера будет своя роль. Роль определяет глобальные права пользователя-менеджера в системе MODx. Роль может предоставлять или ограничивать доступ для выполнения функций, связанных с контентом, шаблоном, фрагментами, управлением пользователями и т. Д. В каждой ситуации будут свои уникальные потребности, но вот несколько предлагаемых ролей, которые будут работать во многих ситуациях:

• Администратор: Учетная запись администратора по умолчанию (эту роль нельзя редактировать или удалять)
• Разработчик: Доступ ко всему, кроме разрешений пользователей, ролей и конфигурации сайта
• Designer Plus: Доступ к контенту, файлам ^{[примечание]} , шаблонам, фрагментам и фрагментам
• Дизайнер: Доступ к контенту, файлам ^{[примечание]} и шаблонам
• Редактор: Доступ к контенту и файлам ^{[примечание]}
• Корректор: Возможность редактировать контент, но не создавать или удалять контент, а также нет доступа к файлам.

Примечания к файлам:

1. Чтобы предоставить доступ к файловому менеджеру (для загрузки PDF-файлов, документов Word и т. Д.), Вам необходимо прокрутить до конца страницы до раздела «Управление конфигурацией» и выбрать «Использовать файловый менеджер. . »
2. Вы можете ограничить доступ пользователей к подкаталогам в файловом менеджере.

Важные моменты о ролях:

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

Создание роли

Перейдите в Безопасность> Роли> Создать новую роль . Установите флажки рядом с разрешениями, которые вы хотите предоставить.

Назначение роли пользователю-менеджеру

Выберите соответствующий вариант в раскрывающемся списке «Роль пользователя» при создании или редактировании пользователя ( Безопасность> Менеджер пользователей ).

Разрешения группы

В MODx способ ограничения доступа к каким документам осуществляется с помощью групповых разрешений. Есть два типа групп:

1. Группы пользователей
2. Группы документов

Вы должны создать и то, и другое, чтобы система работала правильно. Как минимум, вы должны создать группу пользователей, создать группу документов, а затем связать их друг с другом. Одной группе пользователей можно назначить несколько групп документов.Невозможно назначить несколько групп пользователей одной группе документов.

Пример

Вот сценарий из реального мира. Допустим, у вас есть 13 организаций, о которых вы хотите опубликовать информацию на своем веб-сайте: Организация A, Организация B, Организация C и т. Д. Через организацию M. Вы хотите предоставить доступ определенным людям в каждой организации для редактирования их собственного веб-сайта. страницы, но не веб-страницы других организаций. Чтобы усложнить ситуацию, организации от A до F относятся к категории 1, а другие — к категории 2.Вы хотите назначить группу «менеджеров категории 1» для наблюдения за веб-страницами всех организаций в категории 1, и вы хотите назначить другую группу «менеджеров категории 2» для наблюдения за веб-страницами организаций в категории 2. Вдобавок ко всему у вас есть «царь организаций», который отвечает за надзор за всеми организациями в обеих категориях.

Вот как это можно настроить:

1. Создайте группу пользователей для каждой организации. Чтобы упростить задачу, вы можете назвать группы пользователей «Организация A», «Организация B» и т. Д. Через «Организация M».”
2. Создайте группу документов для каждой организации. Я бы использовал то же соглашение об именах («Организация A», «Организация B» и т. Д.).
3. Создайте группу пользователей под названием «Категория 1» и группу пользователей под названием «Категория 2».
4. Создайте группу пользователей под названием «Организации».
5. Свяжите группы пользователей с соответствующими группами документов .
   • Свяжите группы пользователей для отдельных организаций только с одной группой документов, например.грамм. группа пользователей «Организация А» будет связана с группой документов «Организация А».
   • Свяжите группу пользователей «Категория 1» со всеми группами документов для каждой из организаций, принадлежащих к Категории 1. Организации с A по F принадлежат к Категории 1, поэтому свяжите группу пользователей «Категория 1» с группами документов «Организация A». через «Организацию Ф.»
   • Свяжите группу пользователей «Организации» с каждой из групп документов организации.
6. Назначьте пользователей в соответствующие группы пользователей.
7. Отнесите документы к соответствующей группе (группам) документов.

Для создания группы пользователей

Перейдите в Безопасность> Разрешения менеджера> Группы пользователей . Введите имя группы в разделе «Создать новую группу пользователей». Нажмите «Отправить».

Создание группы документов

Перейдите в Безопасность> Разрешения менеджера> Группы документов . Введите имя группы в разделе «Создать новую группу пользователей». Нажмите «Отправить».

Чтобы связать группы пользователей с группами документов

Перейдите к Безопасность> Разрешения менеджера> Ссылки на группы пользователей / документов .Выберите имя группы документов из раскрывающегося списка документов. Нажмите «Добавить». Вы можете повторить этот процесс, чтобы добавить несколько групп документов в одну группу пользователей.

Добавление пользователя в группу пользователей

Перейдите в раздел «Безопасность »> «Пользователи диспетчера », затем щелкните имя пользователя (или нажмите «Новый пользователь»). Прокрутите вниз, пока не увидите «Разрешения доступа». Выберите соответствующие группы пользователей. Обратите внимание, что вы не можете добавлять пользователей в группы document , только в группы пользователей.

Добавление документа в группу документов

Щелкните страницу в дереве документов слева, затем щелкните «Редактировать» в главном окне.Прокрутите до нижней части экрана, пока не увидите список «Разрешения доступа». Выберите соответствующие группы документов из списка. Обратите внимание, что вы не можете добавить документ в группу пользователей , только в группы документов .

Важные сведения о разрешениях группы:

• По умолчанию ограничения доступа к документам отсутствуют. Если документы не отнесены к определенной группе, они доступны для редактирования для всех групп документов. В большинстве многопользовательских настроек это плохая идея. Если вы не являетесь небольшой командой администраторов с полными привилегиями, которые полностью доверяют друг другу, вы, вероятно, не хотите, чтобы какой-либо документ был полностью доступен для редактирования всеми. Вы должны создать группы и назначить все страницы хотя бы в одну группу.
• Пользователи могут получить доступ только к тем файлам, которые назначены их группе. Если пользователь не включен в группу, он сможет получить доступ только к документам, отмеченным как «Все группы документов (общедоступные)». Если все документы назначены группе (как и должно быть), этот пользователь не сможет получить доступ к каким-либо документам.
• Документы наследуют разрешения своих родительских документов. По умолчанию, когда вы создаете документ, он унаследует разрешения своего родительского документа, что обычно хорошо… если только вы не поймете после того, что вы забыли назначить правильные разрешения для родительского документа. Затем вам нужно вернуться и вручную связать каждый документ с соответствующей группой (группами). Особенно важно установить правильные разрешения при создании страниц на корневом уровне сайта, потому что без какого-либо родительского документа для наследования они будут доступны для редактирования всеми пользователями по умолчанию, что, как я уже упоминал ранее, вероятно, плохо.

ПРЕДУПРЕЖДЕНИЕ. Пользователям должно быть предоставлено разрешение хотя бы на один документ на корневом уровне. К сожалению, система разрешений в MODx не позволяет пользователям получать доступ к подкаталогам, если они также не могут получить доступ к родительскому документу (ам). Если вы не предоставите доступ хотя бы к одной строке родительских документов до корневого уровня, пользователи увидят пустое дерево документов и не смогут получить доступ ни к чему. Это недостаток MODx, потому что это означает, что пользователям должны быть предоставлены полные права редактирования всех родительских документов в этом пути, даже если вы не хотите, чтобы они имели такой доступ.Используя приведенный выше пример, если путь к главной странице «Организация A» — / organization / category1 / organizationA /, вы должны указать документы «organization» и «category1» как принадлежащие к группе документов «Organization A». Люди, принадлежащие к группе документов «Организация А», смогут редактировать все страницы под «организацией А», как вы хотите и ожидаете, но они также смогут редактировать родительские документы «организации» и «категория 1». как, возможно, вы не ожидали и уж точно не хотите.Но так оно и есть. В настоящее время нет способа обойти этот недостаток в системе разрешений MODx.

Настройка разрешений для файлового менеджера

Если вы мудро решили, что не хотите, чтобы все ваши пользователи имели полный доступ ко всем файлам в файловом менеджере (папка «активы»), вам нужно будет ограничить их доступ к определенному подкаталогу в этой папке. Это звучит достаточно просто, и в некотором смысле это так, но это усложняется тем, как работает файловый браузер для редакторов форматированного текста MODx.

Принцип достаточно прост: чтобы ограничить пользователя определенным каталогом в файловом менеджере, установите для этого пользователя «Путь к файловому менеджеру» в подкаталог в папке «assets». Например, если путь по умолчанию к файловому менеджеру — «/ home / web / public_html / assets /» ^{[примечание]} , вы можете установить каталог для пользователя в группе «Организация A» примерно так: «/ home / web / public_html / assets / org_a / ». Но нужно учитывать и другие факторы. Если вы хотите, чтобы люди из групп пользователей «Организации» и «Категория 1» также имели доступ к этой папке, вам, вероятно, следует поместить путь в аналогичную иерархию.Что-то вроде этого может сработать: «/ home / web / public_html / assets / orgs / cat1 / org_a /».

Примечание: Путь по умолчанию для диспетчера файлов задается в конфигурации сайта в разделе Инструменты > Конфигурация> Диспетчер файлов> Путь диспетчера файлов .

Для настройки пути к файловому менеджеру

Перейдите в Безопасность> Пользователи диспетчера , щелкните имя пользователя, которого вы хотите изменить (или выберите «Новый пользователь»), затем щелкните вкладку «Пользователь» и введите желаемый путь в поле «Путь к диспетчеру файлов. .”

• Настройка пути диспетчера файлов не влияет на браузер файлов из редактора форматированного текста. Вы ​​должны установить этот путь отдельно (см. Настройку разрешений для TinyMCE).

Настройка разрешений для TinyMCE

TinyMCE можно настроить для каждого пользователя с точки зрения интерфейса и файлового браузера. Настройки по умолчанию для сайта доступны в Инструменты> Конфигурация> Интерфейс и функции> Настройки TinyMCE .Чтобы настроить эти параметры для отдельных пользователей, перейдите к Security> Manager Users , щелкните имя пользователя, которого вы хотите изменить (или выберите «Новый пользователь»), затем щелкните вкладку «Пользователь» и прокрутите вниз до Параметры «Путь к ресурсу» и «URL ресурса».

Настройка папки обозревателя файлов

Вероятно, вы хотите, чтобы путь к файловому менеджеру совпадал с путем к файловому браузеру, используемому в многофункциональном текстовом редакторе TinyMCE. Вам необходимо изменить два пути: «Путь к ресурсу» и «URL-адрес ресурса».»Сделайте« Путь к ресурсам »таким же, как« Путь к файловому менеджеру ». В нашем примере путь будет «/ home / web / public_html / assets / orgs / cat1 / org_a /». Для «URL ресурса» преобразуйте этот путь в общедоступный URL-адрес веб-сайта: «http://your_web_site.com/home/web/public_html/assets/orgs/cat1/org_a/».

Важно: Если вы настраиваете путь к файловому браузеру, вам нужно будет создать две подпапки внутри этого пути: «изображения» и «файлы». Браузер файлов ищет все изображения в папке, называемой изображениями, и ищет все файлы в папке, называемой «файлы».«Если этих папок не существует, пользователи не смогут воспользоваться преимуществами файлового браузера. В нашем примере папки будут находиться по следующим путям: «/ home / web / public_html / assets / orgs / cat1 / org_a / images /» и «/ home / web / public_html / assets / orgs / cat1 / org_a / files. / ». Вам НЕ нужно вводить эти пути где-либо в параметрах конфигурации, но папки должны существовать для работы файлового браузера.

Настройка интерфейса TinyMCE

Вам не нужно настраивать интерфейс TinyMCE.Если вы оставите все файлы в разделе «Настройки TinyMCE» пустыми, пользователям будут предоставлены функции по умолчанию, указанные в настройках сайта (Инструменты > Конфигурация> Интерфейс и функции> Настройки TinyMCE ). Но вы можете решить, что хотите, чтобы у некоторых пользователей были настроенные версии интерфейса TinyMCE. Есть предустановленные «Темы» на выбор: простые, расширенные, редактор содержимого и пользовательские. Выберите один из этих вариантов.

Установка параметров для «Пользовательских плагинов», «Пользовательских кнопок» и «Селекторов CSS» выходит за рамки настоящего руководства, но я упомяну одну полезную возможность: добавление элементов управления редактированием таблицы.Вероятно, это следует сделать для всех пользователей, а не только для определенных. Чтобы добавить параметры редактирования таблицы, введите «tablecontrols» в строке 3 «Пользовательские кнопки». Прокрутите вверх и нажмите «Сохранить».

ПРЕДУПРЕЖДЕНИЕ: Невозможно установить собственный файл CSS для каждого пользователя. Если вы установите «Путь к файлу CSS» в конфигурации сайта (Инструменты > Конфигурация> Интерфейс и функции> Настройки TinyMCE ), вы застрянете с этой таблицей стилей, несмотря ни на что, даже на страницах, которые ее не используют.Это настоящий позор, и это сильно ограничивает полезность опции «Путь к файлу CSS». Один неуклюжий обходной путь — ограничить количество классов, доступных для TinyMCE, указав их в опции сайта «Селекторы CSS», а затем убедиться, что все таблицы стилей имеют все эти конкретные классы.

Руководств Боба | Разрешения Revolution

Разрешения Revolution

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

Всегда помните, что никогда не следует изменять стандартные политики или шаблоны политик, предоставленные при базовой установке MODX. Если, например, вы измените стандартную политику администратора, чтобы снять отметку с некоторых разрешений, вы заберете эти разрешения у суперпользователя Admin. Если вы удалите разрешения из стандартного шаблона политики администратора, вы также отнимете эти разрешения у суперпользователя Admin.То же касается и других стандартных политик и шаблонов политик. Всегда дублировать политики или шаблоны политик и изменять дубликаты.

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

Где это сделано

Это помогает понять, что на самом деле система разрешений Revolution состоит из четырех частей.

• Какие ресурсы пользователи могут видеть и что они могут с ними делать, контролируется записями ACL.
• Видимость вкладки «Элементы» и вкладки «Файлы» контролируется определенными разрешениями (element_tree, file_tree).
• Видимостью и организацией главного меню можно управлять в Manager | Действия.
• Какие поля отображаются на панели «Создать / редактировать ресурс» для конкретных пользователей, контролируется в Безопасность | Настройка формы.

Больше никаких веб-пользователей и пользователей-менеджеров

В MODX Revolution больше нет различия между пользователями-менеджерами и веб-пользователями — есть только пользователи.Управление доступом в передней и задней частях выполняется с помощью контекстов. Пользователи в бэкенде находятся в контексте «mgr», пользователи во внешнем интерфейсе находятся в «веб-контексте» (или другом контексте, который вы создаете). Под серверной частью мы имеем в виду, где вы находитесь, когда вы входите в систему через yoursite.com/manager и работаете в MODX Manager. С другой стороны, пользователи во внешнем интерфейсе посещают сайт через yoursite.com и могут или не могут войти в систему через форму во внешнем интерфейсе сайта.

В Revolution пользователь в любой момент времени находится в системе или не авторизован.Пользователь в диспетчере MODX вошел в систему и в контексте «mgr». Пользователь во внешнем интерфейсе находится в «веб-контексте» (или другом контексте, который вы создаете) и может войти в систему или нет. Если не вошел в систему, Пользователь является анонимным пользователем, имеющим только Разрешение «загружать» документы (то есть просматривать их).

Основные принципы

В MODX Evolution документы «защищаются», когда группа документов назначается группе пользователей. Как только это будет сделано, только Пользователи, которым предоставлены права на Документы, смогут получить к ним доступ.Подключения «Пользователь диспетчера / группа ресурсов диспетчера» применяются только в серверной части (в диспетчере MODX). Соединения WebGroup / WebUser применяются только во внешнем интерфейсе сайта.

В MODX Revolution документы и контексты защищены списками контроля доступа (ACL) (подробнее об этом позже). После того, как документ или контекст защищены одной записью ACL, к нему могут получить доступ только Пользователи, которым предоставлен доступ к нему в записи ACL, и эта запись будет определять, что они могут делать.

Права доступа перечислены в Политике доступа.Эти политики назначаются в записях ACL с указанной ролью и указанным контекстом. Списки контроля доступа (ACL) принадлежат определенной группе пользователей, и (в отличие от Evolution) разным пользователям могут быть назначены разные роли в группе. Сейчас это может показаться тарабарщиной, но по мере продвижения это должно стать ясным.

Эта система, хотя поначалу немного сложна для понимания, дает вам огромную гибкость, позволяя иметь пользователей в одной группе пользователей, которые имеют доступ к одним и тем же ресурсам, но с разными возможностями.Например, при наличии трех пользователей в одной группе пользователей один пользователь может видеть документ в дереве, но не может его редактировать. Другой Пользователь может видеть, редактировать и сохранять Документ, но не может публиковать, отменять публикацию или удалять его. Третий Пользователь может иметь полные права на Документ. Точно так же пользователи в одной группе пользователей могут иметь разные возможности в MODX Manager.

Я предполагаю, что вы знаете или можете понять, что такое пользователь, группа пользователей и группа ресурсов («Ресурс» — официальное название для документов, веб-ссылок, символических ссылок и статических ресурсов — если вы не знаете что все это такое, пока просто подумайте: Resource = Document).Однако, если вы привыкли к разрешениям Evolution, вам потребуется некоторая информация о контекстах, ролях, шаблонах политик, политиках доступа и списках контроля доступа (ACL).

Короче говоря, политики доступа — это просто списки отдельных разрешений (например, save_tv, edit_document, view_document, access_permissions и т. Д.), Которые позволяют пользователю выполнять определенное действие или видеть что-либо в диспетчере. Роли — это имена, которые связаны с политиками доступа с номером авторизации (подробнее об этом позже).ACL — это просто списки правил доступа, которые связывают группы пользователей с группами ресурсов и / или контекстами и политиками. Давайте рассмотрим эти концепции более подробно:

Контексты

Contexts — это новая концепция MODX Revolution, которая имеет множество применений, выходящих за рамки данной страницы. Для наших целей здесь мы предполагаем, что у вас есть только два контекста: «web» и «mgr». Контекст «mgr» по сути является серверной частью (MODX Manager). Веб-контекст — это интерфейс (за небольшим исключением, о котором мы поговорим позже).Если вы позже создадите больше контекстов, все, что вы узнали здесь о «веб-контексте», применимо и к ним.

По умолчанию, когда вы создаете ресурсы в Менеджере, они будут располагаться под значком «Интернет» (если вы не создадите другие контексты и не поместите ресурсы в эти контексты). Ресурсы под значком «Интернет» находятся в контексте «Интернет». Контекст «mgr» — это просто менеджер MODX. Когда пользователи находятся в контексте «mgr», они входят в диспетчер. Разрешения, привязанные к контексту «mgr», определяют, что пользователь может делать и видеть в диспетчере.Разрешения, привязанные к «веб-контексту», ограничивают то, что пользователи могут делать или видеть в интерфейсе сайта.

Роли

В MODX Evolution, когда вы создаете роль, вы точно определяете, какие действия менеджера может выполнять пользователь с этой ролью. Однако в MODX Revolution единственное, что вы устанавливаете при создании роли, — это имя роли, номер полномочий, связанный с этой ролью, и необязательное описание роли. Номер полномочий для роли суперпользователя администратора равен 0. Когда вы создаете другие роли, вы назначаете им более высокие номера полномочий.Это произвольные числа от 0 до 9999. Все, что вам действительно нужно сейчас знать о них, это то, что:

• Роли, которые должны иметь больше прав, должны иметь более низкие номера полномочий.
• Как правило, следует избегать дублирования номеров авторизации.
• Пользователи в группе пользователей «наследуют» разрешения, предоставленные пользователям с ролями, которые имеют более высокие номера полномочий, чем их роли.

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

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

Единственная функция роли — назначить этому пользователю номер полномочий (связанный с ролью) в группе, чтобы пользователь унаследовал разрешения других пользователей в группе с большими номерами полномочий.

Роли создаются путем перехода в Безопасность | Контроль доступа и выбор вкладки «Роли».При нажатии на кнопку «Создать» будет создана новая роль. Роли можно удалить, щелкнув их правой кнопкой мыши и выбрав «Удалить роль».

Шаблоны политик

— это просто списки отдельных разрешений, которые будут отображаться в конкретной политике доступа. Каждая политика доступа основана на определенном шаблоне политики и будет отображать разрешения только для этого шаблона. Вы можете увидеть некоторые из них (Важно: , не редактируйте и не удаляйте их сейчас, ), перейдя в Безопасность | Контроль доступа | Вкладка Шаблоны политик.Щелкните правой кнопкой мыши шаблон политики и выберите «Обновить шаблон политики». Затем щелкните вкладку «Разрешения», чтобы просмотреть список разрешений для этого шаблона политики. Обратите внимание, что здесь вы можете добавлять или удалять разрешения, но не здесь вы назначаете разрешения пользователям. Это делается на вкладке «Политики доступа».

Добавление и удаление разрешений здесь обычно не требуется, потому что вы можете определить, какие пользователи имеют какие разрешения, на вкладке «Политики доступа», установив или сняв их отметку.Как правило, единственная причина для изменения шаблона политики — это если вы хотите добавить настраиваемое разрешение. Например, вы можете добавить настраиваемое разрешение, которое позволяет пользователям видеть определенные элементы в верхнем меню. Некоторые дополнительные компоненты также могут использовать настраиваемые разрешения. Фрагмент NewsPublisher, например, имеет настраиваемое разрешение под названием allow_modx_tags, которое позволяет пользователям редактировать ресурсы, содержащие теги MODX.

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

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

Если у пользователя есть конфликтующие разрешения (например, пользователь принадлежит к двум разным группам и разрешения контекста «mgr» у этого пользователя разные), будет применяться наиболее разрешающее правило.Таким образом, если пользователю предоставлено разрешение в контексте «mgr» в одном месте, никакое другое правило в другом месте не может отнять это разрешение.

При установке Revolution по умолчанию создается несколько стандартных политик и шаблонов политик, включая политику администратора, политику ресурсов и политику элементов. Их использование регулируется четырьмя важными принципами:

• Никогда не редактируйте включенные шаблоны политик администратора или ресурсов. Всегда дублируйте их, а затем редактируйте дубликат.
• Политики, используемые в записях ACL доступа к контексту, должны основываться на стандартном шаблоне политики администратора.
• Политики, используемые в записях ACL доступа к группе ресурсов, должны основываться на стандартном шаблоне политики ресурсов.
• Политики, используемые в записях ACL доступа к категории элементов, должны быть основаны на стандартном шаблоне политики элементов.

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

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

(ACL) — это списки правил, которые связывают группы пользователей с группами ресурсов и / или контекстами. Каждая запись ACL имеет контекст и минимальную роль. Контекст определяет, в каком контексте применяется правило. Контекст «диспетчера» указывает, что правила будут применяться в диспетчере. «Веб-контекст» указывает, что правила будут применяться во внешнем интерфейсе сайта. Минимальная роль определяет, к каким пользователям в группе применяется правило.

Одним из первых камней преткновения для новых пользователей Revolution является поиск списков ACL .Вы можете связаться с ними, перейдя в Безопасность | Контроль доступа | На вкладке «Группы пользователей» щелкните правой кнопкой мыши группу пользователей и выберите «Обновить группу пользователей». Списки ACL доступны на двух вкладках справа на панели «Обновить группу пользователей». Они отображаются в виде сеток, и в настоящее время фраза «Список контроля доступа» не отображается на странице. Каждая строка в сетке представляет собой запись ACL — правило, определяющее, что пользователи с определенной ролью могут делать или видеть.

Обратите внимание, что нет смысла создавать запись ACL до тех пор, пока вы не создадите группу пользователей, роль и политику доступа, которые вы будете использовать в записи ACL.

Существует три типа ACL: ACL доступа к контексту, ACL доступа к группе ресурсов и ACL доступа к категории элементов.

Списки управления доступом к контексту

Записи в этом списке, находящиеся на вкладке «Контекстный доступ» панели «Обновить группу пользователей», определяют, какие административные задачи могут выполнять пользователи в контексте, указанном в записи ACL. Вы создаете новую запись ACL доступа к контексту, щелкая по кнопке «Добавить контекст». Разрешения здесь определяют, что пользователь может делать и видеть в MODX Manager в целом.Приведенные здесь разрешения необходимы для применения указанных ниже разрешений. Если пользователь не имеет права просматривать и редактировать ресурсы в диспетчере, например, запись ACL доступа к группе ресурсов, дающая пользователю право на публикацию ресурса, не применяется.

Когда создается запись ACL доступа к контексту, она «защищает» указанный контекст от пользователя, не входящего в указанную группу пользователей. Никакие пользователи вне группы (включая суперпользователя) не получат доступа к этому контексту, если вы явно не предоставите его им в записи ACL.Например, если вы создаете новый контекст, не забудьте предоставить себе доступ к нему в записи ACL доступа к контексту для группы пользователей «Администраторы» (обычно она будет выглядеть так же, как запись ACL «web»).

В группе пользователей-администраторов уже есть записи ACL доступа к контексту для контекстов «mgr» и «web». Это делает эти контексты «защищенными» по умолчанию. Это имеет потенциально сбивающий с толку побочный эффект: когда вы создаете нового пользователя, этот пользователь не сможет войти в диспетчер, пока вы не поместите пользователя в группу пользователей и не предоставите пользователю доступ в записи ACL доступа к контексту для этого. Группа пользователей с контекстом «мгр.«После того, как вы это сделаете, пользователь сможет войти в систему, но не сможет видеть« веб-контекст »в дереве ресурсов в диспетчере, пока вы не предоставите пользователю доступ к этому контексту в другом ACL доступа к контексту. запись для группы пользователей с «веб-контекстом» (это исключение, о котором мы упоминали ранее, из принципа, согласно которому «веб-контекст влияет только на интерфейс»).

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

Допустим, у вас есть группа пользователей под названием SubAdmins, и вы хотите, чтобы пользователи в этой группе могли использовать Manager, но с ограниченными возможностями. Вот шаги, которые вы должны предпринять:

1. Сначала создайте роль субадминистратора с уровнем полномочий 9.
2. Создайте группу пользователей SubAdmins и добавьте в нее пользователей с ролью SubAdmin.
3. Дублируйте стандартную политику доступа администратора.
4. Отредактируйте дубликат и измените имя на SubAdmin.
5. На вкладке «Разрешения» снимите флажки со всех разрешений, которые не должны иметь ваши субадминистраторы. Удаление разрешения access_permissions не позволит им изменять свой уровень безопасности и уровень безопасности других пользователей. Удаление разрешений element_tree и file_tree не позволит им видеть эти вкладки на левой панели Менеджера. (Примечание: разрешения element_tree и file_tree доступны только в SVN и будущих версиях Revolution RC.)
6. Сохранить политику
7. Обновите группу пользователей SubAdmins, перейдя в Безопасность | Контроль доступа | На вкладке «Группы пользователей» щелкните правой кнопкой мыши группу дополнительных администраторов и выберите «Обновить группу пользователей».«
8. Перейдите на вкладку «Контекстный доступ».
9. Добавьте запись ACL (нажав кнопку «Добавить контекст»). Дайте ему следующее:

• Контекст: mgr
• Минимальная роль: SubAdmin
• Политика доступа: SubAdmin

Если вы выйдете сейчас и войдете в систему как один из пользователей SubAdmin, вход будет успешным, но дерево ресурсов слева будет пустым, потому что мы не предоставили нашим пользователям SubAdmin доступ к «веб-контексту».Нам нужно создать еще одну запись ACL для доступа к контексту со следующим:

• Контекст: Интернет
• Минимальная роль: SubAdmin
• Политика доступа: SubAdmin

Теперь наши субадминистраторы являются настоящими пользователями Менеджера с ограниченным доступом к Менеджеру.

Обратите внимание, что мы могли бы сделать это по-другому. Мы могли бы пропустить создание группы пользователей SubAdmin и просто добавить всех наших пользователей SubAdmin в группу пользователей Administrator с ролью SubAdmin.Затем мы обновили бы группу пользователей-администраторов и добавили две записи ACL доступа к контексту, перечисленные выше. Результаты будут такими же, и то, как вы это сделаете, зависит от вашей общей стратегии безопасности. Если вы будете ограничивать, какие документы могут видеть субадминистраторы, вы, вероятно, захотите создать для них отдельную группу пользователей. Если у них будет доступ ко всем документам в Менеджере, вы можете добавить их в группу пользователей-администраторов.

Я обычно рекомендую * не * помещать других пользователей-администраторов в группу администраторов.Предоставление им собственной группы упрощает понимание и дает вам больше возможностей для настройки формы.

Ничего из того, что вы делаете в ACL доступа к контексту, не повлияет на то, какие документы любой пользователь может видеть во внешнем интерфейсе. Это можно сделать только в ACL доступа к группе ресурсов, указав контекст, отличный от контекста «mgr».

ACL доступа к группе ресурсов

На вкладке «Доступ к группе ресурсов» панели «Обновить группу пользователей» записи ACL в этом списке определяют, какие отдельные ресурсы пользователи могут видеть на передней и задней стороне, и что они могут делать с этими ресурсами.Вы создаете новый ACL доступа к группе ресурсов, нажав кнопку «Добавить группу ресурсов». Как и в случае с ACL доступа к контексту, после создания записи ACL доступа к группе ресурсов вы «защищаете» ресурсы в указанном контексте. Никто не может видеть их в этом контексте, если им не предоставлен доступ к ним в записи ACL доступа к группе ресурсов.

Если вы укажете контекст «mgr», ресурсы в группе ресурсов будут видны в дереве ресурсов в диспетчере только пользователям, которым был предоставлен доступ к ним.Если вы укажете «веб-контекст», только пользователи, которым был предоставлен доступ к ним (и вошли в систему), могут видеть ресурсы в интерфейсе сайта.

Эти записи ACL доступа к группе ресурсов имеют те же поля, что и записи доступа к контексту, с добавлением поля, определяющего группу ресурсов.

Допустим, у вас есть группа пользователей под названием «Редакторы» и группа ресурсов под названием «Новости», содержащая несколько новостных статей. Вы хотите скрыть страницы новостей от пользователей, не являющихся редакторами, в Менеджере.Вы обновляете группу пользователей-редакторов, чтобы создать запись ACL для доступа к группе ресурсов, как показано ниже:

• Ресурсная группа: Новости
• Минимальная роль: редактор
• Политика доступа: ресурс
• Контекст: мгр

Теперь только члены группы пользователей «Редакторы» с минимальной ролью редактора (или ролью с более низким номером полномочий) могут просматривать страницы новостей в Менеджере. У них будут полные права на ресурсы. Чтобы ограничить их, вы можете продублировать политику доступа к ресурсам, изменить имя на «EditorResource», отредактировать дубликат, чтобы снять флажок «Разрешения, которые вам не нужны», и назначить политику EditorResource в записи ACL вместо политики ресурсов.

Как суперпользователь с правами администратора, когда вы сбрасываете разрешения (Безопасность | Очистить разрешения), вы заметите, что страницы новостей исчезают из дерева. Чтобы вернуть их, вам нужно будет либо добавить администратора в группу пользователей редакторов (предположительно с минимальной ролью суперпользователя и политикой доступа администратора), либо обновить группу пользователей-администраторов, чтобы добавить запись ACL доступа к группе ресурсов с указанием Группа ресурсов новостей, контекст «mgr» и снова минимальная роль суперпользователя и политика доступа администратора.Добавление суперпользователя-администратора во все группы пользователей обычно является лучшей стратегией.

Запись ACL, приведенная выше, будет защищать страницы новостей в Менеджере, но любой по-прежнему сможет видеть страницы в интерфейсе сайта.

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

• Ресурсная группа: Новости
• Минимальная роль: редактор
• Политика доступа: ресурс
• Контекст: Интернет

Теперь только члены группы «Редакторы», вошедшие в систему во внешнем интерфейсе, могут видеть страницы новостей.Эта запись ACL будет защищать страницы новостей во внешнем интерфейсе, но не повлияет на то, кто может их видеть в Менеджере.

Обратите внимание, что при предварительном просмотре документов из Менеджера вы по-прежнему входите в систему как суперпользователь с правами администратора. Чтобы проверить свои права доступа к интерфейсу, посетите сайт в другом браузере.

Списки доступа к категории элементов

Эти ACL работают точно так же, как ACL доступа к группе ресурсов, за исключением того, что вместо защиты ресурсов в группе ресурсов они защищают элементы (фрагменты, блоки, шаблоны, переменные шаблона и плагины) в категории.Сначала создайте категорию, щелкнув правой кнопкой мыши «Категории» в дереве элементов и выбрав «Новая категория». Затем перетащите любые элементы, которые хотите защитить, и поместите их в новую категорию. Наконец, перейдите в Безопасность | Контроль доступа | На вкладке «Группы пользователей» щелкните правой кнопкой мыши группу, на которую вы хотите повлиять, и выберите «Обновить группу пользователей». На вкладке «Доступ к категории элементов» нажмите кнопку «Добавить категорию». Выберите категорию, роль группы пользователей, политику доступа Element и контекст «mgr». Сохраните свою работу и удалите все разрешения.Элементы в этой категории теперь защищены от всех других пользователей.

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

Если вы хотите предоставить пользователям ограниченный доступ к элементам в категории (скажем, чтобы разрешить им редактировать, но не удалять элементы), продублируйте политику элемента, назначьте эту политику вместо исходной и снимите флажки со всех разрешений, которые у вас нет. не хочу, чтобы они были.

Управление тем, что пользователи могут делать и видеть в диспетчере

Если вы просто хотите ограничить действия пользователя в Менеджере, не скрывая какие-либо ресурсы или элементы, то, вкратце, вы хотите продублировать стандартную политику администратора. Затем поместите пользователей в группу пользователей и обновите эту группу пользователей в разделе «Безопасность» -> «Контроль доступа». Создайте запись ACL доступа к контексту для контекста диспетчера с дублирующей политикой, которую вы создали (и ролью с более высоким номером полномочий, чем у администратора).Затем отредактируйте дублирующую политику и снимите флажки со всех разрешений, которые вам не нужны.

Это ограничит то, что пользователи могут делать в Менеджере.

Если вам нужен более детальный контроль и вы хотите ограничить то, что пользователи могут делать с некоторыми, но не со всеми ресурсами или элементами, вы можете поместить определенные ресурсы в группы ресурсов и определенные элементы в категории, а затем сделать что-то похожее на приведенное выше, но продублируйте политику ресурсов (для ресурсов) и политику элемента (для элементов).Затем вы создаете записи ACL доступа к группе ресурсов и записи ACL доступа к категории элементов с двумя соответствующими политиками и редактируете политики, снимая отметку с разрешения, как указано выше. Это ограничит то, что пользователи могут делать с конкретными объектами в группе ресурсов или категории элементов.

Вы также можете многое сделать, просто настроив Диспетчер. Вы можете скрыть части формы создания / редактирования ресурса с помощью настройки формы. Скройте части дерева ресурсов, установив параметр пользователя tree_root_id.Полностью скройте дерево элементов и дерево файлов, сняв отметку с разрешений element_tree и file_tree в дублирующейся политике администратора. Вы также можете использовать настраиваемые разрешения, чтобы скрыть различные элементы и подпункты главного меню.

Пользователи с ограниченным доступом, которые могут видеть все документы

Иногда вам нужны пользователи, которые могут видеть все ресурсы в дереве, но имеют ограниченные права в Менеджере. Чтобы ограничить действия пользователей в Менеджере, вам не нужны никакие группы ресурсов. Вам просто нужно назначить им политику в контексте диспетчера, для которой проверено меньшее количество разрешений.

Вот шаги для примера, где вам нужна группа редакторов, которые не являются суперпользователями:

1. Перейдите в Безопасность -> Контроль доступа -> вкладка Роли.
2. Создайте роль Редактор с уровнем полномочий 5.
3. Щелкните вкладку «Шаблоны политики».
4. Дублировать политику администратора; назовите его AdminEditor.
5. Щелкните вкладку Группы пользователей; щелкните правой кнопкой мыши группу пользователей-администраторов и выберите «Обновить группу пользователей».
6. Щелкните вкладку «Контекстный доступ».
7. Щелкните Добавить контекст. Вы создаете запись ACL доступа к контексту; используйте следующие настройки:

• Контекст: mgr
• Минимальная роль: редактор
• Политика доступа: AdminEditor
• Сохранить

Если вам нужно предоставить разные разрешения разным пользователям, создайте новую роль с другим номером полномочий и новой политикой для каждой группы пользователей, которые будут совместно использовать набор разрешений, и повторите шаги, описанные выше, чтобы создать запись ACL доступа к контексту для каждая группа с соответствующей политикой.

Дополнительные советы:

• Помните, что пользователи наследуют разрешения политик в списке доступа к контексту с минимальными ролями, число которых больше, чем у них в группе.
• Не забудьте очистить кеш сайта, очистить все разрешения (и иногда) очистить все сеансы перед тестированием любых изменений.
• Обратите внимание, что удаление разрешений file_tree и element_tree полностью скроет эти деревья.
• Вы можете скрыть определенные телевизоры и поля формы «Создать / редактировать ресурс» с помощью правил настройки формы.
• Вы также можете скрыть определенные пункты меню в верхнем меню с помощью настраиваемых разрешений, но это другой учебник.

Ограничение пользователей Manager подмножеством ресурсов с помощью tree_root_id

Примечание: tree_root_id устарел в MODX 2.2.0 и выше, но я оставил это здесь, потому что часть информации все еще полезна

Иногда требуется группа, которая может видеть только некоторые ресурсы в Менеджере. Если вы доверяете своим пользователям, вы можете создать пользовательский параметр tree_root_id для каждого пользователя. Параметр tree_root_id — это список идентификаторов ресурсов, разделенных запятыми. Пользователь увидит в дереве только эти ресурсы и их дочерние элементы. Это не полностью безопасный вариант, потому что пользователи, которые могут угадать URL-адрес диспетчера ресурса, все равно могут его редактировать.

Для создания пользовательской настройки tree_root_id:

1. Перейдите в Безопасность -> Управление пользователями
2. Щелкните пользователя правой кнопкой мыши и выберите «Обновить пользователя».
3. Выберите вкладку «Настройки»
4. Нажмите кнопку «Создать».
5. Поместите tree_root_id в поле «Ключ»
6. Поместите идентификатор корня дерева в поле «Имя»
7. Поместите список идентификаторов ресурсов, разделенных запятыми, в поле «Значение».
8. Нажмите кнопку «Сохранить»
9. Важно Нажмите кнопку «Сохранить» в правом верхнем углу, чтобы сохранить пользователя.
10. Повторите шаги выше для каждого пользователя
11. Перейдите в Безопасность -> Очистить разрешения

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

Ограничение пользователей Manager подмножеством ресурсов с использованием групп пользователей и ресурсов

Здесь есть руководство по скрытию ресурсов в Менеджере.

Здесь есть руководство по созданию пользовательских страниц (например, ограничение нескольких пользователей их собственными отдельными страницами).

Чтобы действительно ограничить доступ пользователей к ресурсам, вам необходимо использовать группы пользователей и группы ресурсов. Основной процесс состоит в том, чтобы поместить все ресурсы сайта в группу ресурсов и защитить их путем создания записи ACL доступа к группе ресурсов, связывающей эту группу ресурсов с группой пользователей-администраторов.Это защищает ресурсы от всех пользователей, не входящих в эту группу. Затем создайте группу пользователей для ограниченных пользователей и группу ресурсов, содержащую ресурсы, к которым они могут получить доступ, и свяжите их с другой записью ACL доступа к группе ресурсов. Это позволяет этим пользователям видеть эти защищенные ресурсы.

Этот метод работает лучше всего, если пользователи, которых вы хотите ограничить, * не * являются членами группы пользователей-администраторов. Вы можете сделать их членами группы администраторов с более высоким номером доступа, чем тот, который используется для защиты ресурсов, но это ограничит ваши действия с настройкой формы, поскольку правила настройки формы часто основаны на членстве в группе пользователей.

Помните, что для входа в диспетчер и просмотра любых ресурсов в веб-контексте ограниченные пользователи должны иметь запись ACL доступа к контексту как для веб-контекста, так и для контекста диспетчера, как описано ранее на этой странице.

Предположим, вы хотите ограничить членов группы пользователей «Редакторы» определенным набором страниц. Вот как бы вы это сделали.

Создание группы пользователей

1. Создайте роль под названием «Редактор», как описано ранее.
2. Перейдите в Безопасность -> Контроль доступа -> вкладка Группы пользователей
3. Нажмите кнопку «Новая группа пользователей».
4. В поле «Имя» укажите «Редакторы».
5. Нажмите кнопку «Сохранить»
6. Щелкните правой кнопкой мыши группу пользователей «Редакторы» и выберите «Обновить группу пользователей».
7. На вкладке «Пользователи» используйте кнопку «Добавить пользователя в группу», чтобы добавить пользователей.
8. После добавления пользователей нажмите кнопку «Сохранить» в правом верхнем углу.

Защита всех страниц

1. Создайте группу ресурсов с именем AllPages, как описано выше
2. Перетащите все ресурсы из корня в эту группу ресурсов (дочерние элементы будут защищены автоматически)
3. Сохраните группу ресурсов

Создание группы ресурсов редактора

1. Создайте новую группу ресурсов под названием Editor
2. Перетащите только те ресурсы, которые должны видеть редакторы, в группу
3. Сохраните группу ресурсов

Защита всех страниц

1. Перейдите в Безопасность -> Контроль доступа -> вкладка Группы пользователей
2. Щелкните правой кнопкой мыши группу «Администратор» и выберите «Обновить группу пользователей».
3. Щелкните вкладку «Доступ к группе ресурсов»
4. Нажмите кнопку «Добавить группу ресурсов»

• Группа ресурсов: AllPages
• Минимальная роль: администратор, суперпользователь
Политика
• : Ресурс
• Контекст: мгр
• Сохранить

На этом этапе все ресурсы должны быть защищены от пользователей, не являющихся администраторами.Если вы входите в систему как пользователь Editor, вы не должны видеть никаких ресурсов в дереве. Следующим шагом является предоставление редакторам доступа к их ресурсам.

Предоставление редакторам доступа к их ресурсам

1. Перейдите в Безопасность -> Контроль доступа -> вкладка Группы пользователей
2. Щелкните правой кнопкой мыши группу пользователей «Редакторы» и выберите «Обновить группу пользователей».
3. Щелкните вкладку «Доступ к группе ресурсов»
4. Нажмите кнопку «Добавить группу ресурсов»

• Группа ресурсов: Editor
• Минимальная роль: редактор
• Политика: ресурс (или EditorResource, если вы создали эту политику ранее)
• Контекст: мгр
• Сохранить

Если вы войдете в систему как пользователь Editor, теперь вы должны увидеть только ресурсы в группе ресурсов Editor в дереве.Для проверки мы создали группу ресурсов AllDocs и защитили все ее ресурсы, подключив их к группе пользователей-администраторов с помощью записи ACL доступа к группе ресурсов. Затем мы создали группу ресурсов Editor и предоставили редакторам доступ к ее ресурсам, создав запись ACL доступа к группе ресурсов, соединяющую группу ресурсов Editor с группой пользователей Editors.

Есть отличная графика, созданная пользователем MODX lithiumlab, показывающая процесс предоставления группе пользователей доступа к определенному набору ресурсов здесь

Действия менеджера во внешнем интерфейсе

Если у вас нет фрагментов или подключаемых модулей, которые выполняют действия Менеджера при посещении страницы во внешнем интерфейсе, такие как очистка кеша или изменение параметров безопасности, вам не нужно беспокоиться об этом разделе.Большинство обычных сниппетов (например, Wayfinder, BreadCrumbs и большинство пользовательских сниппетов) будут работать нормально. Весь код также будет выполняться, если вы просматриваете страницу из Менеджера как суперпользователь с правами администратора.

Однако помните, что по умолчанию «веб-контекст» защищен записью ACL в группе пользователей «Администратор». Пользователи во внешнем интерфейсе, которые вошли в систему, должны будут получить соответствующие разрешения с помощью ACL доступа к «веб-контексту» для их группы пользователей, чтобы код, выполняющий действия Manager, мог выполняться.Он по-прежнему не будет выполняться для анонимных (не вошедших в систему) пользователей, если вы также не создадите ACL доступа к контексту для анонимной группы пользователей, предоставив им соответствующие разрешения в «веб-контексте».

Несанкционированное или ошибка Страница

Это изменение по сравнению с MODX Evolution. В Revolution, если веб-страница защищена во внешнем интерфейсе, так что ее могут видеть только зарегистрированные пользователи, поведение по умолчанию заключается в том, что анонимные пользователи перенаправляются на страницу с ошибкой (страница не найдена), а не на несанкционированную страницу, когда они попробуйте получить доступ к ресурсу.В Revolution, если у пользователей нет разрешения на «загрузку» ресурса, это как будто его не существует — отсюда и ответ «страница не найдена». Если вы хотите, чтобы они отправлялись на неавторизованную страницу, вы можете сделать следующее:

• Создайте новую запись ACL доступа к группе ресурсов для группы анонимных пользователей с группой ресурсов защищенных ресурсов, контекстом «Интернет», ролью «Участник» и политикой доступа «Только загрузка». Сделайте это для каждой защищенной группы ресурсов
.

Обратите внимание, что это не решит проблему для пользователей, которые вошли в систему во внешнем интерфейсе, но пытаются получить доступ к страницам, на просмотр которых у них нет прав.Чтобы решить эту проблему для этих пользователей, добавьте их в группы пользователей, которым разрешено просматривать страницы, но с ролью «Участник». Затем обновите группы пользователей и добавьте еще одну запись ACL доступа к группе ресурсов для группы с группой ресурсов, установленной на защищенные ресурсы, минимальной ролью «Участник» и политикой «Только загрузка».

Краткое описание

Вот краткое изложение, которое может помочь, если вы все еще не знаете, как использовать Revolution Permissions

1. Первая линия контроля над тем, какие ресурсы пользователи вообще могут видеть в Менеджере, — это привязка групп пользователей к группам ресурсов в записях ACL доступа к группам ресурсов (с контекстом mgr) — точно так же, как в MODX Evolution.Это эквивалент привязки групп документов к группам пользователей-менеджеров в Evolution.
2. Управление тем, что пользователи в группе пользователей могут делать в диспетчере в целом (например, изменять разрешения, редактировать ресурсы, создавать фрагменты и т. Д.), Контролируется проверенными разрешениями в политике, которую они назначают в записи ACL доступа к контексту диспетчера. .
3. Контроль того, что пользователи в группе пользователей могут * использовать ресурсы в группе ресурсов *, контролируется проверенными разрешениями в политике, назначенной для этой группы ресурсов в записи ACL доступа к группе ресурсов, созданной в # 1 (при условии, что Записи ACL доступа к контексту дают им разрешение на выполнение этих действий в диспетчере).
4. Контроль того, что пользователи в группе пользователей могут * с элементами в категории *, контролируется проверенными разрешениями в политике, назначенной для этой категории в записи ACL доступа к категории элементов (при условии, что записи ACL доступа к контексту предоставляют им Разрешение на выполнение этих действий в Менеджере).
5. Пользователи в группе пользователей наследуют разрешения пользователей * в этой группе *, у которых есть роли с более высокими номерами полномочий. Это единственная функция ролей в Revo.

Все еще не понимаете?

Давайте рассмотрим еще одну проблему с точки зрения того, чем вы хотите заниматься, и установим некоторые твердые правила:

1. Скрытие выбранных ресурсов в диспетчере всегда выполняется с записями ACL доступа к группе ресурсов с политикой, которая является некоторым подмножеством политики ресурсов и контекстом mgr .
2. Скрытие выбранных ресурсов во внешнем интерфейсе — всегда выполняется с записями ACL доступа к группе ресурсов с политикой, которая является некоторым подмножеством политики ресурсов и контекстом web .
3. Контроль того, что пользователь может делать * с определенными ресурсами * (например, видеть их, публиковать, удалять и т. Д.) Всегда осуществляется с помощью политики, которая прикреплена к любой из двух записей ACL доступа к группе ресурсов, описанных выше.
4. Скрытие выбранных элементов и контроль того, что пользователи могут с ними делать, точно такие же, как в правилах 1-3, за исключением того, что вы используете записи ACL доступа к категории элементов вместо записей ACL доступа к группе ресурсов.
5. Контроль того, что пользователь может делать в Менеджере в целом (например,g., создавать пользователей, изменять правила безопасности, очищать кеш, редактировать файлы, просматривать дерево элементов и т. д.) всегда выполняется с помощью записи ACL доступа к контексту (фактически присоединенной политики) с контекстом mgr .

После создания соответствующих ролей, пользователей, групп пользователей, групп ресурсов и политик, все шаги, указанные выше, выполняются путем перехода в Безопасность | Контроль доступа | Вкладка «Группа пользователей», щелкнув правой кнопкой мыши группу пользователей и выбрав «Обновить группу пользователей».«

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

Где мой полис?

Когда вы пытаетесь добавить политику в запись ACL, вы увидите только те политики, которые соответствуют типу создаваемой вами записи ACL. Если вы создаете копию политики ресурсов, например, и создаете запись ACL доступа к контексту, вы не увидите свою политику, потому что она там неуместна.Вот как выстраиваются политики:

• Запись ACL доступа к контексту -> Политика администратора
• Запись ACL доступа к группе ресурсов -> Политика ресурсов
• Запись ACL доступа к категории элементов -> Политика элементов

Убедитесь, что вы продублировали правильную политику для типа записи ACL, которую вы собираетесь создать.

Ресурсы по безопасности в Bob’s Guides

Другие страницы безопасности

Здесь находится шпаргалка по системе безопасности MODX Revolution.

Здесь есть руководства по безопасности Revolution.

Официальная документация по безопасности MODX Revolution находится здесь.

Смотрите видео Шона МакКормика о безопасности Revolution (разделено) здесь.

Моя книга, MODX: Официальное руководство — цифровое издание теперь доступно здесь. Бумажная версия книги доступна на Amazon.

Если у вас есть книга и вы хотите загрузить код, вы можете найти его здесь.

Если у вас есть книга и вы хотите видеть страницу обновлений и исправлений, вы можете найти ее здесь.

MODX: Официальное руководство состоит из 772 страниц и выходит далеко за рамки этого веб-сайта в объяснении начальных и продвинутых методов MODX. Он включает подробную информацию о:

• Установка MODX
• Как работает MODX
• Работа с ресурсами и элементами MODX
• Использование Git с MODX
• Использование общих дополнительных компонентов MODX, таких как SPForm, Login, getResources и FormIt
• Разрешения безопасности MODX
• Настройка MODX Manager
• Использование настройки формы
• Создание транспортных пакетов
• Методы объекта MODX и xPDO
• Системные события MODX
• Использование PHP с MODX

Для получения дополнительной информации о книге перейдите сюда.

Спасибо, что посетили BobsGuides.com

Только редактировать ресурсы в MODX | Блог группы разработчиков PMACS по MODX

Редактировать только ресурсы в MODX

Энн Торокио

Когда мы настраиваем сайты MODX для наших клиентов, мы всегда создаем несколько страниц, которые мы хотим, чтобы издатели сайтов никогда не удаляли и не отменяли публикацию. Мы хотим, чтобы эти страницы были «только для редактирования» для издателей, и мы также не хотим, чтобы они дублировали их.Для нас это относится к домашней странице, странице, которая не найдена, странице результатов поиска и специальному ресурсу, который мы используем для конфигураций всего сайта. Да, у нас были издатели, удаляющие домашнюю страницу, даже если мы сказали не делать этого.

К счастью, у нас есть способы защитить пользователей от самих себя; Система разрешений MODX позволяет нам настроить доступ только для редактирования к определенным ресурсам для группы пользователей MODX. Настройка состоит из трех или четырех основных частей.

Первый — создать новую группу ресурсов, которую вы можете назначить своим ресурсам.Группы ресурсов позволяют указать набор разрешений для набора ресурсов. Вот как создать группу ресурсов:

1. Перейдите в Content> Resource Groups в верхнем меню
2. Нажмите кнопку «Создать группу ресурсов», затем введите следующие данные:
   • Имя: Только редактировать или как вам угодно называть свою группу ресурсов
   • Контексты: mgr
   • Автоматически предоставлять доступ к группе администраторов: проверено или нет, в зависимости от вашего варианта использования
   • Нажмите «сохранить»
3. Добавьте любой существующий ресурс, который вы хотите защитить, в новую группу ресурсов, вы можете сделать это либо
   • На странице диспетчера групп ресурсов ИЛИ
   • В «Группы ресурсов» при редактировании ресурса

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

1. Перейдите на вкладку «Политики доступа» (значок шестеренки> Списки контроля доступа> вкладка «Шаблоны политик»).
2. Нажмите кнопку «Создать политику доступа», заполните всплывающую форму:
   1. Имя: Только редактировать
   Шаблон политики
   2. : ResourceTemplate
   3. Описание: Разрешение только на редактирование для ресурсов.
   4. Нажмите «Сохранить»
3. Щелкните правой кнопкой мыши, чтобы обновить новую политику
4. Убедитесь, что включены только те разрешения, которые вы хотите предоставить, например:
5. Нажмите «Сохранить», затем «Закрыть».

Вы можете захотеть, чтобы ваша политика доступа управляла разрешениями, которые не контролируются политиками доступа MODX по умолчанию.Для этого нам нужно отредактировать шаблон политики ResourceTemplate и добавить в шаблон разрешение resource_duplicate. Идея шаблонов политик может немного сбивать с толку. Сами по себе шаблоны политик не предоставляют и не запрещают разрешения, но шаблон позволяет политике, использующей этот шаблон, управлять всеми разрешениями, назначенными используемому шаблону политики. Если вы знакомы с шаблонами MODX и шаблонными переменными (TV), это похоже на предоставление доступа к шаблону для шаблона телевизору.В этом случае разрешение для политики доступа похоже на переменную шаблона для ресурса.

Редактировать шаблон политики доступа

1. Перейдите к значку Cog> Списки контроля доступа> вкладка Шаблоны политик
2. Щелкните правой кнопкой мыши и обновите ResourceTemplate
3. Нажмите кнопку «Добавить разрешение к шаблону»
4. Выберите «resource_duplicate» из раскрывающегося списка, помните, что вы можете ввести для поиска в списке
5. Нажмите «Добавить»
6. Нажмите «Сохранить», затем «Закрыть».

Наконец, мы назначаем новую политику доступа группе пользователей.У нас есть существующая группа издателей, которой мы хотим назначить эту политику. Если у вас нет такой группы, см. «Создание группы пользователей издателя в MODX», чтобы узнать, как создать такую ​​группу.

1. Перейдите на вкладку «Группы пользователей и пользователи» (значок шестеренки> Списки контроля доступа> вкладка «Группы пользователей и пользователи»).
2. Щелкните правой кнопкой мыши группу, которую вы хотите ограничить, и выберите «Обновить группу пользователей».
3. Перейдите на вкладку «Разрешения»> вложенная вкладка «Доступ к группе ресурсов»
4. Нажмите кнопку «Добавить группу ресурсов», заполните всплывающую форму:
   • Группа ресурсов: только редактировать
   • Контекст: мгр
   • Минимальная роль: суперпользователь — 0
   Политика доступа
   • : только редактировать
   • Нажмите «Сохранить»
5. Сохранить и закрыть

На этом этапе вы закончили настройку новой политики доступа и можете добавлять пользователей в свою группу издателей, и у них будет только ограниченный доступ для изменения ресурсов в новой группе ресурсов «Только редактирование».Мы рекомендуем протестировать это с тестовым пользователем и протестировать контент. Нам пришлось поэкспериментировать и настроить разрешения, чтобы получить наиболее подходящую для нас настройку.

Если вам нужна дополнительная информация о различных аспектах разрешений в MODX Revolution, см. Подробный урок в Руководстве Боба по разрешениям Revolution.

Свяжитесь с нами

PMACS Web Team
Penn Medicine Academic Computing Services Web Team
Перельмана медицинский факультет
Пенсильванский университет

Электронная почта

Быстрые ссылки