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

Настройка прав доступа для контент-менеджера в MODX Revolution

Всем привет! Сегодня мы рассмотрим настройку и разграничение прав в MODx Revolution. Создадим нового пользователя manager, ограничим его как следует и назначим соответствующие права на редактирование ресурсов и файлов.

Поделиться

Твитнуть

Поделиться

Класснуть

Запинить

Полный алгоритм действий по настройке прав контент менеджера MODx

1. Создание нового пользователя и назначение прав

• Переходим в меню: «Настройки» > «Контроль доступа»
• Переходим на вкладку «Политики доступа»
• Копируем «Content Editor», редактируем и называем новую политику «Менеджер»
• Устанавливаем разрешения:
  • Установить галку «Изменять права доступа (chmod) к каталогам»
  • Установить галку «Создавать каталоги в файловой системе»
  • Установить галку «Получать список подкаталогов для каталога в файловой системе»
  • Установить галку «Переименовывать каталоги в файловой системе»
  • Установить галку «Создавать файлы»
  • Установить галку «Смотреть список файлов в определенном каталоге»
  • Установить галку «Использовать диспетчер файлов»
  • Установить галку «Удалять файлы»
  • Установить галку «Видеть дерево файлов в левой навигационной панели»
  • Установить галку «Изменять файлы»
  • Установить галку «Загружать файлы в папку»
  • Установить галку «Просматривать содержимое файла»
  • Установить галку «Использовать пакеты в системе управления пакетами»
  • Установить галку «Использовать страницу «Поиск»»
  • Сохранить.
• Переходим в меню: «Настройки» > «Контроль доступа»
• Переходим на вкладку: «Группы пользователей & Пользователи»
• Создаем новую группу пользователей и задаем имя «Контент менеджеры»
• Устанавливаем в окне новой группы пользователей контексты web, mgr
• Политика бэкэнда в окне новой группы: «Менеджер» + Сохранить
• Новая группа пользователей «Контент менеджеры» > Редактировать
• Переходим на вкладку: «Права доступа»
• На вкладке «Доступ к контекстам» редактируем mgr, web по очереди
• mgr, web > редактировать, устанавливаем «Политика доступа» как «Менеджер» + Сохранить
• Переходим в меню «Управление» > «Пользователи» и создаем нового пользователя по кнопке «Новый пользователь»
• Имя manager, указываем E-mail менеджера, устанавливам радиобаттон ниже как «Я укажу пароль сам» и задаем пароль
• Переходим на вкладку «Права доступа» > «Добавить пользователя в группу»
• Группа пользователей: «Контент Менеджеры», Роль: «Super User»
• Установить чекбокс «Активный» + Сохранить
• Переходим в меню «Управление» > «Перезагрузить права доступа»

2. Ограничения на просмотр файловой системы

2.1. Добавляем источник файлов

• Переходим в меню: «Медиа» > «Источники файлов»
• Скопируем «Filesystem»
• Отредактируем скопированный источник
• Название: «Images»; basePath, baseUrl: «assets/images/»
• Переходим в меню: «Настройки» > «Контроль доступа»
• Отредактируем группу пользователей «Контент менеджеры» правой кнопкой мыши
• Переходим на вкладку: «Права доступа» > «Доступ к источнику файлов» и добавим новый источник по кнопке «Добавить источник файлов»
• Источник: Images, Минимальная роль: Member — 9999, Политика доступа: Media Source Admin
• Сохранить; Меню: «Управление» > «Очистить кэш»; Меню: «Управление» > «Перезагрузить права доступа»

2.2. Удаляем источник «Filesystem» для manager

• Переходим в меню: «Медиа» > «Источники файлов»
• Filesystem > Редактировать
• Переходим на вкладку: «Права доступа», нажимаем «Добавить группу пользователей»
• Группа пользователей: «Administrator», Минимальная роль: «Super User — 0», Политика: «Media Source Admin» + Сохранить
• Переходим в меню: «Медиа» > «Источники файлов»
• Images > Редактировать
• Переходим на вкладку: «Права доступа», нажимаем «Добавить группу пользователей»
• Группа пользователей: «Administrator», Минимальная роль: «Super User — 0», Политика: «Media Source Admin» + Сохранить

