Сообщество MODX. Группы ресурсов modx

Топики с тегом группы ресурсов

Иногда бывают ситуации, когда надо, чтобы какой-то закрытый документ все-таки выводился в меню. Это особенно удобно тогда, когда на сайте не особо нужна авторизация, и пользователи не авторизовываются просто так, но из-за этого они не видят какие-то важные пункты меню, которые должны быть видны авторизованным пользователям. А так даже если документ закрытый, а в меню он есть, пользователь уже его видит, и если у него есть интерес к этому документу, он переходит на эту страницу, и если не авторизован, то ему выводится страница «Доступ запрещен» с формой авторизации/регистрации. Тогда пользователь авторизуется и получит доступ к документу. К сожалению, в MODX-е не предустановлена такая политика безопасности. Есть Load only, но тогда для этого документа не будет выводиться пункт меню, ибо для этого требуются права list. Есть Load, list and view, но это полные права, в том числе и на просмотр документа, то есть если документ должен быть доступен только определенным группам пользователей, а не всем, то нам эта политика не подходит априори. Нужна политика List and load, но её-то как раз и нет. Вот рассмотрим процесс создания такой политики.

1. Создаем новую политику безопасности и назовем ее List and load. Здесь важно указать шаблон политик безопасности — ObjectTemplate. /assets/images/resized/2014/1343/step1.jpg

/assets/images/resized/2014/1343/step2.jpg

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

/assets/images/resized/2014/1343/step2_1.jpg

/assets/images/resized/2014/1343/step2_2.jpg

2. Создаем группу ресурсов «Вывод в меню». Так как политики безопасности для документов основываются на группах ресурсов, то нам необходимо такую создать. При чем я не советую вам настраивать доступ List and load для анонимусов прям на ваши какие-то закрытые группы, так как явность в управлении сильно спадает. Лучше документ отнести сразу к двум группам, то есть одна группа будет обеспечивать доступ к документу для определенных групп пользователей (именно на просмотр), а вторая группа «Вывод в меню» будет обеспечивать видимость документа в меню.

/assets/images/resized/2014/1343/step4.jpg

/assets/images/resized/2014/1343/step5.jpg

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

/assets/images/resized/2014/1343/step6.jpg

4. Даем анонимным пользователям доступ List and load к этой группе ресурсов. Для этого опять идем в «Контроль доступа» и редактируем группу пользователей.

/assets/images/resized/2014/1343/step3.jpg

/assets/images/resized/2014/1343/step7.jpg

На всякий случай сбрасываем права доступа.

/assets/images/resized/2014/1343/step7_1.jpg

На всякий случай всем группам пользователей добавьте доступ List and load к группе ресурсов «Вывод в меню». Это особенно критично в случаях, когда есть группы пользователей, которые не имеют доступа к этому ресурсу, и получится, что пользователь авторизовался (то есть он уже не анонимус) и в тоже самое время он не имеет доступа к этому ресурсу и у него этот ресурс пропадет из меню.

5. Не забудьте создать документ «Доступ закрыт» и в системных настройках указать его id в настройку unauthorized_page. К контент этого документа пропишите [[!Login]] или типа того (то есть выведите форму регистрации/авторизации на свое усмотрение).

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

modxclub.ru

Скрытие ресурсов в админке Modx Revolution для менеджера

Добрый день, дорогие читатели. Сегодня я расскажу как скрыть системные или не нужные для менеджера ресурсы из дерева документа на сайте под управление Modx Revolution (текущая версия 2.4.2). Для начала поймем для чего нам это нужно. В дереве документы у нас есть системные ресурсы, которые мы не показываем в меню. Это, скажем, sitemap, результаты поиска, 404 страница, Сайт не доступен и многие многие другие. И очень не хотелось бы, что обычный менеджер видел эти ресурсы в дереве документов. И в Modx Revolution предусмотрено это — их можно просто скрыть. Как это делается, я сейчас подробно опишу. В качестве примера я приведу один из моих сайтов. Его дерево документов выглядит так:

Мы видим, что здесь имеются системные ресурсы, которые не отображаются в меню: Sitemap, Корзина товаров, Результаты поиска и Оформление заказа. Нам нужно скрыть эти ресурсы от слишком любопытного менеджера, чтобы он там ничего не напортачил.

Создаем группу ресурсов

Заходим в Содержимое/Группы ресурсов

и нажимаем на кнопку «Создать группу ресурсов»

и создаем группу «Admin» (вы можете назвать по другому)

Никакие галочки не выставляем. Жмем кнопку «Сохранить»

Перенос нужных ресурсов в группу ресурсов «Admin»

Далее переносим методом drag and drop ресурсы, которые нужно исключить из админки менеджера. В моем случаем это все скрытые из меню ресурсы:

Даем доступ к группе ресурсов «Admin» только группе пользователей «Administrator»

Для это заходим в «Контроль доступа»

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

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

Здесь идем во вкладку «Доступы к группам ресурсов»

И жмем кнопку «Добавить группу ресурсов»

