Modx manager: MODX Extras | Asset Manager 1.3.1-pl

Сброс пароля от панели администратора MODX – Beget

У CMS Modx есть 2 основные версии:

• Modx Evolution версии 1.*.*
• Modx Revo версии 2.*.*

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

Как узнать имя базы?

Узнать имя базы, с которой работает сайт, и префикс таблиц можно в конфигурационном файле сайта.
Для Modx Evolution 1.*.* он находится по следующему пути от корня сайта:

./manager/includes/config.inc.php

А для версии Modx Revo 2.*.*его следует искать по следующему пути от корня сайта:

./core/config/config.inc.php

Корень сайта можно узнать в разделе Сайты:

На скриншоте можно наблюдать, что в нашем случае корнем сайта является modx/public_html, и, соответственно, файл будет находиться по следующим путям для версии Modx Evolution 1. *.* и Modx Revolution 2.*.* соответственно:

modx/public_html/manager/includes/config.inc.php

и

modx/public_html/core/config/config.inc.php 

Теперь нам нужно открыть нужный файл любым удобным способом, например, через Файловый менеджер, и найти в нём следующие строки:

$dbase = 'passreset_modx1';
$table_prefix = 'modx_';

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

Редактирование базы данных

После того, как мы узнали имя базы, нам нужно попасть в саму базу данных. Сделать это можно через phpMyAdmin в разделе MySQL. Находим нужную базу данных в списке и напротив неё нажимаем иконку PMA. Возможно, сразу phpMyAdmin не откроется, так как Ваш браузер блокирует всплывающие окна, поэтому разрешите использование всплывающих окон.

Дальнейшие действия для каждой из версий разные, поэтому далее мы рассмотрим процесс отдельно для MODX Evolution и MODX Revo.

Modx Evolution 1.*.*

Перед нами база данных, с которой работает наш сайт. Нам нужно найти таблицу с пользователями нашего сайта. Её название имеет следующий вид – Префикс_manager_users. В нашем случае она называется modx_manager_users. Найдём её в списке и нажмём на неё:

Перед нами появилась информация из таблицы modx_manager_users, в которой указана информация о всех зарегистрированных пользователях вашего сайта. Вам нужно найти строку с логином Вашей учётной записи, в нашем случае это учётная запись admin. Теперь откроем эту строку для редактирования, нажав на иконку с карандашом в левой части строки:

Теперь приступим к самой смене пароля. Для этого находим строку с названием password:

И поменяем в ней 2 строки: в поле Значение удаляем все текущие символы и вводим туда желаемый пароль, например BegetNewPass, а в поле Функция выбираем из списка MD5.

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

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

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

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

Modx Revo 2.*.*

Перед нами база данных, с которой работает наш сайт. Нам нужно найти таблицу с пользователями нашего сайта. Её название имеет следующий вид – Префикс_users. В нашем случае она называется modx_users. Найдём её в списке и нажмём на неё:

Перед нами появилась информация из таблицы modx_users, в которой указана информация о всех зарегистрированных пользователях вашего сайта. Вам нужно найти строку с логином Вашей учётной записи, в нашем случае это учётная запись admin. Теперь откроем эту строку для редактирования, нажав на иконку с карандашом в левой части строки:

Теперь приступим к самой смене пароля. Для этого находим строку с названием password:

И поменяем в ней 2 строки: в поле Значение удаляем все текущие символы и вводим туда желаемый пароль, например BegetNewPass, а в поле Функция выбираем из списка MD5.

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

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

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

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

Инструкция к CMS Evolution (MODx)

Обращение к читателям статьи

Изначально мы написали эту статью в помощь клиентам нашей студии. Но спустя время эту страницу стали посещать тысячи пользователей со всей России, которые искали информацию по этой замечательной CMS. Мы разрабатываем сайты на этой системе управления уже много лет, поэтому, если вас интересует поддержка или доработка вашего сайта, вы можете смело обращаться по электронной почте [email protected]!

Вход в систему управления сайтом

Для входа в систему управления сайтом необходимо к адресу вашего сайта добавить /manager. Итоговый адрес будет site.ru/manager

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

Словарь терминов

Чтобы общаться с вами «на одном языке», приведём несколько понятий, которые пригодятся:

«Система управления сайтом», она же «CMS (Content Management System)», она же «админка».
Это та «оболочка», через которую вы осуществляете всю работу с сайтом – наполнение, управление и так далее. На скриншоте ниже вы можете увидеть её внешний вид

Бэкенд («бэк»), фронтенд («фронт»)
Как понятно из названия, это «задник» и «передник» сайта. Бэком называется то, что вы видите в админке. Фронтом – то, что на реально действующем сайте.

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

Ресурс
Любая из страниц сайта. Это может быть главная, страница, статья, услуга, товар, страница контактов — что угодно. Всё, что вы видите на сайте — это ресурсы.

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

ID (айди) ресурса
Цифра, написанная справа от ресурса в дереве. Нужна, в основном, чтобы избежать путаницы при общении по какому-то вопросу. Например, может быть одновременно два ресурса с одинаковым названием (например, два врача-однофамильца). Чтобы проще объяснить кому-тО, какой ресурс смотреть, можно назвать его порядковый номер, то есть, айди.

Шаблон
Визуальная структура ресурса. От шаблона зависит, как будет отображаться та или иная страница. Любой ресурс можно сделать любым шаблоном. Например, любой услуге можно присвоить шаблон «Контакты» и на ней ожидаемо появится карта. Именно этот фактор является огромным преимуществом этой CMS. Любой ресурс может выступать в роли любой страницы при условии смены всего лишь его шаблона.

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

