Modx manager: MODX Extras | Asset Manager 1.3.1-pl

MODX CMS, система управления сайтом, бесплатная система управления сайтом

Работа на MODX

Иинтернетмагазин на MODX Revolution 2.8.3-pl 4 предложения

Андрей
14.09.2022 в 11:33

Бюджет проекта:

Неопределен

Разработчики:

Любые

Срок до:

25.09.2022

btransport.de 3 предложения

Кирилл
12.09.2022 в 22:17

Бюджет проекта:

Неопределен

Разработчики:

Любые

Срок до:

01. 10.2022

Создать YML файл турбо страниц для интернет магазина 2 предложения

Руслан
01.09.2022 в 12:13

Бюджет проекта:

1500 RUB

Разработчики:

Любые

Срок до:

04.09.2022

Импорт товаров на сайт 2 предложения

Лилия
01.08.2022 в 14:32

Бюджет проекта:

Неопределен

Разработчики:

Любые

Срок до:

31. 08.2022

Забирать данные по API в моем складе, загрузка данных их экселя и обработка данных 1 предложение

Артем
11.08.2022 в 18:01

Бюджет проекта:

Неопределен

Разработчики:

Любые

Срок до:

25.08.2022

Смотреть все записи

Вопрос — Ответ

Задать вопрос

MODX: Все версииEvolutionRevolution

[Revo] Изменение стоимости доставки в корзине Shopkeeper 3

Прикручиваю к шопкиперу расчет доставки через транспортную компанию. Получаю в javascript стоимость доставки. Теперь вопрос — как эту стоимость выставить заказу? Документация крайн…

snowdog178
14.09.22 в 20:09

[Revo] Изменение стоимости доставки в корзине Shopkeeper 3

Прикручиваю к шопкиперу расчет доставки через транспортную компанию. Получаю в javascript стоимость доставки. Теперь вопрос — как эту стоимость выставить заказу? Документация крайн…

snowdog178
14.09.22 в 20:09

Галерея сайтов на MODX

Добавить сайт

MODX:Все версииEvolutionRevolution

Категория:все категорииНе определеноАвто/МотоВыставки, конференцииГорода и страныДизайн и РекламаДом, семьяКаталоги, рейтинги, поисковые системыКомпьютеры и интернетКонсалтингКультура и ИскусствоМебель и интерьерМедицинаМода и красотаМузыкаНаукаНедвижимостьНекоммерческие и госорганизацииНефть и газОборудованиеОбучениеОдеждаПитаниеПолитикаПотребительские товарыПровайдеры, хостингПрограммное обеспечениеПромышленностьРаботаРазвлеченияРелигияСМИСпортСтроительство и ремонтТелекоммуникацииТорговляТранспортные услугиТуризм и отдыхУслугиФинансы, инвестиции, банкиЭлектронная коммерция

• Такси Эконом

  0. 00 0

• Топ браузерных игр
  0.00 0

• Full Check — чип тюнинг в Тюмени.

  0.00 0

• Молагроторг

  0.00 0

• TiNews — Новостной портал

  0.00 0

• zbanking.ru

  0.00 0

Эти сайты были добавлены в каталог MODX.RU за последнее время.
Вы также можете добавить свои сайты в каталог и участвовать в общем рейтинге.

Смотреть все сайты в каталоге

Новости и статьи

Добавить статью

MODX: Все версииEvolutionRevolution

Тип: все записиНовостиСтатьи и руководство

Ссылка на файл в письме заказа MINISHOP

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

Вараника
06.09.22 в 14:09

6. Важное о Evolution CMS — комьюнити-релиз 3.1.12

Вышел новый релиз Evolution 3.1.12 от комьюнити.  Как обновиться?Простой вариант — накатить файлы из гита сверху на сай…

Андрей Казунин
11.07.22 в 13:07

5. Важное о Evolution CMS — комьюнити-релиз 1.4.19

Вышел релиз Evolution CMS 1.4.19 от комьюнити. Что выделил я для себя: Минимальная версия php для корректной работы …

Андрей Казунин
28.06.22 в 13:06

4. Важное о Evolution CMS — комьюнити-релиз 3.1.11

Вышел новый релиз Evolution 3 от комьюнити. Доработана масса вещей. Из приятных для меня лично я бы назвал отображени.

Андрей Казунин
11.05.22 в 11:05

Смотреть все записи

Сброс пароля от панели администратора 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/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 Revolution

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

Смотреть урок на YouTube

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

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

2.

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

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

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

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

3.

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

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

