Права доступа в Revolution

Перевод статьи "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. 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

  • Контекст: 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/.

27 комментариев

avatar
Как прекрасно, что у нас сошлись мысли =)

Позавчера нашел эту статью, распечатал, чтобы вдумчиво прочитать. А потом решил, что было бы клево ее перевести.

Первую страницу перевел, поддерживайте ;)
avatar
перевод в студию )
avatar
translated.by/you/revolution-permissions/into-ru/trans/ — 29% переведено начерно. ;)
avatar
Скринкаст ещё есть от Shaun McCormick: Understanding MODx Revolution Security
avatar
Видое-то хорошее, вот только на слух мало чего понятно.

Вот бы перевел =)

avatar
Надо попросить splittingred делать скринкасты с субтитрами:)
avatar
Переведено начерно, требуется вычитка.
И можно выкладывать на сайт.
В некоторых абзацах на 2 (самый верхний) и 9 (три нижних) страницах я не уверена, возможно потребуется переформулировать.

з.ы.: привет коллегам, буду изредка заглядывать
avatar
Это вы молодец, спасибо! =)
avatar
Спасибо! :-)
avatar
Спасибо!
avatar
Статью выложил, читать можно, каких-то больших ошибок помоему нет.
И ещё сейчас в Revolution у роли есть «авторитет», я в переводе поменял на «уровень», ещё есть вариант переводить как «ранг доступа», прокомментируйте как лучше.
avatar
Слово «авторитет» у нас в стране имеет несколько не тот оттенок, «уровень» — как-то расплывчато. «Ранг» имеет максимально подходящий смысл.
avatar
FIXED! Исправил на ранг.
avatar
Вот и сказочке конец, все кто слушал — молодец.
BobsGuides.com — Bob Ray


Я думал поменяете на что-то более официальное =)))

Топик следует перенести в лучшее, а вероятно будет лучше создать отдельный топик с переведенной статьей, чтобы в комментариях было обсуждение прав доступа, а не перевода статьи про права доступа ;)
avatar
Никак не разберусь: можно ли сделать так, чтобы пользователь мог редактировать только те документы в папке, которые он создал сам? И если да, то как это реализовать?
avatar
7.Отредактируйте теперь группу «Субадминистраторы», перейдя в раздел Безопасность | Группы пользователей (Security | Access Controls ), на вкладке «Группы пользователей» (User Groups) нажмите правой кнопкой на одну из групп и выберите «Обновление группы пользователей» (Update User Group).

Группы пользователей надо заменить на Управление пользователями
avatar
Контроль доступа то есть.
avatar
Поправьте ошибочку не «updprems_allowroot», а «updperms_allowroot».
avatar
Сам ошибся!)) Верно будет «udperms_allowroot».
avatar
Существует ли возможность дать одним пользователям доступ в админке только к определенной ветке ресурсов, а в фронтенде — ко всему сайту? Второй день ковыряюсь, что-то не получается :(
avatar
Существует такая возможность. Игрался часа 1.5, но сделать удалось. Пробовал на MODX Revo 2.2.0-rc3. Целиком описать все что сделал сложно, скажу только что:
1) создавал юзера test, группу пользователей TEST и роль TEST_ROLE
2) в разделе «Группы ресурсов» создал «тестовую группу ресурсов» и туда перетащил страницы из web, которые я хочу спрятать для юзера test в админке. Возможно после перетаскивания эти страницы перестали быть видны для Админа, тогда
3) чтобы страницы из «тестовой группы ресурсов» были видны админу нужно в разделе «Контроль доступа» для группы Administator настроить необходимые ACL (вкладка «Доступ к контекстам»). После перезагрузить Права доступа в админке и нужные страницы опять будут видны для админа в админке
4) последнее: для группы юзеров TEST выставить необходимые ACL так, чтобы им были видны только страницы не из «тестовой группы ресурсов».
avatar
Спасибо за ответ! Про TEST_ROLE и необходимые ACL хотелось бы поподробнее.
avatar
1) Тут я немного лишнего дал: никаких TEST_ROLE или тестовых политик доступа для данной ситуации создавать не обязательно.

3) настройка ACL для админа (вернее для группы Administrator):
Входим в «Безопасность->Контроль доступа». На «Administrator» правой кнопкой мыши и выбираем «Редактировать группу пользователей», далее редактируем ACL-таблицы. Открываем вкладку «Доступ к группам ресурсов» и создаем 2 новые записи:
— Тестовая группа ресурсов Super User-0 Resource mgr
— Тестовая группа ресурсов Super User-0 Resource web

Перезагружаем права пользователей.

4) настройка ACL для группы TEST:
Открываем страницу «Контроль доступа». На «TEST» правой кнопкой мыши и выбираем «Редактировать группу пользователей».
Открываем вкладку «Доступ к контексам» и создаем 2 новые записи подобные тем что изначально существовали у группы Administrator:
— web Super User-0 Administrator
— mgr Super User-0 Administrator

Открываем вкладку «Доступ к группам ресурсов» и создаем 1 новую запись, как уже ранее вносили у Administrator:
— Тестовая группа ресурсов Super User-0 Resource web

Перезагружаем права пользователей (возможно отдельно нужно залогинется под юзером test и перезагрузить права из под него).

— В результате группа «TEST» стала такая же крутая как и «Administrator», но у нее не видны в админке страницы из Тестовой группы ресурсов.
avatar
Попробовал, получилось что пользователь test вобще перестал видеть фронтенд, ему выдает 404 ошибку. Хотя в админке все так, как вы написали :) Чуть позже попробую на чистой установке.
avatar
У меня ща похожая ситуация возникла как открыл сайт, тольно немного по-другому. Не авторизованному пользователю выдается 404 ошибка на страницы которые положил в «тестовую группу ресурсов». Для авторизованного юзера test все работает правильно.
avatar
Чтобы не авторизованному юзеру были видны страницы из тестовой группы ресурсов надо:
1) открыть страницу «Контроль доступа», вкладку «Группы пользователя»
2) редактировать анонима
3) добавить во вкладке «доступ к группам ресурсов» запись со следующими параметрами:
— Тестовая группа ресурсов
— Member-9999
— Load, List and View
— web
4) «Перезагрузить права доступа» и «Завершить все сеансы»
avatar
4 пункт очень важен, в гайде написано только про «перезагрузить права доступа», но, например, что бы анонимам стало отдавать 403 код, надо обязательно еще и «завершить все сеансы».
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.