[adminTools] Права доступа для ресурсов
Права доступа в MODX — вещь не очень понятная и требует время для познания. С наскока управиться с ними не получится. Даже если нужно просто ограничить доступ к страницам на сайте, всё равно придётся разбираться с группами ресурсов, пользователей, политиками и т.п. Но теперь это делать не обязательно.
Данное решение достаточно простое — у ресурса добавляется вкладка «Права доступа» и в ней можно перечислить, кому показывать страницу, а кому нет. Причём в привычном для многих стиле операционной системы.

Чтобы добавить запись, нажимаем кнопку "+ Добавить" и выбираем нужную строчку в списке «Группа/пользователь».

Первые 2 строчки списка — «Все» и «Гости». Думаю, тут пояснять не нужно. Дальше идут группы. Они выделены жирным шрифтом и обозначены иконкой с несколькими пользователями. Затем перечисляются пользователи (иконка с одним пользователем). Если выбрана группа пользователей, то становится доступным поле «Приоритет». Поясню, зачем оно нужно.
Проверка прав идет последовательно в порядке создания записей. Если указано несколько групп, то права пользователя будут такие, какие указаны для последней группы. Но если у первой группы указать приоритет выше остальных групп, то её права будут выше. Это может пригодится, например, если пользователям группы «Администратор» разрешить доступ, а другой группе, добавленной ниже, запретить. Тогда, если пользователь является членом обоих групп, а у группы «Администратор» приоритет выше, то доступ для пользователя будет открыт. Это что касается приоритета групп. А ещё есть приоритет записей прав.
У записи «Все» наименьший приоритет. У пользователя — максимальный приоритет. Т.е. если группе пользователей дан доступ к ресурсу, а пользователю, входящему в данную группу — нет, то для него этот ресурс будет недоступен и он будет перенаправлен на страницу, указанную в системной настройке unauthorized_page.
Чтобы наоборот, только гости могли видеть страницу, добавляем:
1. «Все» со значением «Запретить».
2. «Гости» со значением «Разрешить».
В общем, пробуйте. Версия пока бета, но ошибок не замечено.
Данное решение достаточно простое — у ресурса добавляется вкладка «Права доступа» и в ней можно перечислить, кому показывать страницу, а кому нет. Причём в привычном для многих стиле операционной системы.

Принцип работы
Включается этот механизм системной настройкой admintools_alternative_permissions. После этого у ресурса будет доступна вкладка «Права доступа». Если права не указаны, то ресурс доступен всем без ограничений. Как только добавили права, начинает работать проверка.Чтобы добавить запись, нажимаем кнопку "+ Добавить" и выбираем нужную строчку в списке «Группа/пользователь».

Первые 2 строчки списка — «Все» и «Гости». Думаю, тут пояснять не нужно. Дальше идут группы. Они выделены жирным шрифтом и обозначены иконкой с несколькими пользователями. Затем перечисляются пользователи (иконка с одним пользователем). Если выбрана группа пользователей, то становится доступным поле «Приоритет». Поясню, зачем оно нужно.
Проверка прав идет последовательно в порядке создания записей. Если указано несколько групп, то права пользователя будут такие, какие указаны для последней группы. Но если у первой группы указать приоритет выше остальных групп, то её права будут выше. Это может пригодится, например, если пользователям группы «Администратор» разрешить доступ, а другой группе, добавленной ниже, запретить. Тогда, если пользователь является членом обоих групп, а у группы «Администратор» приоритет выше, то доступ для пользователя будет открыт. Это что касается приоритета групп. А ещё есть приоритет записей прав.
У записи «Все» наименьший приоритет. У пользователя — максимальный приоритет. Т.е. если группе пользователей дан доступ к ресурсу, а пользователю, входящему в данную группу — нет, то для него этот ресурс будет недоступен и он будет перенаправлен на страницу, указанную в системной настройке unauthorized_page.
Пример
Чтобы закрыть страницу от неавторизованных пользователей, достаточно добавить одну запись «Гости» и запретить им доступ. Всего одно действие! И сравните с обычной настройкой MODX. Чувствуете разницу?Чтобы наоборот, только гости могли видеть страницу, добавляем:
1. «Все» со значением «Запретить».
2. «Гости» со значением «Разрешить».
В общем, пробуйте. Версия пока бета, но ошибок не замечено.
Комментарии: 25
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
Получается что группа указана последней будет приоритетнее?
И что за приориет записи прав?
Что будет с дочерними ресурсами, в случае если ограничить доступ к родителю?
А так это очень нужное добавление, однозначно в избранное и плюс автору!
Возможно 2 варианта —
1. Приоритет записей — последовательная проверка добавленных прав.
2. Приоритет прав — например, «запрещение» выше «разрешения».
Я выбрал первый вариант, у него больше возможностей.
Логика такая:
1. Запись «Все» — имеет наименьший приоритет. Может быть только одна такая запись.
2. Запись с группой пользователей — перебивает права, указанные в записи «Все». Групп можно указать несколько.
3. Запись с пользователем — имеет наивысший приоритет. Перебивает права групп и записи «Все». Каждый пользователь может быть указан только один раз.
Так как групп может быть несколько, то для них как раз и вводится ещё один приоритет.
Так же как и в родном механизме MODX — права родителя не влияют на дочерний ресурс. Но думаю, такая возможность будет не лишний. Спасибо за идею.
Интересует пункт с правами родителя и дочерних документов.
Попробовал выставить права
Но неавторизированный пользователь все равно может просматривать дочерний документ.
Я полагаю такой функционал не сделан?
Подскажите пожалуйста как проще ограничить доступ к дочерним ресурсам? дочерних ресурсов много в ручную конечно же не вариант(все-таки 21 век)
Мысль написать плагин, чтобы слать всех на страницу авторизации если не авторизирован, но это как то «велосипедно», хотелось бы по уму.
Самый простой вариант проверять права у родителя текущего ресурса. Нужно создать плагин на событие OnLoadWebDocument:
Т.е. я про вложенность, если вложенность 3 уровня или более. Но это блин, замедлит работу.
.-.- -....- --… .-
А чем обусловлено такое желание?
П.С. adminTools — набор независимых друг от друга примочек.
Когда admintools_alternative_permissions активна то вечная анимация прелоадера добавления в корзину и товар не добавляется!
Разбираться было лень откатился на 1.6.0
Действительно когда приходилось возится с правами это занимало уйму времени.
Еще хотелось бы чтоб в пакет admintools входила похожая штука как AjaxManager. Т.к. AjaxManager давно уже не обновляется и поглючивает когда устанавливаешь на текущие версии модх, а Вы занимаетесь админкой и название(admintools) подходящее, было бы круто чтоб похожий плагин(который работает на свежих версиях нормально) входил в Ваш пакет.
Спасибо и на том, что есть щас!