Группа ресурсов: «Admin»
Контекст: Manager (mgr)
Минимальная роль: Member-9999
Политика доступа: Resource

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

Обновляем админку менеджера и видим, что ресурсы, которые мы добавили в группу ресурсов «Admin» исчезли.

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

В следущий раз когда Вам нужно будет скрыть како-либо ресурс, Вы просто можете зайти в этот ресурс, нажать на «Группы пользователей» и отметить галочку напротив «Admin»

На этом у меня все, успехов Вам в освоении Modx Revolution и до новых уроков. Надеюсь помог. Добро.

bayguzin.ru

Права доступа в Revolution / Документация по MODx / Сообщество MODX

Перевод статьи "Revolution Permissions" которую написал Bob Ray.

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

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

Где устанавливаются права доступа?

Для простоты понимания стоит отметить, что система прав доступа MODx Revolution состоит из четырех частей.

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

Видимостью и структурой главного меню админки можно управлять из System | Actions (Система | Действия)
Задать видимость полей в конкретных формах (например для страницы создания/редактирования ресурса) для определенных пользователей можно из Security | Form Customization (Безопасность | Настройка форм).

Больше нет «Менеджеров» и «Веб пользователей»

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

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

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

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

В MODx Revolution ресурсы и контексты защищены в списках контроля доступа (для краткости мы будем использовать сокрашение ACL). Если ресурс или контекст защищён с помощью ACL записи, то доступ к ресурсу или контексту могут получить только пользователи которым доступ разрешён с помощью ACL записи и эта запись будет определять, что они могут делать.

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

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

Я предполагаю, что вам известно (или вы в состоянии узнать) что такое пользователь, группа пользователей, и группа ресурсов («ресурс» — официальное название документов (Documents), веб-ссылок (Weblinks), символических ссылок (Symlinks) и статических ресурсов (Static Resources). Если вы не понимаете всего этого сейчас, то просто думайте что: ресурс = документ). Если вы привыкли к управлению правами доступа в Evolution, то вам потребуется дополнительная информация о контекстах, ролях, политиках доступа и списках контроля доступа (ACLs)

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

Контексты

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

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

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

Разрешения относящиеся к контексту «web» определяют что пользователи могут видеть и делать в фронтенде сайта.

Роли

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

Ранг роли Super User равен 0.

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

Ранг это число между 0 и 9999.

Все, что вам действительно нужно знать о них сейчас, заключается в следующем:

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

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

При добавлении пользователя в группу, вы назначаете ему роль в этой группе.

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

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

Роли создаются в Security | Access Controls (Безопасность | Группы пользователей), вкладка «Roles(Роли)».

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

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

Политики доступа это просто списки индивидуальных разрешений.

Вы можете увидеть некоторые из них (Важно: не изменяйте и не удаляйте их сейчас) в Security | Access Controls | Access Policies (Безопасность | Группы пользователей | Политики доступа).

Щёлкните по политике и выберите «Edit(Редактировать)». Затем выберите вкладку «Permissions(Разрешения)» и вы увидите список разрешений для этой политики.

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

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

В стандартную установку Revolution входят две стандартные политики: политика Administrator и политика Resource. Три важных принципа регулирующих использование этих политик:

Никогда не изменяйте политики Administrator и Resource. Всегда делайте их копию, а затем изменяйте копию.
Политики используемые в ACL записях определяющих права доступа для контекстов должны основываться на стандартной политике Administrator.
Политики используемые в ACL записях определяющих права доступа для групп ресурсов должны основываться на стандартной политике Resource.

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

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

Замечание: перед тем как разбираться с разрешениями, проверьте системную настройку «updprems_allowroot» в разделе «Система | Настройки системы» (System | System Settings). Она определяет право пользователей создавать документы в корне сайта и перекрывает любые другие настройки безопасности.

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

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

Первое, обо что спотыкаются начинающие пользователи Revolution — это местонахождение ACL. Вы можете найти их в разделе Безопасность | Группы пользователей (Security | Access Controls ), на вкладке «Группы пользователей» (User Groups) нажмите правой кнопкой на одну из групп и выберите «Обновление группы пользователей» (Update User Group).

Три крайних правых таба на открывшейся панели — это именно Списки контроля доступа. Они сгруппированы в таблицы и… на странице нет никаких упоминаний об ACL, но это именно они.Каждая строка таблицы — это одна ACL-запись, правило, указывающее на то, что может участник редактируемой группы с определённой ролью делать или видеть.

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

Существует 2 вида ACL: для контекстов и для групп ресурсов. (Прим.: на самом деле сейчас в админке есть ещё третий вид доступа: к категориям элементов)

ACL для контекстов

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

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

Для группы администраторов уже создан набор контекстных ACL-записей к контекстам «mgr» и «web», что защищает эти контексты по-умолчанию. Поначалу эта система немного сбивает с толку:

когда вы создаёте нового пользователя, он не может залогиниться в админку пока вы не добавите его в группу пользователей и не дадите пользователю доступ к этому контексту посредством создания ACL-записи с контекстом «mgr»;

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