«TV-параметр» (ТВ-параметр)
Поле с неким параметром сайта. Это может быть ввод картинки, какого-то названия, текста, заголовка – по-русски это называлось бы просто «параметром», но в рамках работы с этой CMS, чтобы не было путаницы, ввели понятие «TV-параметр». Самый простой пример – это ввод номера телефона, который отображается в шапке сайта. Поле ввода и будет называться TV-параметром. Пример ТВ-Параметров ниже на скриншоте.

«Мульти-TV»
Аналогично предыдущему термину, это просто параметр ресурса. Однако, название явно показывает, что у него есть возможность ввода множества данных, объединённых одним TV-параметром. Например, если у компании несколько телефонов, то плодить множество TV-параметров неудобно (т.к. телефоны могут появляться хоть по 5 штук в день). В таком случае используется Мульти-ТВ. Пример внешнего вида мульти-ТВ находится ниже на скриншоте. Зелёным плюсом и красным минусом мы можем регулировать количество ТВ-параметров внутри одного мульти-ТВ

DocPicker (ДокПикер)
Используется нечасто и не факт, что у вас он будет, но инструкция общая для всех, поэтому нужно его упомянуть. Используется для логической связи ресурсов между собой. Например, одна из частых задач – конкретному филиалу компании присвоить нужных сотрудников. Для этого в строке пишутся номера ID ресурсов. На скриншоте ниже показано, что сотрудник относится именно к филиалу на Московской, д. 123.

Табы
«Закладки» внутри админки, на которых расположены ТВ-параметры. Расположены в самом верху окна редактирования ресурса.

Файловый менеджер
Используется для загрузки файлов и изображений на сайт. Вызывается кликом по кнопке «Вставить» в ТВ-параметре.

Представляет собой стандартный проводник с обычными файлами и папками. То, что вы видите в нём – это файлы, расположенные на хостинге (а не на вашем ПК). Для того, чтобы загрузить файл, необходимо нажать зелёную кнопку «Загрузить» и выбрать необходимый файл на вашем ПК. Рекомендуем создавать папки в левом дереве файлов, а не грузить всё в одну, чтобы потом вам самим было проще найти нужный файл.

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

Для начала вернёмся к объяснению, которое мы 100% рассказывали вам на встрече, просто вы забыли. Любая страница состоит из неких визуальных блоков. Если бы статья содержала в себе только текст, то было бы прекрасно, и никакой ПейджБилдер нам не потребовался бы. Однако, зачастую, статья может содержать в себе: текст, галерею, слайдер, отзывы, преимущества, что угодно. Все эти блоки имеют свой html-код, свою вёрстку. И без знаний этого кода вы просто-напросто не сможете скомпоновать порядок блоков на странице так, как вам нужно.

Рассмотрим на примере. Ниже будет скриншот страницы услуги Стоматологии.

Явно видно, что на картинке шесть разных визуальных блоков. Но ведь очевидно, что прайс-лист на какой-то услуге может быть, а на какой-то – нет. На какой-то услуге может быть блок с круглыми картинками, а какая-то услуга – это всего лишь один абзац текста, т. к. про неё больше нечего писать. Именно для этого и нужен ПейджБилдер. Он позволяет без знания кода формировать порядок блоков на странице. Фактически, ПейджБилдер – это всего лишь чуть более навороченный МультиТВ.

Теперь посмотрим, как выглядит этот же сайт в разрезе ПейджБилдера в админке.

По принципу МультиТВ мы можем добавить в любом порядке блок с определённой визуальной структурой и наполнением. Эти блоки можно менять местами, можно добавлять несколько одинаковых блоков и так далее.

Вот именно понять, как выбрать наиболее привлекательный блок для какого-то наполнения – это и есть основная проблема (даже не проблема, а сложность) в наполнении сайта.

Рассмотрим на примере. Один и тот же текст можно вверстать в сайт по разному, ниже три примера:

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

Работа с деревом ресурсов

Работа с деревом ресурсов очень простая. Давайте прям пошагово:

• Первое, что нужно знать – изначально, все ресурсы и их подресурсы свёрнуты. Чтобы посмотреть, какие дочерники содержит в себе ресурс, необходимо нажать на стрелочку слева:

• Зажав ЛКМ, можно перетаскивать ресурсы вверх-вниз, это будет влиять на порядок отображения на фронте.

• По ресурсу можно кликнуть левой кнопкой мыши (далее просто «ЛКМ») или правой кнопкой мыши (далее ПКМ).

  ЛКМ откроет окно редактирования конкретного ресурса в правой области админки.

  ПКМ откроет контекстное меню редактирования ресурса, остановимся на нём.

По порядку по скриншоту:

• Дочерний ресурс. Создаст дочерний ресурс выбранного ресурса. Используется для добавления статей, услуг и так далее.
• Редактировать. Действие, аналогичное ЛКМ.
• Переместить. Позволяет перемещать созданный ресурс (например, если вы создали его не в том ресурса)
• Сделать копию. Создаёт полную копию выбранного ресурса (включая заполненные ТВ-параметры)
• Отменить публикацию. Меняет статус публикации ресурса.
• Удалить. Действие аналогично удалению файла в Windows. То есть, сначала ресурс просто зачёркивается, и только после нажатия на иконку корзины сверху, он удаляется. Это очень удобно и защищает от случайного удаления ресурса.
• Дочерняя веб-ссылка. Как правило, не используется.
• Обзор ресурса. Как правило, не используется.
• Просмотр ресурса. Открывает страницу сайта для просмотра.

Работа с окном редактирования ресурса

Работа с окном редактирования ресурса довольно простая. Давайте по порядку, сверху-внизу. Ниже – скриншот-пример:

Всегда обращаем внимание на табы. Есть три стандартных таба, которые есть у каждого ресурса: Общие, Настройки страницы, SEO.