Создание сайта от А до Я. Комплексный курс

Создание современного интернет-магазина от А до Я

Я — фрилансер! Базовый курс для начинающих

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

• Ajax фильтр на MODx Revolution
• Посадка типовой секции Landing Page на MODx с использованием MIGX (добавляемые поля)
• MODX Revolution — Базовый урок
• Как создать шаблон для WordPress. Грамотная посадка верстки на WordPress (Right Way)
• Быстрое создание красивых сайтов на WordPress. Layers Style Kit на реальном примере

Урок 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 Revo

Когда я начал работать на CMF Modx Revolution (до этого сажал сайты на Evolution) я открыл для себя неприятную новость — я не могу создать админку для клиента с теми правами доступа, чтобы клиент ничего не испортил на сайте. То есть с закрытыми «Элементами», рабочими файлами системы, системными настройками и так далее. Вообщем я не знал как настроить админку под клиента. Сейчас знаю :)) И хочу поделиться этими знаниями с вами!

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

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

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

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

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

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

5. Редактируем manager

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.

А точнее редактируем уже имеющийся web: Контекст — web, Минимальная роль — Manager — 9, Политика доступа — Administrator. Нажимаем кнопку «Сохранить»

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

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

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

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

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

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

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

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

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

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. На всякий случай очищаем кэш

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

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

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

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

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

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

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

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

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

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

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

В 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. Вы создаете новую запись 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 защитит страницы новостей во внешнем интерфейсе, но не повлияет на то, кто может видеть их в Менеджере.

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

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

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

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

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

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

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

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

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

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

Здесь есть руководство по сокрытию ресурсов в 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. Записи ACL доступа к группе ресурсов (с контекстом mgr) — точно так же, как в MODX Evolution. Это эквивалент привязки групп документов к менеджерам групп пользователей в Evolution.

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

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

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

1. Скрытие выбранных ресурсов в диспетчере всегда выполняется с записями ACL доступа группы ресурсов с политикой, которая является некоторым подмножеством Ресурсная политика и контекст мгр .
2. Скрытие выбранных ресурсов во внешнем интерфейсе всегда выполняется с записями ACL доступа группы ресурсов с политикой, которая является некоторым подмножеством политики ресурсов и контекстом web .
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 находится здесь.

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

Моя книга, 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

  —  Bob Ray

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
Yamaha Steinberg USB Driver V3.1.1 для Mac macOS 11/12 (Intel/Apple Silicon с Rosetta 2)	Mac	4 МБ	07.02.2022
Программа обновления ОС MODX V2. 52	—	366,9 МБ	22.02.2021
USB-драйвер Yamaha Steinberg версии 2.0.5 для Mac macOS 10.15–10.13	Mac	3,5 МБ	2021-02-02
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
Вин	7,1 МБ	02.03.2020
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 МБ	14. 09.2018

1. Главная
2. Товары
3. Синтезаторы и инструменты для создания музыки
4. Синтезаторы
5. MODX
6. Загрузки

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

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

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