Итак, каждая ACL-запись для контекста содержит настройки «Контекст», «Минимальная роль», «Политика доступа». Пользователи с минимальной ролью в редактируемой группе пользователей (или кто-то с наименьшим уровнем) будут иметь возможность выполнять в указанном контексте все административные действия, отражённые в выбранной политике доступа.

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

1.Сначала создайте Роль «Субадминистратор» с рангом 9.
2.Создайте группу пользователей «Субадминистраторы» и добавьте туда участников с ролью «Субадминистратор»
3.Сделайте копию стандартной политики доступа «Administrator»
4.Отредактируйте дубликат, заменив название на «Субадминистратор»
5.На вкладке «Разрешения» (Permissions) удалите всё нежелательное для субадминистраторов. К примеру, удаление разрешения «access_permissions» предотвратит возможность редактирования участниками группы уровней безопасности как собственного, так и для других пользователей. А удаление разрешений «the element_tree» и «file_tree» не позволит им видеть, соответственно, вкладки «Элементы» и «Файлы» в левой панели админки.
6.Сохраните политику.
7.Отредактируйте теперь группу «Субадминистраторы», перейдя в раздел Безопасность | Группы пользователей (Security | Access Controls ), на вкладке «Группы пользователей» (User Groups) нажмите правой кнопкой на одну из групп и выберите «Обновление группы пользователей» (Update User Group).
8.Перейдите на вкладку «Доступ к контекстам» (Context Access).
9.Добавьте ACL-запись (нажатием на кнопку «Добавить контекст» (Add Context) ). Укажите следующие значения:
- Контекст: mgr
- Минимальная роль: Субадминистратор
- Политика доступа: Субадминистратор
10.Выберите в меню Безопасность |Очистить права доступа (Security | Flush Permissions).
Если вы сейчас попытаетесь зайти в админку под одним из участников группы «Субадминистраторы», то логин будет успешным, но блок с деревом ресурсов слева будет пустым, так как вы не дали группе «Субадминистраторы» доступа к «web»-контексту. Теперь надо сделать ещё одну контекстную ACL-запись со следующими значениями:
- Контекст: web
- Минимальная роль: Субадминистратор
- Политика доступа: Субадминистратор
Всё, теперь участники группы «Субадминистраторы» имеют доступ к админке с ограничениями.

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

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

ACL для групп ресурсов

Итак, в панели редактирования группы пользователей найдите вкладку «Доступ к группам ресурсов» (Resource Group Access). ACL-записи в этом списке позволяют определять, какие конкретные ресурсы могут видеть пользователи в админке и во фронтенде и что они могут делать с этими ресурсами. Создать ресурсную ACL-запись можно нажатием кнопки «Добавить группу ресурсов» (Add Resource Group). Так же как с контекстными ACL, создавая ресурсную ACL вы делаете «защищёнными» ресурсы в указанном контексте. Никто не сможет увидеть их в определённом контексте, пока вы не дадите соответствующий доступ в ресурсной ACL-записи.

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

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

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

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

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

Опять же, как суперпользователь, когда вы обновите кэш настроек доступа (Безопасность |Очистить права доступа (Security | Flush Permissions)), вы заметите отсутствие страниц новостей в дереве ресурсов. Чтобы вернуть их вы можете либо добавить администратора в группу «Редакторы» (вероятно, с минимальной ролью «Super User» и политикой «Administrator»), либо отредактировать группу «Administrator», добавив в неё ресурсную ACL-запись с указанием на группу ресурсов «Новости», контекст «mgr», минимальную роль «Super User» и политику доступа «Administrator».

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

Но допустим, вы хотите ещё и спрятать новости во фронтенде от анонимных посетителей. Добавим ещё одну ресурсную ACL-запись со следующими значениями:

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

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

Заметьте, если вы просматриваете документы из админки, вы всё ещё залогинены как суперадмин. Чтобы протестировать фронтенд-доступ откройте сайт в другом браузере.

Административные действия через фронтенд

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

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

«Доступ запрещен» и «Документ не найден»

В отличие от MODx Evolution в Revolution если страница защищена на сайте, то только залогиненые пользователи могут ее увидеть. При попытке просмотра такой страницы по-умолчанию анонимус будет переправлен на страницу с ошибкой, а не на страницу «Доступ запрещен». В Revolution если пользователь не имеет прав доступа «load» для ресурса это все равносильно для него отсутствию страницы на сайте. Если вы хотите показать анонимусу страницу «Доступ запрещен», вам необходимо сделать следующее:

Создать новую политику доступа (Access Policy) с названием «Load» и добавить единственное разрешение (Permission): Load.
Создать новую ресурсную ACL-запись для группы (anonymous ), указав для группы ресурсов защищаемые ресурсы, для контекста — «web», минимальную роль — «Member» и политику доступа — «Load». Проделайте это для каждой защищаемой группы ресурсов.

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

Вот и сказочке конец, все кто слушал — молодец. BobsGuides.com — Bob Ray

Поучаствовать в переводе, исправлении ошибок можно здесь http://translated.by/you/revolution-permissions/into-ru/trans/.

archive.is