У каждого ресурса есть стандартные поля:

• Заголовок. Это – название страницы. Как правило, используется на фронте в качестве заголовка.
• Псевдоним. Это адрес страницы на фронте. Например, site.ru/adres-stranicy. В данном случае, adres-stranicy является псевдонимом. Его трогать не нужно, он формируется автоматически на основе заголовка по правилам транслитерации.
• Шаблон. Как правило, шаблон выбирается автоматически при создании ресурса (на основе «соседних» ресурсов). Но если вы видите, что вы наполнили всё верно, а на фронте какая-то ерунда, то в первую очередь проверьте шаблон и сверьтесь с ресурсом, который работает корректно.
• Позиция в меню. Порядковый номер вывода ресурса на фронте.

Табы SEO и «Настройка страницы», как правило, заказчиками не используется. Если же вам это нужно, то, скорее всего, вам эта инструкция уже бесполезна 🙂

Работа с редактором контента

Работа с редактором текста не сложнее работы в Microsoft Office.

На картинке дали пояснения к основным кнопкам.

Самые частые вопросы по использованию редактора контента:

• Как изменить шрифт текста, размер, интервалы? Делать этого не нужно! Над вашим сайтом работал профессиональный дизайнер, который подобрал именно тот шрифт, именно тот размер, именно то выравнивание, которое идеально подходит для тех или иных целей. Ваша задача – просто вставить текст, не более.
• Текст на фронте выглядит «слипшемся, без абзацев». Частая проблема, когда вы копируете текст с какого-то чужого сайта. Вам в некоторых случаях необходимо вставлять абзацы самостоятельно (просто нажав Enter на нужном участке текста). Ниже пример «слипшегося текста» и текста, как он должен выглядеть в админке, чтоб был красивый на фронте:

Что важно понимать?

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

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

Подведем итоги

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

Настройка админ панели клиента Modx Revo

В Evolution все было достаточно просто: создаешь права пользователю и готово! А здесь нужно проделать достаточно много шагов, но сдругой стороны — в Modx Revolution с правами на документы и файлы можно делать все, что угодно (если конечно разбираться в этом). Ну что ж, начнем!

1. Переходим в «Безопасность» — «Контроль доступа» в верхнем меню админ-панели

2. Заходим во вкладку «Политика доступа»

3. Нажимаем на кнопку «Создать политику доступа»

У нас откроется окно с полями. В поле Имя пишем «manager», шаблон политики доступа — AdministratorTemplate. Жмем кнопку сохранить

4. После сохранения политики доступа «manager» мы видим, что она появилась у нас в списке политик доступа

5.

6. Убираем галочки ненужных параметров

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

Убираем галочки со следующих параметров:

• access_permissions     Вывод страницы с настройками прав доступов пользователей
• dashboards          Просмотр и управление панелями
• element_tree          Возможность просмотра дерева элементов в левой навигационной панели
• menu_reports          Показывать в верхнем меню пункт «Отчёты»
• menu_security          Показывать в верхнем меню пункт «Безопасность»
• menu_system          Показывать в верхнем меню пункт «Система»
• menu_tools          Показывать в верхнем меню пункт «Инструменты»
• new_static_resource   Создавать новые статичные ресурсы.
• remove_locks          Удалять все блокировки на сайте

Обязательно нажимаем кнопку «Сохранить»

7. Переходим во вкладку «Безопасность» — «Контроль доступа» — «Роли»

8. Нажимаем кнопку «Создать новый», в поле Имя вбиваем Manager, Ранг — 9, нажимаем кнопку «Сохранить»

9. Сохраняем изменения и переходим в меню «Безопасность» — «Контроль доступа» — «Группы пользователей»

Правой кнопкой мыши жмем на «Administrator» и нажимаем «Создать группу пользователей»

10. Создаем новую группу: Имя — Manager, Политика бэкэнда — нет политики, жмем «Сохранить»

11. Находим ее в списке Групп пользователей и жмем «редактировать»

12. Заходим в меню «Доступ к контекстам» и нажимаем «Добавить контекст»

13. Контекст — mgr, Минимальная роль — Manager — 9, Политика доступа — Manager

14.

15. Мы увидим такую картину! Сохраняем все во вкладке «Группа пользователя: Manager»

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

17. Создаем нового пользователя (это будет наш клиент) — нажимаем кнопку «Новый пользователь».

Имя вы ему можете задать какое угодно, я назову его — manager

18. Имя пользователя — manager, жмем галочку — Активный, вбиваем email

19. Указываем пароль

20. Перед тем как сохранить, зайдите во вкладку «Права доступа»

21. Жмем кнопку «Добавить пользователя в группу», Группа пользователя — «Manager», Роль — «Manager»

Сохраняем.

22. Переходим во вкладку «Инструменты» — «Источники файлов»

23. Откроется список всех источников файлов. По умолчанию создан одни единственный — Filesystem

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

24. Откроется такое окно. Жмем «Добавить группу пользователей»

25. Группы пользователей — Administrator, Минимальная роль — Super User — 0, Политика — Media Source Admin. Нажимаем «Сохранить»

26.

Назовем его «Manager», Тим источника файлов — Файловая система

Жмем «Сохранить»

27. Нажимаем правой кнопкой мыши на новый источник файлов «Manager» и выбираем «Редактировать»

28. Откроется такое окно! Нам нужно изменить первые 4 параметра

В basePath в поле значение мы вбиваем /manager/, basePathRelative и baseUrlRelative оставляем как есть со значениями «Да», в поле baseUrl пишем manager/

Жмем сохранить! Теперь осталось только задать права доступа к источнику файлов, но перед этим нам нужно задать источник файлов ко всем tv параметрам, которые будет администрировать наш клиент