3. Управление группами ресурсов

• Переходим в меню: «Содержимое» > «Группы ресурсов»
• Создать группу ресурсов
• Имя: «Администратор», Контексты: «web,mgr»
• Установить галку «Автоматически дать доступ группе Administrator»
• Добавить элементы в новую группу «Администратор», которые мы хотим скрыть от менеджера
• Сохранить; Меню: «Управление» > «Очистить кэш»; Меню: «Управление» > «Перезагрузить права доступа»

Премиум уроки от WebDesign Master

Другие уроки по теме «MODx»

[AdminTools] Права доступа | Зона разработки

Настройка прав доступа в MODX — занятие очень не простое и требующее время для познания. С наскока управиться с ними не получится. И если нужно настроить админку для разных групп пользователей, то деваться не куда — придётся сесть и разобраться с ними. Но когда нужно просто ограничить доступ к ресурсам на сайте, то можно обойтись упрощённым механизмом прав доступа из библиотеки AdminTools.

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

Принцип работы

Чтобы заработал этот упрощённый механизм прав доступа, нужно включить системную настройку admintools_alternative_permisions. После этого у ресурса будет доступна вкладка «Права доступа». Если права не указаны, то ресурс доступен всем без ограничений. Как только добавили права, начинает работать проверка.

Чтобы добавить запись, нажимаем кнопку + Добавить и выбираем нужную строчку в списке «Группа/пользователь».

В списке можно выбрать следующие пункты:

• Все
• Гости
• Группы пользователей
• Пользователи

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

Проверка прав идет последовательно в порядке создания записей. Если указано несколько групп, то права пользователя будут такие, какие указаны для последней группы. Но если у первой группы указать приоритет выше остальных групп, то её права будут выше. Это может пригодится, например, если пользователям группы «Администратор» разрешить доступ, а другой группе, добавленной позже, запретить. Тогда, если пользователь входит в обе группы, а у группы «Администратор» приоритет выше, то доступ для пользователя будет открыт. Это что касается приоритета групп. А ещё есть приоритет (вес) записей.

У записи «Все» наименьший приоритет. У пользователя — максимальный приоритет. Т.е. если группе пользователей дан доступ к ресурсу, а пользователю, входящему в данную группу — нет, то для него этот ресурс будет недоступен и он будет перенаправлен на страницу, указанную в системной настройке unauthorized_page.

Для доступа к странице необязательно добавлять права для всех. Т.е. если вы хотите ограничить доступ к странице сайта только для анонимов (гостей), то достаточно добавить запись «Гости» и указать действие «Запрещено». Но вот если вдруг вам захочется ограничить доступ для авторизованных пользователей, то тогда запись «Все» очень пригодится — нужно запретить для нее доступ, а гостям доступ разрешить.

Пример

Чтобы закрыть страницу от неавторизованных пользователей, достаточно добавить запись «Гости» и запретить доступ. Всего одно действие! И сравните с обычной настройкой MODX. Чувствуете разницу?

В общем, пробуйте. Компонент доступен в официальном репозитории modx.com.

24 августа 2016, 16:12

0

 
3744

Разрешения — Политики | 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

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

Роли и группы пользователей

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

Для управления группами пользователей нужно нажать левой кнопкой мыши на шестерёнку в правом верхнем углу панели управления. В открывшемся меню кликаем на «Контроль доступа».

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

Управление политикой привилегий

В меню «Контроль доступа» есть вкладка «Шаблоны политик доступа». Здесь можно добавлять новые шаблоны, редактировать имеющиеся. Затем на их базе создаются политики. Для редактирования нужно нажать на шаблон правой кнопкой, затем на строку «Редактировать шаблон политики доступа». Здесь можно добавлять и удалять разрешения.

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

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