#	CVE-идентификатор	Идентификатор CWE	# эксплойтов	Тип(ы) уязвимости	Дата публикации	Дата обновления	Счет	Получен уровень доступа	Доступ	Сложность	Аутентификация	конф.	Интегр.	Доступно.
1	CVE-2020-25911	611		DoS	2021-10-31	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	2018-09-07	6,4	Нет	Пульт	Низкий	Не требуется	Нет	Частично	Частично
Версия MODX Revolution <= 2.6.4 содержит уязвимость обхода каталога в /core/model/modx/modmanagerrequest.class.php, которая может привести к удалению файлов. Эта атака, по-видимому, может быть использована через веб-запрос через систему безопасности/логина. Эта уязвимость, похоже, была исправлена ​​в pull 139.80.
4	CVE-2018-1000207	732			13.07.2018	03.10.2019	6,5	Нет	Пульт	Низкий	???	Частично	Частично	Часть
Версия MODX Revolution <= 2.6.4 содержит уязвимость неправильного контроля доступа при фильтрации пользовательских параметров перед их передачей в класс phpthumb, что может привести к созданию файла с настраиваемым именем файла и содержимым. Эта атака может быть использована через веб-запрос. Эта уязвимость, похоже, была исправлена ​​в коммите 06bc94257408f6a575de20ddb955aca505ef6e68.
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	30. 07.2017	2017-08-02	4,3	Нет	Пульт	Средний	Не требуется	Нет	Частично	Нет
В MODX Revolution 2.5.7 параметры «ключ» и «имя» в модуле «Системные настройки» уязвимы для XSS. Вредоносная полезная нагрузка, отправленная на connectors/index.php, будет запускаться каждым пользователем при посещении этого модуля.
13	CVE-2017-9071	79		XSS	18.05.2017	30.05.2017	2,6	Нет	Пульт	Высокий	Не требуется	Нет	Частично	Нет
В MODX Revolution до версии 2. 5.7 злоумышленник мог запустить XSS, внедрив полезную нагрузку в заголовок HTTP-узла запроса. Это можно использовать только в сочетании с другими проблемами, такими как отравление кеша.
14	CVE-2017-9070	79		XSS	18.05.2017	30.05.2017	3,5	Нет	Пульт	Средний	???	Нет	Частично	Нет
В MODX Revolution до версии 2.5.7 пользователь с правами на редактирование ресурсов может вставлять полезную нагрузку XSS в заголовок любого сообщения через параметр pagetitle в коннекторах/index.php.
15	CVE-2017-9069	434		Исполнительный код	18.05.2017	30.05.2017	6,5	Нет	Пульт	Низкий	???	Частично	Частично	Частично
В MODX Revolution до версии 2. 5.7 пользователь с правами на загрузку файлов мог выполнять произвольный код, загружая файл с именем .htaccess.
16	CVE-2017-9068	79		XSS	18.05.2017	30.05.2017	4,3	Нет	Пульт	Средний	Не требуется	Нет	Частично	Нет
В MODX Revolution до версии 2.5.7 злоумышленник может инициировать Reflected XSS, вводя полезные данные в несколько полей на странице настройки, что демонстрируется параметром database_type.
17	CVE-2017-9067	22		Реж. Трав.	18.05.2017	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	10.01.2020	7,5	Нет	Пульт	Низкий	Не требуется	Частично	Частично	Частично
setup/templates/findcore.php в MODX Revolution 2.5.4-pl и более ранних версиях позволяет удаленным злоумышленникам выполнять произвольный PHP-код с помощью параметра core_path.
20	CVE-2017-7323			Исполнительный код	30.03.2017	10.01.2020	6,8	Нет	Пульт	Средний	Не требуется	Частично	Частично	Частично
Функции (1) обновления и (2) установки пакетов в MODX Revolution 2. 5.4-pl и более ранних версиях по умолчанию используют http://rest.modx.com, что позволяет злоумышленникам-посредникам подделывать серверы и инициировать выполнение произвольного кода, используя отсутствие механизма защиты HTTPS.
21	CVE-2017-7322	295		Исполнительный код	30.03.2017	10.01.2020	6,8	Нет	Пульт	Средний	Не требуется	Частично	Частично	Частично
Функции (1) обновления и (2) установки пакетов в MODX Revolution 2.5.4-pl и более ранних версиях не проверяют сертификаты X.509 с SSL-серверов, что позволяет злоумышленникам-посредникам подделывать серверы и запускать выполнение произвольного кода через созданный сертификат.
22	CVE-2017-7321	94		Исполнительный код	30. 03.2017	10.01.2020	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	10.01.2020	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	09.10.2018	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	24.04.2014	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	11.03.2014	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	10.01.2020	4,3	Нет	Пульт	Средний	Не требуется	Частично	Нет	Нет
Уязвимость обхода каталога в файле manager/controllers/default/resource/tvs.php в MODx Revolution 2.0.2-pl и, возможно, ранее, когда magic_quotes_gpc отключена, позволяет удаленным злоумышленникам читать произвольные файлы через .. (точку) в Параметр class_key. ПРИМЕЧАНИЕ: некоторые из этих сведений получены из информации третьих лиц.

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

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

Оценка Пола Бохмана с использованием автоматизированных инструментов, таких как FireEyes/WorldSpace от Deque, Wave от WebAIM, но в основном это ручная оценка, сравнивающая действия веб-сайта с Руководством по доступности веб-контента 2. 0 и передовыми методами обеспечения доступности веб-сайтов.

Содержание

• Резюме
• Справочная информация о веб-доступности
• Стили
• Экран входа в систему
• Общая структура страницы
• Верхнее главное меню (убербар)
• Боковая панель дерева
• Модальные диалоги
• Добавить/редактировать ресурс
• Еще не все…

Резюме

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

Эта оценка еще не завершена, но появились некоторые тенденции:

• Доступность клавиатуры:
  • В менеджере MODx есть много мест, где требуется мышь. Это делает невозможным использование слепыми пользователями программ чтения с экрана, потому что мышь бесполезна для тех, кто не видит, где ее щелкнуть. Это также делает его невозможным для зрячих пользователей клавиатуры, которые не могут пользоваться мышью, возможно, из-за дрожи в руках, или отсутствия рук и использования палочки для рта, или из-за другого подобного заболевания. Многие динамические виджеты (таблицы, списки с множественным выбором и т. д.) необходимо дополнить атрибутами ARIA и сочетаниями клавиш в стиле ARIA, чтобы обеспечить эффективное взаимодействие программ чтения с экрана.
• Управление фокусом клавиатуры:
  • Фокус клавиатуры должен следовать за действиями динамических сценариев (модальные окна, проверка форм и т. д.).
• Метки и варианты текста:
  • Каждый активный элемент (ссылки, кнопки и т. д.) и каждый важный элемент, подобный изображению (графика и значки шрифтов), нуждаются в текстовой метке или текстовой альтернативе. Без метки или альтернативного текста программам чтения с экрана нечего читать, поэтому пользователи не знают, что это за элементы.

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

Общие сведения о веб-доступности

• Инвалиды по зрению:
  • Слепым пользователям программы чтения с экрана необходимо:
    • альтернативный текст для изображений, значков и т. д.
    • метки на элементах формы
    • полная доступность с клавиатуры всех функций, включая раскрывающиеся меню, всплывающие подсказки, списки вкладок, модальные окна и т. д.
    • управление фокусом с динамическим содержимым, таким как сообщения об ошибках/обратная связь, динамически загружаемое содержимое AJAX и т. д.
    • логический порядок табуляции
    • действительная ссылка и текст кнопки
    • хорошая структура документа (заголовки, заголовки таблиц, списки, ориентиры)
  • Пользователям с плохим зрением необходимо:
    • хороший цветовой контраст
    • легко видимые стили :focus и, желательно, стили :hover тоже
  • Дальтоникам необходимо:
    • информация, представленная способом, не зависящим от цвета
• Глухим пользователям необходимо:
  • Стенограммы и субтитры для аудио/визуального контента (не проблема с менеджером MODx)
• Пользователям с двигательными нарушениями необходимо:
  • полная функциональность клавиатуры (см. выше для слепых пользователей)
  • легко видимые стили :focus (некоторые люди вообще не могут пользоваться мышью, поэтому им нужно всегда знать, где находится фокус клавиатуры)
• Пользователям с когнитивными нарушениями (включая распространенные нарушения чтения, СДВ и другие) необходимо:
  • простота визуального оформления, организации процессов и т. д.
  • четкие инструкции
  • хорошие механизмы предотвращения ошибок
  • хорошие, интуитивно понятные механизмы восстановления после ошибок

Модели