29. Заходим в tv параметр

30. Нажимаем самую последнюю вкладку «Источники файлов»

и меняем источник файлов с «Filesystem» на «Manager». Сохраняем!

31. Добавляем группу пользователей в «Manager»

Теперь после всех проделанных шагов заходим в «Источник файлов» — «Manager» и добавляем группу пользователей в этот источник файлов

32. Группы пользователей — Manager, Минимальная роль — Manager — 9, Политика — Media Source Admin. Жмем «Сохранить»

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

33. На всякий случай очищаем кэш

и наш пользователь с ограниченными правами и доступами к файловой системе создан!

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

Урок 3. Базовая настройка и установка пакетов MODX

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

Название сайта и другие настройки

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

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

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

На этой странице показаны все системные настройки стандартного набора MODX Revolution. Здесь вы можете увидеть очень большое количество количество настроек, даже вы можете создавать собственные настройки. Мы рассмотрим лишь некоторые из настроек.

В данным момент настройки, которые нас интересуют, это настройки сайта Site settings и мы их можем найти используя функцию фильтра.

В выпадающем меню фильтра Filter by Area можно выбрать нужные нам настройки. Выберите в списке Site, чтобы отфильтровались настройки сайта.

Отредактируем имя сайта сделав в поле имени двойной клик для того, чтобы отредоктировать его. Удалим текущее название сайта и вставим свое имя «Изучение MODX Revolution». После окончания редактирования имени сайта нажмите и спустя некоторое время после обновления страница отобразит новое имя сайта.

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

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

Установка дополнений

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

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

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

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

Откроется станица, на которой будут показаны последние и наиболее популярные дополнения справа и браузер дополнений (пакетов) слева.

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

• MODX Addons (адонны)– это функциональные куски, которые не являются частью ядра MODX, такие как галереи, построители меню, теговые сниппеты и другое. Они не изменяют ядро, а просто добавляют функциональность.
• Core Extensions (расширения ядра) – это дополнения к самому ядру, которые изменяют работу MODX. Они изменяют работу частей ядра.
• FrontEnd Templates (шаблоны фронт-энда)– это готовые к использованию шаблоны сайта сделанные в виде пакетов для быстрой установки. Если вы хотите построить/установить свой собственный шаблон можете воспользоватся этими и изменять их как угодно.
• Manager Templates (шаблоны админки) – это backend шаблоны для изменения вида вашего менедзжера, это повлияет только на внешний вид, но не на функции вашего менеджера.
• Site Packages (пакеты сайта) – это уже построенные полные сайты, которые вы можете установить и исследовать. Это просто отличный способ установить демо MODX сайт и увидеть как он работает. Демо сайт может быть также отличным материалом для изучения инструментов, так как вы можете в нем посмотреть как реализованная та или иная функциональность.

Не бойтесь изучить самостоятельно все эти категории и исследовать доступные пакеты. Во время написания этого урока наиболее богатой на пакеты была категория MODX Addons и именно в ней мы будем брать используемые в дальнейшем пакеты.

Устанавливается адонн/дополнение/пакет очень просто. Например, мы хотим установить текстовый редактор rich text editor (RTE), все что нам нужно сделать — это нажать на папке , развернуть ее, найти в списке и нажать на , далее просто выбрать из списка необходимый нам редактор.

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

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

Установщик попросит вас согласится с лицензией и далее установит пакет, далее нажимаете ОК, если не появилось сообщений об ошибках или проблемах и возвращаемся на страницу управления пакетами, которая покажет эти пакеты как установленные. Как видно у нас появилась кнопка Uninstall для деинсталяции. Дополнительно под списком плагинов видно только что установленный новый адонн.

Все просто. Правда?

Короткая заметка для пользователей XAMPP, если у вас появились проблемы при установке дополнений, проверте включен ли параметр cURL в вашей установке XAMPP.

Выводы.

В этом уроке мы немного расмотрели менеджер MODX Revolution, посмотрели коротко как изменять системные настройки сайта. Также рассмотрели как устанавливать дополнения из репозитория MODX.

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

Скоро новый урок!

В следующем уроке мы добавим парочку страниц к нашему вебсайту и далее начнем строить шаблон для него. Мы не будем использовать уже построенные шаблоны MODX из репозитория, вместо этого мы используем HTML/CSS шаблон и портируем его в MODX Revolution, используя возможность изучить синтаксис MODX Revolution.

Если есть какие-то идеи/комментарии/поправки — не стесняйтесь комментировать.

Полезные материалы:

• Настройка ЧПУ (Friendly URL) на сайте MODX Revolution

Урок 2. Установка MODX Revolution Советы для начинающих работу с MODX

Please enable JavaScript to view the comments powered by Disqus.

MODX — Загрузки — Синтезаторы — Синтезаторы и инструменты для создания музыки — Продукты

Искать на этом сайте

Выберите ОС AllMacWin

