[adminTools] Права доступа для ресурсов
Права доступа в MODX — вещь не очень понятная и требует время для познания. С наскока управиться с ними не получится. Даже если нужно просто ограничить доступ к страницам на сайте, всё равно придётся разбираться с группами ресурсов, пользователей, политиками и т.п. Но теперь это делать не обязательно.
Данное решение достаточно простое — у ресурса добавляется вкладка «Права доступа» и в ней можно перечислить, кому показывать страницу, а кому нет. Причём в привычном для многих стиле операционной системы.
Чтобы добавить запись, нажимаем кнопку "+ Добавить" и выбираем нужную строчку в списке «Группа/пользователь».
Первые 2 строчки списка — «Все» и «Гости». Думаю, тут пояснять не нужно. Дальше идут группы. Они выделены жирным шрифтом и обозначены иконкой с несколькими пользователями. Затем перечисляются пользователи (иконка с одним пользователем). Если выбрана группа пользователей, то становится доступным поле «Приоритет». Поясню, зачем оно нужно.
Проверка прав идет последовательно в порядке создания записей. Если указано несколько групп, то права пользователя будут такие, какие указаны для последней группы. Но если у первой группы указать приоритет выше остальных групп, то её права будут выше. Это может пригодится, например, если пользователям группы «Администратор» разрешить доступ, а другой группе, добавленной ниже, запретить. Тогда, если пользователь является членом обоих групп, а у группы «Администратор» приоритет выше, то доступ для пользователя будет открыт. Это что касается приоритета групп. А ещё есть приоритет записей прав.
У записи «Все» наименьший приоритет. У пользователя — максимальный приоритет. Т.е. если группе пользователей дан доступ к ресурсу, а пользователю, входящему в данную группу — нет, то для него этот ресурс будет недоступен и он будет перенаправлен на страницу, указанную в системной настройке unauthorized_page.
Чтобы наоборот, только гости могли видеть страницу, добавляем:
1. «Все» со значением «Запретить».
2. «Гости» со значением «Разрешить».
В общем, пробуйте. Версия пока бета, но ошибок не замечено.
Данное решение достаточно простое — у ресурса добавляется вкладка «Права доступа» и в ней можно перечислить, кому показывать страницу, а кому нет. Причём в привычном для многих стиле операционной системы.
Принцип работы
Включается этот механизм системной настройкой admintools_alternative_permissions. После этого у ресурса будет доступна вкладка «Права доступа». Если права не указаны, то ресурс доступен всем без ограничений. Как только добавили права, начинает работать проверка.Чтобы добавить запись, нажимаем кнопку "+ Добавить" и выбираем нужную строчку в списке «Группа/пользователь».
Первые 2 строчки списка — «Все» и «Гости». Думаю, тут пояснять не нужно. Дальше идут группы. Они выделены жирным шрифтом и обозначены иконкой с несколькими пользователями. Затем перечисляются пользователи (иконка с одним пользователем). Если выбрана группа пользователей, то становится доступным поле «Приоритет». Поясню, зачем оно нужно.
Проверка прав идет последовательно в порядке создания записей. Если указано несколько групп, то права пользователя будут такие, какие указаны для последней группы. Но если у первой группы указать приоритет выше остальных групп, то её права будут выше. Это может пригодится, например, если пользователям группы «Администратор» разрешить доступ, а другой группе, добавленной ниже, запретить. Тогда, если пользователь является членом обоих групп, а у группы «Администратор» приоритет выше, то доступ для пользователя будет открыт. Это что касается приоритета групп. А ещё есть приоритет записей прав.
У записи «Все» наименьший приоритет. У пользователя — максимальный приоритет. Т.е. если группе пользователей дан доступ к ресурсу, а пользователю, входящему в данную группу — нет, то для него этот ресурс будет недоступен и он будет перенаправлен на страницу, указанную в системной настройке unauthorized_page.
Пример
Чтобы закрыть страницу от неавторизованных пользователей, достаточно добавить одну запись «Гости» и запретить им доступ. Всего одно действие! И сравните с обычной настройкой MODX. Чувствуете разницу?Чтобы наоборот, только гости могли видеть страницу, добавляем:
1. «Все» со значением «Запретить».
2. «Гости» со значением «Разрешить».
В общем, пробуйте. Версия пока бета, но ошибок не замечено.
24 августа 2016, 14:04
Поблагодарить автора
Отправить деньги
Комментарии: 25
А что будет если пользователь состоит в нескольких группах, с одинаковым приоритетом но одной группе разрешено, другой нет?
И что за приориет записи прав?
Что будет с дочерними ресурсами, в случае если ограничить доступ к родителю?
А так это очень нужное добавление, однозначно в избранное и плюс автору!
Если указано несколько групп, то права пользователя будут такие, какие указаны для последней группы.Получается что группа указана последней будет приоритетнее?
И что за приориет записи прав?
Что будет с дочерними ресурсами, в случае если ограничить доступ к родителю?
А так это очень нужное добавление, однозначно в избранное и плюс автору!
Получается что группа указана последней будет приоритетнее?Да. Я так и написал.
И что за приориет записи прав?Возможно 2 варианта —
1. Приоритет записей — последовательная проверка добавленных прав.
2. Приоритет прав — например, «запрещение» выше «разрешения».
Я выбрал первый вариант, у него больше возможностей.
Логика такая:
1. Запись «Все» — имеет наименьший приоритет. Может быть только одна такая запись.
2. Запись с группой пользователей — перебивает права, указанные в записи «Все». Групп можно указать несколько.
3. Запись с пользователем — имеет наивысший приоритет. Перебивает права групп и записи «Все». Каждый пользователь может быть указан только один раз.
Так как групп может быть несколько, то для них как раз и вводится ещё один приоритет.
Что будет с дочерними ресурсами, в случае если ограничить доступ к родителю?Так же как и в родном механизме MODX — права родителя не влияют на дочерний ресурс. Но думаю, такая возможность будет не лишний. Спасибо за идею.
Приветствую Сергей!
Интересует пункт с правами родителя и дочерних документов.
Попробовал выставить права
Я полагаю такой функционал не сделан?
Подскажите пожалуйста как проще ограничить доступ к дочерним ресурсам? дочерних ресурсов много в ручную конечно же не вариант(все-таки 21 век)
Мысль написать плагин, чтобы слать всех на страницу авторизации если не авторизирован, но это как то «велосипедно», хотелось бы по уму.
Интересует пункт с правами родителя и дочерних документов.
Попробовал выставить права
- все - запрещено
- гости - запрещено
- Users - разрешеноЯ полагаю такой функционал не сделан?
Подскажите пожалуйста как проще ограничить доступ к дочерним ресурсам? дочерних ресурсов много в ручную конечно же не вариант(все-таки 21 век)
Мысль написать плагин, чтобы слать всех на страницу авторизации если не авторизирован, но это как то «велосипедно», хотелось бы по уму.
Я полагаю такой функционал не сделан?Нет, не сделан.
Самый простой вариант проверять права у родителя текущего ресурса. Нужно создать плагин на событие OnLoadWebDocument:
$AdminTools = $modx->getService('admintools');
if ($modx->getOption('admintools_alternative_permissions', null, false) && !$AdminTools->hasPermissions($resource->parent)){
$modx->sendUnauthorizedPage();
}
По моему если вынести в отдельный пакет, то получится схожий с этим modstore.pro/packages/users/modaccessmanager
Мне кажется, что в любом случае просто оберткой дополнение это быть не может, т.к. из коробки MODx заставить распределять доступы для отдельных страниц конкретным пользователям, можно разве что через создание групп пользователей для каждого пользователя. Судя по изменениям кода MODx в последних версиях, что-то в ближайшее время намечается новое, но все равно это из разряда наделок на будущее.
Сергей, спасибо за проделанную работу!
Действительно когда приходилось возится с правами это занимало уйму времени.
Еще хотелось бы чтоб в пакет admintools входила похожая штука как AjaxManager. Т.к. AjaxManager давно уже не обновляется и поглючивает когда устанавливаешь на текущие версии модх, а Вы занимаетесь админкой и название(admintools) подходящее, было бы круто чтоб похожий плагин(который работает на свежих версиях нормально) входил в Ваш пакет.
Действительно когда приходилось возится с правами это занимало уйму времени.
Еще хотелось бы чтоб в пакет admintools входила похожая штука как AjaxManager. Т.к. AjaxManager давно уже не обновляется и поглючивает когда устанавливаешь на текущие версии модх, а Вы занимаетесь админкой и название(admintools) подходящее, было бы круто чтоб похожий плагин(который работает на свежих версиях нормально) входил в Ваш пакет.
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
Здесь упомянуты:
| Компонент | Текущая версия | Закачки |
| AdminTools | 1.15.2-pl от 28.09.2020 | 3 486 |
| modAccessManager | 1.0.1-rc от 08.01.2016 | 134 |
| miniShop2 | 4.4.0-pl от 06.08.2024 | 26 122 |
20 декабря 2024, 19:42
Подскажите а как написать путь к файлу пресетов если папка core вынесена за пределы public_html и переименована?
выдает ошибку что путь к пресетам за...
20 декабря 2024, 13:32
Я-то понял :)
Исправил, может так понятнее будет.
20 декабря 2024, 07:11
вы были правы, благодарю
20 декабря 2024, 00:21
Превьюшки нашел.
Они в этом массиве [_embedded][items][номер файла][sizes]
Остался вопрос с кешированием
19 декабря 2024, 21:35
Попробуйте поменять
'tplFilter.row.msoc|color' => '@FILE chunks/tpl.mfilter2.filter.checkbox.color.tpl'на
'tplFilter.row.msoc|color~value~color' ...
19 декабря 2024, 21:22
Никак, но вот тут есть лайфхак
19 декабря 2024, 18:58
Я сильно поздно, но если вдруг нужно, пишите, помогу