Modx права на папки и файлы: Как правильно выставить права на файлы? / Русскоязычное сообщество MODX

Настройка прав доступа для контент-менеджера в 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 на реальном примере

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

• Безопасность
• MODX

Если у вас не просто сайт-визитка, то вы обязательно столкнетесь с задачей разграничения доступа. Как правило, первое, с чем сталкиваются, это приватные страницы типа профиля пользователя. Это что касается сайта. Есть ещё задача управления этим сайтом. И тут кроме админа есть ещё контент-менеджеры, менеджеры по продажам и т.п. И все они работают через админку. Такая концепция MODX. Лично я уже давно считаю, что админка только для админа, а все интерфейсы дополнений необходимо выносить из админки. В этом есть определённые плюсы:

• Не нужно использовать устаревшую библиотеку ExtJS. Она пугает многих новичков и раздражает опытных модыксеров.
  Да, MODX позволяет дополнению работать без этой библиотеки. Но таких юзкейсов единицы, информации по ним крайне мало. Так что начинающий разработчик дополнений не осилит данный подход.
• Перегруженный интерфейс. Даже если отказаться от ExtJs, всё равно пользователь получит жутко перегруженный интерфейс ненужными UI объектами и огромным количеством загружаемых файлов. Плюс всё равно придется использовать API админки сайта и следовать его требованиям.
• Дополнительный уровень безопасности. Например, на сайте с установленным минишопом менеджер, ограниченный минимальными правами, может легко получить полный доступ. Конечно, пользователь с определёнными знаниями. А если вы используете свою концепцию, то можете случайно открыть дырку и скомпрометировать админку. Ведь даже опытные разработчики на этом попадались. Что уж говорить про тех, у кого есть только базовые знания web-безопасности. А если менеджер сидит на фронте, то эта проблема вас беспокоить не будет. По крайней мере, не сильно.

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

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

Модель безопасности в MODX строится на концепции ABAC и использует такое понятие как список контроля доступа (ACL). Сейчас мы разберёмся, что это такое и как оно работает. Для этого обратимся к документации MODX.

Принципал

В MODX принципалом выступает не сам пользователь, а группа пользователя. И чтобы права сработали, пользователя нужно добавить в эту группу. Причём, пользователь может входить в несколько групп. В MODX из коробки есть 2 группы пользователя — «(аноним)» и «Administrator». Если со второй всё понятно, то первая группа виртуальная. Она предназначена только для определения прав доступа для гостей.

Цели

В MODX доступ ограничивают для пяти объектов

• контекст,
• группа ресурсов,
• категория элементов,
• медиаисточник,
• пространство имен (namespace)

Обратите внимание, все объекты единичные, а для ресурсов используется целая группа. Да, в MODX права задаются именно группе ресурсов, а не единичному ресурсу. Т.е. по аналогии с файловой системой на папки, а не на файлы. Ровно такой же принцип используется для настройки прав доступа к элементам MODX. Права определяются не к отдельному чанку или сниппету, а для категории элементов, которая как раз группирует элементы.

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

Политика доступа — это список разрешений, объединенных по конкретному принципу. Например, есть политика доступа «Object» для работы с объектами. Она содержит разрешения на создание, редактирование, удаление, просмотр объекта и списка объектов. Все политики доступа можно найти в интерфейсе контроля доступа на вкладке «Политики доступа». Там же можно создать свою политику или скопировать уже существующую и выставить в ней нужные права.

Полномочия

Ну и следующий важный элемент системы безопасности — полномочия. Это минимальный уровень, который разрешает пользоваться указанными политиками. В MODX это синоним роли. И тут есть определенная особенность, ломающая мозг. Чем ниже число, тем выше уровень полномочий. Просто запомните этот факт. Он неинтуитивен.

В MODX из коробки есть 2 роли: 0 с псевдонимом «Super User» и 9999 с псевдонимом «Member». Так вот, 0 — это максимальные полномочия. 9999 — минимальные. Создавать роли можно в этих пределах.

Ещё запомните, когда говорят про число, то используют определение «ранг». Когда про псевдоним, то «роль». Таким образом, роль «Super User» имеет ранг 0, а роль «Member» — ранг 9999. Просто в разных местах используют оба понятия, но значат они одно и тоже.

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

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

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

Важно!

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