Имя	ОС	Размер	Последнее обновление
MODX Connect V1. 2.0 для Mac macOS 12 macOS 11 macOS 10.15 и macOS 10.14	Mac	18,2 МБ	01.09.2022
MODX Connect V1.2.0 для Windows	Вин	15,4 МБ	01.09.2022
USB-драйвер Yamaha Steinberg версии 2.1.1 для Windows 11/10 (64-разрядная версия)	Вин	4,6 МБ	22.02.2022
USB-драйвер Yamaha Steinberg версии 3.1.1 для Mac macOS 11/12 (кремний Intel/Apple с Rosetta 2)	Mac	4 МБ	07.02.2022
—	366,9 МБ	22.02.2021
USB-драйвер Yamaha Steinberg версии 2.0.5 для Mac macOS 10.15–10.13	Mac	3,5 МБ	02.02.2021
USB-драйвер Yamaha Steinberg версии 2.0.4 для Mac macOS 10.15–10.12	Mac	3,4 МБ	25.11.2020
MODX Connect V1.1.1 для Windows	Вин	15,1 МБ	13.11.2020
MODX Connect V1.1.0 для Mac macOS 11 и macOS 10.15-macOS 10.12	Mac	20,7 МБ	2020-06-02
MODX Connect V1. 1.0 для Windows	Вин	15 МБ	2020-06-02
Драйвер USB Yamaha Steinberg версии 2.0.3 для Windows 10/8.1/7 (32-разрядная/64-разрядная версия)	Win	7,1 МБ	2020-03-02
MODX Connect V1.0.6 для Windows	Вин	20,3 МБ	10.01.2019
MODX Connect V1.0.4 для Mac macOS 10.15-OS X 10.11	Mac	51,4 МБ	2018-09-14

org/» typeof=»BreadcrumbList»>
1. Главная
2. Продукты
3. Синтезаторы и инструменты для создания музыки
4. Синтезаторы
5. MODX
6. Загрузки

Путеводители Боба | Скрытие ресурсов в Менеджере

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Контексты

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

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

Роли

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Контекст: управляющий
• Минимальная роль: SubAdmin
• Политика доступа: субадминистратор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это ограничит действия пользователей в Менеджере.

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

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

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

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

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

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

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

Создайте новую группу пользователей с именем «Редакторы».

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

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

• Помните, что пользователи будут наследовать Разрешения политик в списке Доступ к контексту с минимальными ролями, число которых выше, чем у них в группе.
• Не забудьте очистить кеш сайта, сбросить все разрешения (и иногда) сбросить все сеансы перед тестированием каких-либо изменений.
• Обратите внимание, что удаление разрешений file_tree и element_tree полностью скроет эти деревья.
• Вы можете скрыть определенные TV и поля формы Create/Edit Resource, используя правила настройки формы.
• Вы также можете скрыть определенные пункты меню в верхнем меню, используя настраиваемые разрешения, но это другое руководство.

Ограничение пользователей менеджера подмножеством ресурсов с использованием 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 подмножеством ресурсов с использованием групп пользователей и ресурсов

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

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

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

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

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

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

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

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

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

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

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

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

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

Защита страниц AllDocs

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

• Группа ресурсов: AllDocs
• Минимальная роль: администратор Суперпользователь
• Политика: Ресурс
• Контекст: управляющий
• Сохранить

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

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

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

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

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

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

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

Unauthorized Versus Error Page

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

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

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

Краткий обзор

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

?

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

Все еще запутались?

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

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

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

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

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

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

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

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

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

• Разрешения Revolution
• Разрешения на эволюцию
• Памятка по безопасности Revolution
• Основные руководства по безопасности
  • Создание нового пользователя
  • Создание новой роли
  • Создание новой группы пользователей
  • Создание новой группы ресурсов
  • Создание новой записи ACL
  • Создание новой категории
  • Создание новой политики
  • Создание нового шаблона политики
  • Редактирование политики
• Дополнительные руководства по безопасности
  • Создание пользователей-менеджеров
  • Скрытие ресурсов в диспетчере
  • Пользовательские страницы
  • Управление доступом к ресурсам в диспетчере
  • Управление доступом к элементам в диспетчере
  • Скрытие элементов в менеджере
  • Скрытие пунктов главного меню в диспетчере
• Записи ACL Revolution по умолчанию

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

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

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

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

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

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

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

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

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

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

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

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

  —  Боб Рэй

Modx Modx Revolution : Список уязвимостей безопасности

Скопировать результаты Скачать результаты

Нажмите ESC, чтобы закрыть