• Визуальный индикатор фокусировки клавиатуры:
  • Визуальный индикатор фокусировки на клавиатуре либо отсутствует в некоторых местах, либо его трудно увидеть. Это можно добавить в manager/templates/default/css/index.css:
    body *:focus {outline:2px solid #00948e !important;}
body #modx-header *:focus {outline:2px solid #fbf5be !important;}
    Это решит проблему почти везде, но потребуется добавить дополнительные стили и/или JavaScript, чтобы убедиться, что вокруг настраиваемых флажков есть видимый контур. Я понимаю, что это несколько влияет на дизайн, но наличие легко видимого индикатора фокусировки клавиатуры является требованием доступности и оказывает огромное положительное влияние на людей, которые не могут использовать мышь. Воздействие на пользователей мыши минимально. Они увидят это в полях формы, но это, вероятно, хорошо. Они не увидят его при наведении курсора мыши (хотя вы, безусловно, можете добавить те же стили для :hover, что также будет полезно для доступности, хотя и не является таким уж обязательным требованием).2569 [ПРИМЕЧАНИЕ. Я только что заметил, что приведенные выше стили лишь частично работают в Safari и Chrome, по-видимому, из-за некоторых конфликтов с другими стилями, специфичными для webkit, где-то в таблице стилей, поэтому требуется дополнительная работа, чтобы визуальный индикатор фокуса клавиатуры работал в браузеры webkit.]
• Цветовой контраст:
  • Коэффициент цветовой контрастности светлого текста во многих местах не соответствует стандарту WCAG 4,5:1 для обычного текста и 3:1 для крупного текста. Цветовой контраст можно анализировать с помощью автоматизированных инструментов, таких как FireEyes и Wave.

Экран входа в систему

• Этикетки:
  • В поле «имя пользователя или адрес электронной почты» должен быть тег . Текст-заполнитель не считается допустимым ярлыком.
• Обязательные поля:
  • Используйте aria-required=»true» для всех обязательных элементов . Программы чтения с экрана сообщат «требуется» при чтении пользователям.
• Порядок вкладок клавиатуры:
  • Порядок табуляции в основном правильный, но селектор языка в нижнем левом углу не в порядке. Его следует переместить в исходный код так, чтобы он был последним на странице в порядке вкладок, как тогда, когда экран входа находится в состоянии по умолчанию, так и когда активирована функция «забыли свой логин». Я заметил, что для некоторых ссылок и полей используется tabindex. Лучше не использовать tabindex с любыми положительными числами, потому что он переопределяет поведение вкладок браузера по умолчанию способами, которые часто нежелательны для пользователей клавиатуры (tabindex=»0″ допустимо поместить что-то в обычный поток вкладок, а tabindex=»-1 » допустимо сделать что-то фокусируемым с помощью JavaScript, но tabindex=»1″ или больше — не лучшая практика). Одна из проблем с tabindex положительных чисел заключается в том, что если вы забудете добавить значение tabindex в ссылку или поле формы, например ссылку «забыли свой логин», а также в поле «имя пользователя или адрес электронной почты» и «отправить электронное письмо для активации», button — вы рискуете навести порядок, что здесь и произошло. Рекомендация состоит в том, чтобы для начала просто расположить вещи в правильном порядке табуляции в DOM и не изменять порядок табуляции с помощью tabindex положительных чисел.
• Управление фокусом клавиатуры:
  • Когда пользователи нажимают «Забыли логин?» фокус клавиатуры должен переместиться в поле формы «имя пользователя или электронная почта».
• Сообщения об ошибках/отклики:
  • Сообщения обратной связи («Пользователь не найден…», «Введено неверное имя пользователя или пароль…») должны быть прочитаны средствами чтения с экрана при обновлении страницы.
    • Вариант 1: Один из способов добиться этого — принудительно сфокусировать клавиатуру на сообщении об ошибке при перезагрузке страницы. Сообщение об ошибке должно иметь tabindex=»-1″ для эффективного получения фокуса через JavaScript.
      Пользователь не найден…
      . Сообщение должно предшествовать первому соответствующему полю формы. Если имя пользователя/пароль неверно, сообщение должно появиться над полем имени пользователя. Если ошибка возникает в поле «Имя пользователя или адрес электронной почты» (после выбора «забыли пароль?», то сообщение об ошибке должно появиться непосредственно над полем «имя пользователя или адрес электронной почты», чтобы пользователи нажали клавишу Tab один раз, чтобы перейти в это поле.
    • Вариант 2: поместите сообщение об ошибке в метку соответствующего поля, либо поместив его в тег , либо используя aria-label для ссылки на сообщение, например относятся как к обычной метке, так и к сообщению:
      
      Пользователь не найден…
      
      Имя пользователя
      
      Обратите внимание, что вы хотели бы связать сообщение об ошибке с полем «имя пользователя или адрес электронной почты» непосредственно в это поле, а не в поле «имя пользователя». Вы также хотели бы убедиться, что фокус клавиатуры переходит в поле «имя пользователя или адрес электронной почты», а НЕ в верхнее поле «имя пользователя» при перезагрузке страницы. Другими словами, убедитесь, что вы отправляете фокус клавиатуры в правильное поле, соответствующее ошибке, и убедитесь, что сообщение об ошибке связано с соответствующим полем.
    • Также: Установите aria-invalid=»true» для элемента после того, как форма была отправлена ​​для всех неправильных полей. Программа чтения с экрана скажет «недействительно», чтобы пользователи знали, что им нужно исправить это поле.
• Цветовой контраст:
  • Коэффициент контрастности между синим текстом ссылки и серым фоном слишком низкий для некоторых пользователей с плохим зрением. Синий текст слишком светлый даже на белом фоне для стандартов коэффициента контрастности для специальных возможностей. Возможное значение #206e99
  • Слишком низкая контрастность серого текста метки «Язык» в левом нижнем углу и метки «запомнить меня». Возможное значение для «запомнить меня» будет #757575. Возможное значение «Язык» — #575757.
  • Слишком низкая контрастность бирюзового цвета фона кнопок по сравнению с белым текстом сверху. Возможным значением будет #007571.

Общая структура страницы менеджера

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

 <заголовок  роль="баннер"  >
    
 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 — файл не существует
Файл конфигурации недействителен.