Ещё важно отметить, что в MODX приоритет доступа allow/deny. Т.е. если для объекта не указан ACL, то доступ разрешён. Или вернее, права для него не проверяются. Например, из коробки в MODX для гостей контекста web задана политика доступа «Load Only» с ролью «Member». Соответственно, если вы создадите пользователя и залогините его на сайте, то должны получить ошибку 404. Причина — раз для контекста уже настроен контроль доступа, и текущий пользователь не прошёл проверку (ведь доступ разрешен только для гостей), то соответственно пользователю в доступе отказано. Поэтому вам придётся создать ещё один ACL для группы пользователя, предварительно её создав и добавив туда этого пользователя. Группе нужно дать доступ к контексту web и указать политику доступа «Load Only». Так как на сайте проверяется только эта политика для контекста.

Ну или второй вариант, удалить ACL для гостей. Тогда проверок не будет и пользователь получит доступ к странице. Именно такая логика задумана, что и подтверждается документацией. Но по факту это не так. Ибо есть баг, из-за которого проверка доступа к контексту не работает.

Системные настройки

Моделью безопасности можно управлять через настройки. Для этого есть специальный раздел «Авторизация и безопасность». И самое первое, на что мы обратим внимание — настройка principal_targets. В ней указаны объекты, для которых нужно проверять права. По-умолчанию, там перечислены все 5 — «modAccessContext,modAccessResourceGroup,modAccessCategory,sources.modAccessMediaSource,modAccessNamespace». Но это ещё не всё. Есть ещё 3 настройки, которые управляют доступом к отдельным объектам:

• access_category_enabled — Проверять доступ к категориям,
• access_context_enabled — Проверять доступ к контекстам,
• access_resource_group_enabled — Проверять доступ к группам ресурсов.

Почему их всего 3, а не 5? Не спрашивайте.

Кэширование

В MODX очень многие вещи кэшируются. И права не исключение. Как я сказал выше, ACL для групп пользователя кэшируются в сессии пользователя. И сбросить этот кэш можно только заставив пользователя перелогиниться. ACL для групп ресурсов (modAccessResourceGroup) хранятся в кэше ресурса в ключике «policyCache». Права доступа к контекстам (modAccessContext) хранятся в кэше контекстов в ключике «policies». Оба кэша можно сбросить через меню «Очистить кэш».

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

Заключение

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

03 июля 2020 1   2554

Медиабраузер показывает каталог, но не показывает контент в MODX

спросил 6 лет, 8 месяцев назад

Изменено 6 лет, 8 месяцев назад

Просмотрено 440 раз

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

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

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

Некоторые вещи, которые следует принять во внимание:

1. Modx версии 2.3 (я уже обновился, но все еще не работает)
2. Права доступа к папке FTP все 777
3. Все источники медиа-файлов верны
4. Я удалил кеш + права
5. В файле error.log нет видимых ошибок.
6. Мой ACL правильный, у него есть права администратора

введите здесь описание изображения введите описание изображения здесь

Пожалуйста, совет. Большое спасибо!!

ОБНОВЛЕНИЕ: Каталоги повреждены Я создал новые каталоги и переименовал старые каталоги.

• модуль
• modx-revolution
• modx-resources

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

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

1

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

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

Опубликовать как гость

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

Требуется, но никогда не отображается

Опубликовать как гость

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

Требуется, но не отображается

apache — Кэш ModX: файлы записываются с неправильными разрешениями

спросил

10 лет, 5 месяцев назад

Изменено 10 лет, 5 месяцев назад

Просмотрено 1к раз

Название на самом деле не суммирует все это. ..

Недавно я установил ModX Revolution 2.2.4 на сервер Apache, и у меня возникли проблемы с папкой кэша. Иногда мне приходится вручную очищать папку кеша через ftp, но любые записанные туда файлы принадлежат Apache, и моя учетная запись не может их удалить. Я попытался добавить «new_file_permissions» и «new_folder_permissions» в системные настройки, но никаких изменений. Файлы кеша всегда принадлежат Apache, и у меня нет доступа по ftp.

Кроме того, такие файлы, как .htaccess и вообще все, что я загружаю (css и т. д.), воспринимаются modx как нередактируемые, если я вручную не изменю их на 777 через ftp. Я не могу изменить владельца и группу.

Серверный техник не может понять. Этот вопрос уже поднимался на форумах modx, но на него так и не ответили.

• apache
• права доступа к файлам
• modx
• modx-revolution
• права доступа к каталогам

Очевидно, это проблема сервера.

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