#	CVE-идентификатор	Идентификатор CWE	# эксплойтов	Тип(ы) уязвимости	Дата публикации	Дата обновления	Счет	Получен уровень доступа	Доступ	Сложность	Аутентификация	конф.	Интегр.	Доступно.
1	CVE-2020-25911	611		DoS	31.10.2021	2021-11-02	6,4	Нет	Удаленный	Низкий	Не требуется	Частичная	Нет	Частично
В компоненте modRestServiceRequest в MODX CMS 2. 7.3 была обнаружена уязвимость XML External Entity (XXE), которая может привести к раскрытию информации или отказу в обслуживании (DOS).
2	CVE-2019-1010123	434			23.07.2019	09.10.2019	5,0	Нет	Удаленный	Низкий	Не требуется	Нет	Частично	Нет
На MODX Revolution Gallery 1.7.0 влияют: CWE-434: Неограниченная загрузка файлов с опасным типом. Результат: создание файла с произвольным именем и содержимым. Компонент: Фильтрация пользовательских параметров перед их передачей в класс phpthumb. Вектор атаки: веб-запрос через /assets/components/gallery/connector.php.
3	CVE-2018-1000208	22		Реж. Трав.	13.07.2018	07.09.2018	6,4	Нет	Удаленный	Низкий	Не требуется	Нет	Частично	Частично
Версия MODX Revolution <= 2.6.4 содержит уязвимость обхода каталога в /core/model/modx/modmanagerrequest.class.php, которая может привести к удалению файлов. Эта атака, по-видимому, может быть использована через веб-запрос через систему безопасности/логина. Эта уязвимость, по-видимому, была исправлена ​​в pull 13980.
4	CVE-2018-1000207	732			13.07.2018	03.10.2019	6,5	Нет	Удаленный	Низкий	???	Частично	Частично	Частично
Версия MODX Revolution <= 2. 6.4 содержит уязвимость неправильного контроля доступа при фильтрации пользовательских параметров перед их передачей в класс phpthumb, что может привести к созданию файла с произвольным именем файла и содержимым. Эта атака может быть использована через веб-запрос. Эта уязвимость, похоже, была исправлена ​​в коммите 06bc9.4257408f6a575de20ddb955aca505ef6e68.
5	CVE-2018-20758	79		XSS	06.02.2019	23.10.2019	3,5	Нет	Удаленный	Средний	???	Нет	Частично	Нет
MODX Revolution до v2.7.0-pl позволяет XSS через пользовательские настройки, такие как описание.
6	CVE-2018-20757	79		XSS	06. 02.2019	06.02.2019	4,3	Нет	Удаленный	Средний	Не требуется	Нет	Частично	Нет
MODX Revolution до v2.7.0-pl позволяет XSS через расширенное пользовательское поле, такое как имя контейнера или имя атрибута.
7	CVE-2018-20756	79		XSS	06.02.2019	06.02.2019	4,3	Нет	Удаленный	Средний	Не требуется	Нет	Частично	Нет
MODX Revolution до v2.7.0-pl позволяет использовать XSS через ресурс документа (например, заголовок страницы), который неправильно обрабатывается во время действия «Обновить», действия «Быстрое редактирование» или просмотра журналов менеджера.
8	CVE-2018-20755	79		XSS	06.02.2019	06.02.2019	4,3	Нет	Удаленный	Средний	Не требуется	Нет	Частично	Нет
MODX Revolution до v2.7.0-pl позволяет использовать XSS через поле «Фото пользователя».
9	CVE-2018-17556	79		XSS	26.09.2018	15.11.2018	3,5	Нет	Удаленный	Средний	???	Нет	Частично	Нет
MODX Revolution v2. 6.5-pl позволяет сохранять XSS с помощью действия «Создать новый медиа-источник».
10	CVE-2018-10382	79		XSS	01.06.2018	27.06.2018	3,5	Нет	Удаленный	Средний	???	Нет	Частично	Нет
MODX Revolution 2.6.3 имеет XSS.
11	CVE-2017-1000223	79		XSS	17.11.2017	01.12.2017	3,5	Нет	Удаленный	Средний	???	Нет	Частично	Нет
Уязвимость внедрения сохраненного веб-контента (WCI, также известная как XSS) присутствует в MODX Revolution CMS версии 2. 5.6 и более ранних версиях. Аутентифицированный пользователь с разрешениями на редактирование пользователей может сохранить вредоносный код JavaScript в качестве имени группы пользователей и потенциально получить контроль над учетными записями жертв. Это может привести к повышению привилегий, обеспечивающих полный административный контроль над CMS.
12	CVE-2017-11744	79		XSS	2017-07-30	2017-08-02	4,3	Нет	Удаленный	Средний	Не требуется	Нет	Частично	Нет
В MODX Revolution 2.5.7 параметры «ключ» и «имя» в модуле «Системные настройки» уязвимы для XSS. Вредоносная полезная нагрузка, отправленная на connectors/index.php, будет запускаться каждым пользователем при посещении этого модуля.
13	CVE-2017-9071	79		XSS	2017-05-18	30.05.2017	2,6	Нет	Удаленный	Высокий	Не требуется	Нет	Частично	Нет
В MODX Revolution до версии 2.5.7 злоумышленник мог запустить XSS, внедрив полезную нагрузку в заголовок HTTP-узла запроса. Это можно использовать только в сочетании с другими проблемами, такими как отравление кеша.
14	CVE-2017-9070	79		XSS	2017-05-18	30.05.2017	3,5	Нет	Удаленный	Средний	???	Нет	Частично	Нет
В MODX Revolution до версии 2. 5.7 пользователь с правами на редактирование ресурсов может вставлять полезную нагрузку XSS в заголовок любого сообщения через параметр pagetitle в коннекторах/index.php.
15	CVE-2017-9069	434		Исполнительный код	2017-05-18	30.05.2017	6,5	Нет	Удаленный	Низкий	???	Частично	Частично	Частично
В MODX Revolution до версии 2.5.7 пользователь с правами на загрузку файлов мог выполнять произвольный код, загружая файл с именем .htaccess.
16	CVE-2017-9068	79		XSS	2017-05-18	30.05.2017	4,3	Нет	Удаленный	Средний	Не требуется	Нет	Частично	Нет
В MODX Revolution до версии 2. 5.7 злоумышленник может инициировать Reflected XSS, вводя полезные данные в несколько полей на странице настройки, что демонстрируется параметром database_type.
17	CVE-2017-9067	22		Реж. Трав.	2017-05-18	31.05.2017	4,4	Нет	Местный	Средний	Не требуется	Частично	Частично	Частично
В MODX Revolution до 2.5.7, когда используется PHP 5.3.3, злоумышленник может включать и выполнять произвольные файлы на веб-сервере из-за недостаточной проверки параметра действия для setup/index.php, также известного как обход каталога.
18	CVE-2017-8115	22		Реж. Трав. +Информация	25. 04.2017	05.05.2017	5,0	Нет	Удаленный	Низкий	Не требуется	Частично	Нет	Нет
Обход каталога в setup/processors/url_search.php (он же страница поиска неиспользуемого процессора) в MODX Revolution 2.5.7 может позволить удаленным злоумышленникам получить информацию о системном каталоге.
19	CVE-2017-7324	94		Исполнительный код	30.03.2017	2020-01-10	7,5	Нет	Удаленный	Низкий	Не требуется	Частично	Частично	Частично
setup/templates/findcore. php в MODX Revolution 2.5.4-pl и более ранних версиях позволяет удаленным злоумышленникам выполнять произвольный PHP-код с помощью параметра core_path.
20	CVE-2017-7323			Исполнительный код	30.03.2017	2020-01-10	6,8	Нет	Удаленный	Средний	Не требуется	Частично	Частично	Частично
Функции (1) обновления и (2) установки пакетов в MODX Revolution 2.5.4-pl и более ранних версиях по умолчанию используют http://rest.modx.com, что позволяет злоумышленникам-посредникам подделывать серверы и инициировать выполнение произвольного кода, используя отсутствие механизма защиты HTTPS.
21	CVE-2017-7322	295		Исполнительный код	30. 03.2017	2020-01-10	6,8	Нет	Удаленный	Средний	Не требуется	Частично	Частично	Частично
Функции (1) обновления и (2) установки пакетов в MODX Revolution 2.5.4-pl и более ранних версиях не проверяют сертификаты X.509 с SSL-серверов, что позволяет злоумышленникам-посредникам подделывать серверы и запускать выполнение произвольного кода через созданный сертификат.
22	CVE-2017-7321	94		Исполнительный код	30.03.2017	2020-01-10	7,5	Нет	Удаленный	Низкий	Не требуется	Частично	Частично	Частично
setup/controllers/welcome. php в MODX Revolution 2.5.4-pl и более ранних версиях позволяет удаленным злоумышленникам выполнять произвольный код PHP с помощью параметра config_key в URI setup/index.php?action=welcome.
23	CVE-2017-7320	79		DoS XSS Http R.Spl.	30.03.2017	2020-01-10	4,3	Нет	Удаленный	Средний	Не требуется	Нет	Частично	Нет
setup/controllers/language.php в MODX Revolution 2.5.4-pl и более ранних версиях не ограничивает должным образом языковой параметр, что позволяет удаленным злоумышленникам проводить атаки с использованием файлов cookie и вызывать отказ в обслуживании (исчерпание квоты файлов cookie) или проводить HTTP Ответ Разделение атак с результирующим XSS через недопустимое значение параметра.
24	CVE-2016-10039	22		Реж. Трав. Включение файла	24.12.2016	14.11.2019	7,5	Нет	Удаленный	Низкий	Не требуется	Частично	Частично	Частично
Обход каталога в /connectors/index.php в MODX Revolution до версии 2.5.2-pl позволяет удаленным злоумышленникам выполнять включение/обход/манипулирование локальными файлами с помощью созданного параметра dir, связанного с браузером/каталогом/getfiles.
25	CVE-2016-10038	22		Реж. Трав. Включение файла	24.12.2016	29.12.2016	7,5	Нет	Удаленный	Низкий	Не требуется	Частично	Частичная	Частично
Обход каталога в /connectors/index. php в MODX Revolution до версии 2.5.2-pl позволяет удаленным злоумышленникам выполнять включение/обход/манипулирование локальными файлами с помощью созданного параметра dir, связанного с браузером/каталогом/удалением.
26	CVE-2016-10037	22		Реж. Трав. Включение файла	24.12.2016	14.11.2019	7,5	Нет	Удаленный	Низкий	Не требуется	Частично	Частично	Частично
Обход каталога в /connectors/index.php в MODX Revolution до версии 2.5.2-pl позволяет удаленным злоумышленникам выполнять включение/обход/манипулирование локальными файлами с помощью созданного параметра id (aka dir), связанного с браузером/каталогом/getlist.
27	CVE-2015-6588	79		XSS	29. 08.2017	2017-09-02	4,3	Нет	Удаленный	Средний	Не требуется	Нет	Частично	Нет
Уязвимость межсайтового скриптинга (XSS) в файле login-fsp.html в MODX Revolution до версии 1.9.1 позволяет удаленным злоумышленникам внедрить произвольный веб-скрипт или HTML через запрос QUERY_STRING.
28	CVE-2014-8992	79		XSS	22.12.2014	22.10.2019	4,3	Нет	Удаленный	Средний	Не требуется	Нет	Частично	Нет
Уязвимость межсайтового скриптинга (XSS) в файле manager/assets/fileapi/FileAPI. flash.image.swf в MODX Revolution 2.3.2-pl позволяет удаленным злоумышленникам внедрить произвольный веб-скрипт или HTML через параметр обратного вызова.
29	CVE-2014-8775	200		+Информация	03.12.2014	22.10.2019	5,0	Нет	Удаленный	Низкий	Не требуется	Частично	Нет	Нет
MODX Revolution 2.x до 2.2.15 не включает флаг HTTPOnly в заголовок Set-Cookie для файла cookie сеанса, что упрощает удаленным злоумышленникам получение потенциально конфиденциальной информации через доступ сценария к этому файлу cookie.
30	CVE-2014-8774	79		XSS	03.12.2014	22. 10.2019	4,3	Нет	Удаленный	Средний	Не требуется	Нет	Частично	Нет
Уязвимость межсайтового скриптинга (XSS) в файле manager/index.php в MODX Revolution 2.x до 2.2.15 позволяет удаленным злоумышленникам внедрить произвольный веб-скрипт или HTML через параметр context_key.
31	CVE-2014-8773	352		Обход CSRF	03.12.2014	22.10.2019	6,8	Нет	Удаленный	Средний	Не требуется	Частично	Частично	Частично
MODX Revolution 2.x до 2. 2.15 позволяет удаленным злоумышленникам обходить механизм защиты от подделки межсайтовых запросов (CSRF) путем (1) пропуска токена CSRF или с помощью (2) длинной строки в параметре токена CSRF.
32	CVE-2014-5451	79		XSS	06.11.2014	2018-10-09	4,3	Нет	Удаленный	Средний	Не требуется	Нет	Частично	Нет
Уязвимость межсайтового скриптинга (XSS) в файле manager/templates/default/header.tpl в MODX Revolution 2.3.1-pl и более ранних версиях позволяет удаленным злоумышленникам внедрить произвольный веб-скрипт или HTML через параметр «a» в файл manager/. ПРИМЕЧАНИЕ. Эта проблема возникает из-за регрессии CVE-2014-2080.
33	CVE-2014-2736	89		Код выполнения Sql	2014-04-24	22. 10.2019	7,5	Нет	Удаленный	Низкий	Не требуется	Частично	Частично	Частично
Множественные уязвимости SQL-инъекций в MODX Revolution до версии 2.2.14 позволяют удаленным злоумышленникам выполнять произвольные SQL-команды через (1) идентификатор сеанса (PHPSESSID) для index.php или удаленным аутентифицированным пользователям выполнять произвольные SQL-команды через (2) пользовательский параметр для Connectors/security/message.php или (3) параметр id в файле manager/index.php.
34	CVE-2014-2311	89		Код выполнения Sql	2014-03-11	22.10.2019	7,5	Нет	Удаленный	Низкий	Не требуется	Частично	Частично	Частично
Уязвимость SQL-инъекции в modx. class.php в MODX Revolution 2.0.0 до 2.2.13 позволяет удаленным злоумышленникам выполнять произвольные команды SQL через неуказанные векторы.
35	CVE-2014-2080	79		XSS	01.03.2014	30.07.2015	4,3	Нет	Удаленный	Средний	Не требуется	Нет	Частично	Нет
Уязвимость межсайтового скриптинга (XSS) в файле manager/templates/default/header.tpl в ModX Revolution до версии 2.2.11 позволяет удаленным злоумышленникам внедрить произвольный веб-скрипт или HTML через параметр «a».
36	CVE-2010-5278	22	1	Реж. Трав.	07.10.2012	2020-01-10	4,3	Нет	Удаленный	Средний	Не требуется	Частично	Нет	Нет
Уязвимость обхода каталога в файле manager/controllers/default/resource/tvs. php в MODx Revolution 2.0.2-pl и, возможно, ранее, когда magic_quotes_gpc отключена, позволяет удаленным злоумышленникам читать произвольные файлы через .. (точку) в Параметр class_key. ПРИМЕЧАНИЕ: некоторые из этих сведений получены из информации третьих лиц.

