ГлавнаяModxModx права доступа

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


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

В данном уроке мы по шагам настроим права доступа в MODX для контент менеджера сайта.

Шаг 1. Создание политики доступа для контент менеджеров.

Для того чтобы создать пользователя перейдите в «Настройки» (шестеренка в правом верхнем углу) > «Контроль доступа» и на открывшейся странице переходим во  вкладку «Политики доступа«.

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

Далее копируем «Content Editor» (щелкаем пкм (правой кнопкой мыши) и выбираем копировать), редактируем (пкм — редактировать) новую политику и называем ее «Менеджер«, пролистываем страницу пониже и устанавливаем галочки на против следующих разрешений:

После этого сохраняете новую политику доступа.

Шаг 2 — Создание группы пользователей для контент менеджеров и устанавливаем для нее права

Теперь снова идем в «Настройки» > «Контроль доступа«, переходим во  вкладку: «Группы пользователей & Пользователи» и создаем новую группу пользователей с именем «Контент менеджеры«. Устанавливаем в окне новой группы пользователей контексты — web, mgr; политика бэкэнда — Менеджер и сохраняем.

создаем новую группу пользователей

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

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

mgr, web > редактировать, устанавливаем «Политика доступа» как «Менеджер» + Сохранить

Политика доступа" как "Менеджер

 

Политика доступа - Менеджер

Шаг 3 — Создане нового пользователя и назначение ему прав

Переходим в «Управление» > «Пользователи» и создаем нового пользователя .

Создание нового пользователя

В открывшейся странице на вкладке «Общая информация» указываем имя — manager, указываем E-mail менеджера, ставим галки на против — «Активный » и «Я укажу пароль сам» и задаем пароль.

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

Переходим на вкладку «Права доступа» > «Добавить пользователя в группу» >»Контент Менеджеры«, Роль: «Super User» >  Сохранить

Добавляем пользователя в группу

Ну и потом еще раз «Сохранить» (сверху), чтобы сохранить пользователя.

После этого переходим в меню «Управление» > «Перезагрузить права доступа»

Шаг 4 — Добавление нового источника файлов

Переходим в «Медиа» > «Источники файлов» и копируем источник «Filesystem»

Копируем источник файлов

Отредактируем скопированный источникНазвание: «images»; basePath и baseUrl: «assets/images/» и сохраняем его.

Изменяем общую информацию у источника файлов

Переходим в меню: «Настройки» > «Контроль доступа» далее жмем правой кнопкой мыши по группе «Контент менеджеры» и выбираем редактировать. Переходим на вкладку: «Права доступа» > «Доступ к источнику файлов» и добавляем новый источник файлов: Источник: images, Минимальная роль: Member — 9999, Политика доступа: Media Source Admin и Сохранить;

добавляем новый источник файлов для менеджеров

Меню: «Управление» > «Очистить кэш»; Меню: «Управление» > «Перезагрузить права доступа»

Шаг 5 — Удаляем источник «Filesystem» для manager

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

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

И потом еще раз сохранить сверху в правом углу.

Теперь точно также изменим права доступа к источнику файлов «images».

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

 

Шаг 6 — Управление группами ресурсов

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

Управление группами ресурсов MODXДобавить элементы в новую группу «Администратор», которые мы хотим скрыть от менеджера (просто перетаскиваете их мышкой) и сохраняем.

Скрываем ресурсы от менеджеров

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

Ну и завершающий штрих: Меню: «Управление» > «Очистить кэш»; Меню: «Управление» > «Перезагрузить права доступа». Все 🙂

Да еще бывают глюки у менеджеров с tv полями картинок, так что лучше используйте не стандартное tv изображение, а дополнение mixedImage (можно установить из репозитория modstore).

web-revenue.ru

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

Конкурс ITPrincess: https://goo.gl/lavFta

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

Поделиться

Твитнуть

Поделиться

Класснуть

Плюсануть

Запинить

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

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

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

2.1. Добавляем источник файлов
2.2. Удаляем источник "Filesystem" для manager

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

На этом все, друзья :)

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

webdesign-master.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

archive.is

Prostoy-Site | Все права защищены © 2018 | Карта сайта