Для создания новой политики нужно нажать кнопку «Создать политику доступа». Здесь нужно ввести название, выбрать шаблон и написать краткое описание. Затем надо нажать кнопку «Сохранить». Новую политику нужно нажать для редактирования, чтобы выбрать, какие разрешения из шаблона в ней будут доступны.

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

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

Автор Алексей На чтение 4 мин Просмотров 2.4к. Опубликовано 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).

Настройка политики доступов в MODX Revolution

Опубликовано: 26 Февраля 2019

В MODX Revolution очень гибкая настройка прав доступов, а потому и не сильно понятная для новичков.

Настройка доступов может состоять из:

• настройки групп пользователей;
• настройки политики доступа;
• настройки шаблона политики доступа;
• ролей;
• настройки групп страниц;
• настройки пользователей;
• настройки доступа к источнику файлов.

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

Группа пользователей (user groups)

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

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

• Имя (name) — название группы
• Контексты — контексты сайта, доступные для группы (обычно web и mgr)
• Политика панели управления — политика доступа для группы

Остальные поля заполняются по необходимости.

Политики доступа (access policy)

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

Предустановленные политики доступа:

• Administrator — полный доступ к администрированию контекста.
• Content Editor — ограниченный доступ к администрированию контекста, без права публикации.
• Context — стандартная контекстная политика, которую можно применять при создании доступа для чтения / записи, и просмотра неопублекованного в контектсе. 
• Element — любые действия с элементами (объектами категории элементы). 
• Hidden Namespace —  не будет отображать пространство имен в списках.
• Load Only — минимальная политика с разрешением на загрузку объекта.
• Load, List and View — предоставляет только загрузку, список и просмотр.
• Media Source Admin — администрирование источников файлов.
• Media Source User — использование источников файлов, с базовым просмотром и использованием, но без редактирования 
• Object — политика полного доступа к объектам.
• Resource — политика полного доступа к ресурсам.

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

Шаблоны политик доступа (policy templates)

Шаблон политик доступа — группирует привилегии, чтобы с ними было удобно работать в панели администрирования.

В MODX есть множество различных привилегий, некоторые из них логически связаны, например:

• создание страницы
• редактирование страницы
• сохранение страницы

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

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

Роли (roles)

Роли позволяют ограничивать привилегии пользователя внутри группы. Каждая роль имеет ранг: чем меньше числовое значение ранга, тем больше доверия соответствует этой роли. Когда пользователь добавляется в группу, ему назначается определённая роль. Если ранг роли равен нулю (Super User), пользователю оказывается максимально возможное для этой группы доверие, он получает доступ ко всем привилегиям группы. 

По умолчанию созданы 2 роли:

• Member — 9999.
• Super User — 0.

Для простейшего использования механизма роли можно всем участникам группы назначать роль Super User.

Более сложный механизм использования ролей становиться необходим если определенным участникам группы надо немного более расширить функционал. Например, если есть политика доступа «Контент-менеджер», в которой участники делятся на контент-менеджеров, и главных редакторов. Оба типа участников должны обладать способностью создания и редактирования ресурсов, но главному редактору можно предоставить право удалять ресурсы. Это можно сделать путем создания новой группы пользователей с дополнительной ролью, но данный ход потребует дублирования действий. Ту же самую задачу можно решить дав контент-менеджерам роль Member, а главным редакторам роль Super User, и для роли Super User предоставить дополнительную привилегию.

Группы страниц (resource groups)

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

Управлять доступом можно на уровне следующих объектов:

• контексты,
• группы страниц,
• категории элементов,
• медиа источники (media source).

Пользователи (users)

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

Источники файлов (media source)

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

Создать новый источник можно в меню Медиа (Media) → Источники файлов (Media Sources).

Общая схема

Учитывая информацию приведенную выше, алгоритм настройки доступа в MODX можно представить так:

1. выделить объекты, доступ к которым необходимо предоставить;
2. если доступом к данным объектам нельзя управлять напрямую (например, это страница или чанк), создать группу страниц или категорию элементов и добавить туда интересующий объект;
3. создать пользователя;
4. создать группу, которая будет носителем прав доступа к интересующим объектам, и добавить пользователя в эту группу;
5. создать политику доступа с набором привилегий, которые необходимо предоставить;
6. присвоить политику доступа группе пользователей.

Примеры

Настройка доступа для аккаунта модератора сайта:

1. В системных настройках выбираем «Контроль доступа» (Access Control List).
2. На вкладке «политики доступа» (access policy) создаем новую политику с именем Moderator, при необходимости выбираем для нее шаблон.
3. Устанавливаем необходимые привилегии.
4. Возвращаемся на вкладку Группы пользователей, пользователи и создаем новую группу, с именем Moderator.
5. В появившемся окне создания группы устанавливаем контексты web, mgr, и политику доступа Moderator. Сохраняем.
6. Кликаем по созданной группе правой кнопкой мыши, жмем редактировать, перепроверяем что все установлено верно.
7. В меню «Управление» (Manage) создаем нового пользователя. Указываем имя, email, и при желании устанавливаем пароль сами.
8. На вкладке «Права доступа» устанавливаем группу в которой будет числиться пользователь. Даем ему роль Super User.
9. Устанавливаем чекбокс «Активный» и сохраняем.
10. В меню «Управление» (Manage) перезагружаем права доступа.

Ограничение на просмотр файловой системы:

1. Добавляем новый либо копируем старый источник файлов в меню Медиа (Media) → Источники файлов (Media Sources);
2. Указываем название: «Upload»; basePath, baseUrl: «assets/upload/»;
3. Переходим в системных настройках идем в «Контроль доступа» (Access Control List);
4. Правой кнопкой мыши жмем на группу пользователей и выбираем отредактировать;
5. На вкладке «права доступа» жмем на «доступ к источнику файлов»;
6. Выбираем созданный источник файлов. Указываем минимальную роль, например: Member — 9999 и политику доступа, например: Media Source Admin. Сохраняем;
7. Далее в меню «Управление» (Manage) выбираем «очистить кеш», затем «Перезагрузить права доступа»

Ограничиваем доступ к источнику файлов «Filesystem» для всех кроме администраторов:

1. Идем в меню Медиа (Media) → Источники файлов (Media Sources);
2. Правым кликом мыши выбираем «редактировать источник»;
3. На вкладке: «Права доступа», нажимаем «Добавить группу пользователей».
4. Выбираем группу «Administrator», ставим минимальную роль: «Super User — 0», Политику: «Media Source Admin». Сохраняем.
5. Если в системе присутствуют другие источники файлов, им придется отдельно, тем же путем, проставить права доступа для каждой группы.

Управление группами ресурсов:

1. Переходим в меню: «Содержимое» (Content) → «Группы ресурсов» (Resource Groups);
2. Создаем группу ресурсов, называем «Administrator», указываем контексты web,mgr, ставим галку «Автоматически дать доступ группе Administrator»;
3. Добавляем элементы которые должны быть скрыты от менеджера в новую группу «Администратор», сохраняем;
4. В меню «Управление» (Manage) выбираем «очистить кеш», затем «Перезагрузить права доступа».

Права доступа к ресурсам…. ? / Вопросы / MODX.im

1 — создал политику «manager» доступа на базе шаблона AdministratorTemplate
2 — создал роль «manager» с рангом 9
3 — создал группу пользователей «manager»
4 — создал пользователя «demo»
5 — создал 2 группы ресурсов «Администратор» и «Редакторы» (ресурсы указал)

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

Пользователи — «demo» роль «Manager — 9»

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

контекст -web

минимальная роль — Manager — 9

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

контекст -mgr

минимальная роль — Manager — 9

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

Доступ к ресурсам

Группа ресурсов — Администратор

минимальная роль — Super User — 0

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

Контекст — mgr

Группа ресурсов — Редакторы

минимальная роль — Manager — 9

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

Контекст — web