Общее количество уязвимостей: 36 Страница : 1 (Эта страница)

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

Содержание

• Пользователи
• ролей
• Групповые разрешения
• Настройка разрешений для файлового менеджера
• Настройка разрешений для TinyMCE

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

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

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

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

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

Чтобы создать пользователя-менеджера

Перейдите к Security > Manager Users , затем нажмите «Новый пользователь».

Веб-пользователи

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

Роли

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

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

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

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

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

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

Чтобы создать роль

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

Чтобы назначить роль администратора

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

Групповые разрешения

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

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

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

Пример

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

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

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

Чтобы создать группу пользователей

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

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

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

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

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

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

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

Чтобы добавить документ в группу документов

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

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

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

ПРЕДУПРЕЖДЕНИЕ. Пользователям должно быть предоставлено разрешение хотя бы на один документ на корневом уровне. К сожалению, система разрешений в MODx не позволяет пользователям получать доступ к подкаталогам, если они также не могут получить доступ к родительскому документу(ам). Если вы не предоставите доступ хотя бы к одной строке родительского документа (ов) вплоть до корневого уровня, пользователи увидят пустое дерево документов и не смогут ничего получить. Это недостаток MODx, потому что это означает, что пользователям должны быть предоставлены полные права редактирования всех родительских документов по этому пути, даже если вы не хотите, чтобы они имели такой доступ. Используя приведенный выше пример, если путь к главной странице «Организация А» — /organizations/category1/organizationA/, вы должны обозначить документы «organizations» и «category1» как принадлежащие группе документов «Организация 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/».

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

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

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

• Настройка пути диспетчера файлов не влияет на браузер файлов из редактора форматированного текста. Этот путь необходимо указать отдельно (см. раздел «Настройка разрешений для 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/».

Важно: Если вы настраиваете путь к файловому браузеру, вам нужно будет создать две подпапки в этом пути: «изображения» и «файлы». Браузер файлов ищет все изображения в папке с именем images и все файлы в папке с именем «файлы». Если этих папок не существует, пользователи не смогут воспользоваться файловым браузером. В нашем примере папки будут находиться по следующим путям: «/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» в конфигурации сайта ( Tools > Configuration > Interface and Features > TinyMCE Settings ), вы застряли с этой таблицей стилей несмотря ни на что, даже на страницах, которые ее не используют. Это настоящий позор и сильно ограничивает полезность опции «Путь к файлу CSS». Один неуклюжий обходной путь — ограничить количество классов, доступных для TinyMCE, перечислив их в опции сайта «Селекторы CSS», а затем убедиться, что все таблицы стилей содержат все эти конкретные классы.

Список дел по веб-доступности для MODx Manager

 <заголовок  роль="баннер"  >
    
 role="search  ">
    
    

 role="tablist" aria-label="Tablist в виде дерева"  > 
    <ли  role="tab"  >Ресурсы
Элементы


 роль = "вкладка"  >
    
    
    

<основной  роль="главная"  >
    Сюда помещается весь основной контент (редактирование страниц, редактирование фрагментов, содержимое панели инструментов и т.  д.).

<нижний колонтитул  роль="contentinfo" >
    (Сейчас в менеджере MODx нет нижнего колонтитула, но вы бы разметили его так)
 

 Конфигурация ядра недоступна для записи. Пожалуйста, сделайте /modx/base/path/packages/gpmdoodles/config.core.php доступным для записи, чтобы продолжить.
 

 Элементы: /modx/base/path/packages/gpmdoodles/core/components/gpmdoodles/elements/chunks/doodle. chunk.html — файл не существует
Файл конфигурации недействителен.