Группа ресурсов — Редакторы

минимальная роль — Manager — 9

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

Контекст — mgr

Доступ к источникам

Кэшированный код ресурса — manager

Минимальная роль — Manager — 9

политика доступа — Media Source Admin

Источники файлов все указал…

Под новым пользователем захожу вижу ту группу ресурсов которую указал, остальное скрыто. Вижу ресурс (контейнер) «Новости» в котором расположены другие ресурсы (сами новости).

ВОПРОС: В WEB могу создать ресурс, а в ресурсе (контейнере) «Новости» создать дочерный документ (новость) не дает, выдает «У вас нет прав на создание ресурса здесь.» ?

Также нельзя перенести ресурс из WEB в контейнер «новости», хотя из него контейнера «новости» можно перенести ресурс в WEB. Править ресурсы которые находятся в контейнере «новости» можно, все сохраняет.

——————————РЕШЕНО——————————

Доступ к ресурсам

Группа ресурсов — Редакторы

минимальная роль — Manager — 9

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

Контекст — web

Группа ресурсов — Редакторы

минимальная роль — Manager — 9

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

Контекст — mgr

Разрешения в выбранной политике

add_children, create, copy, delete, list, load, move, publish, remove, save, steal_lock, undelete, unpublish, view

разрешений — Политики | Документация 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 группы ресурсов.

Примером может быть назначение политики «Ресурс» группе ресурсов под названием «Кадровые документы». Затем вы должны предоставить группе пользователей под названием «Отдел кадров» доступ к этой группе ресурсов через 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 доступа к «веб-контексту» для их группы пользователей, чтобы код, выполняющий действия диспетчера, мог выполняться.Он по-прежнему не будет выполняться для анонимных (не вошедших в систему) пользователей, если вы также не создадите 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

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

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

по

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

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

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

Есть два шага для настройки такой роли пользователя. Первым шагом является создание политики доступа для роли. Второй шаг — создание группы пользователей и назначение ей политики.

Создание политики доступа «Издатель»

Узнайте, как редактировать, дублировать и создавать политики доступа, в официальной документации MODX. Дублируйте одну из политик доступа, поставляемых с MODX, вместо того, чтобы редактировать одно из значений по умолчанию; согласно подробному сообщению Боба Рэя на MODX Revolution Permissions:

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

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

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

• новый_документ_в_root
• view_unpublished
• различные разрешения file_ *, если вы хотите, чтобы издатели могли добавлять файлы, такие как изображения

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

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

1. Перейдите на вкладку «Группы пользователей и пользователи» (значок шестеренки> Списки контроля доступа> вкладка «Группы пользователей и пользователи»).
2. Нажмите кнопку «Новая группа пользователей».
3. Назовите свою группу «Издатель» или как хотите.
4. При желании добавить описание
5. Контексты: введите «mgr»

Политика менеджера

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

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

      • : выберите созданную вами политику издателя.
      • Сохранить
   3. Повторите вышеуказанный шаг для веб-контекста и / или любых других, если необходимо.

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

1. Перейдите в список пользователей в диспетчере MODX (Управление> Пользователи)
2. Нажмите «Новый пользователь»
3. Заполните обязательные поля и обязательно отметьте «Активно», нажмите «Сохранить»
4. Запишите пароль
5. Нажмите «Закрыть», чтобы вернуться к списку пользователей.
6. Перейти к спискам контроля доступа (Cog> Списки контроля доступа)
7. Щелкните правой кнопкой мыши группу «Издатель» и выберите «Добавить пользователя в группу».
8. Выберите своего тестового пользователя и роль «Суперпользователь»
9. Войдите в систему как тестовый пользователь и начинайте тестирование!

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

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

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

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

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

© Попечители Пенсильванского университета
Лучше всего просматривать сайт
поддерживаемый браузер.
Сообщить о проблемах доступности и получить помощь
Политика конфиденциальности
Дизайн сайта: веб-команда DART.
Фоновое изображение: D Шарон Прюитт
.