Ох блин, как всё сложно! Уже 4 раза полностью пер
Ох блин, как всё сложно! Уже 4 раза полностью переписывал огромный комментарий с возникшими вопросами, но теперь вот окончательная версия) Во-первых, спасибо огромное за материал! Очень ценно! Ну и, собссна, во-вторых.
Какие у меня вопросы. Возьмём класс modResource. Есть шаблоны политик доступа:
- ResourceTemplate с разрешениями:
add_children copy create delete list load move publish remove save steal_lock undelete unpublish view
- И есть AdministratorTemplate с кучей разрешений, из которых нам интересны:
delete_document edit_document new_document new_document_in_root new_static_resource publish_document resource_duplicate resource_quick_create resource_quick_update resource_tree save_document tree_show_resource_ids undelete_document unpublish_document view_document
В этих списках есть как уникальные, так и политики-«синонимы»:
delete == delete_document create == new_document publish == publish_document copy == resource_duplicate save == save_document undelete == undelete_document unpublish == unpublish_document view == view_document
(при чём везде '_document', но 'resource_duplicate', очередная странность). И это при условии, что в шаблоне AdministratorTemplate так же есть простые load, list, view, create, delete, copy и т.д.
Я, конечно, понимаю, что политики из первого списка можно проверить только через modResource::checkPolicy(), а из второго списка через $modx->hasPermission(), но лично для меня ясности это нифига не вносит.
- В чём между ними в итоге разница-то?
- Какие политики надо назначать пользователям, для нужных разрешений? Первые? Вторые? И те и другие?
Здесь у меня ступор :-)
Примеры.
У modResource, как наследника modSimpleAccessibleObject, вшиты проверки на load, save и remove в соответствующие методы (например). Здесь проверяется локальная политика.
Предположим, что нам надо создать документ. И по сути, логично найти проверку на create где-нибудь в modSimpleAccessibleObject::newObject().
Так ведь нифига! Проверки на create ресурсов я вообще не нашёл! (может плохо искал?). Зато в процессоре на создание ресурса проверяется глобальная new_document через $modx->hasPermission().
Как такое понять??
Дальше, предположим, что нам надо опубликовать документ. Процессор modResourcePublishProcessor наследуется от modProcessor (кстати, почему бы ему сразу не отнаследоваться от modObjectProcessor, в котором уже прописан метод для проверки для глобальных прав?).
Как видно из метода modProcessor::run(), в нём сначала проверяются глобальные права (вызывается modResourcePublishProcessor::checkPermissions(), который возвращает $modx->hasPermission('publish_document')), а затем вызывается метод modResourcePublishProcessor::initialize(), который проверяет локальные права save и publish! Масло масляное? Мало того, ещё и при сохрании ресурса ещё раз проверится локальная политика save! Нафига? Нафига делать одно и тоже 2 раза?
Т.е. получается, что мало дать юзеру (ну группе этих юзеров) право publish_document из шаблона политик AdministratorTemplate, надо ещё и обязательно дать ему права save и publish из шаблона ResourceTemplate??
Вот об этом я ни разу не подозревал, сколько раз права настраивал. Видать не правильно настраивал?
Зачем вообще разделять тогда на глобальные и локальные? И так во многих процессорах — проверяются глобальные разрешения, потом те же, но локальные. Почему тогда не сделать все проверки глобальными и через процессоры?
Вот всего этого я не понимаю :-(
Изучая процессор resource/duplicate, я начал смутно представлять зачем нужны локальные политики — там внутри методов процессора есть проверки разрешения на добавление к родительскому ресурсу дочерних документов, т.е. как-то так:
if ($parentResource->checkPolicy()){
// ...
}
Да, здесь это, безусловно, оправдано. Но, исходя из вышеизложенного, картинка у меня всё-равно как-то не складывается.
Николай, помоги советом! А то я уже близок к тому, чтоб плюнуть на всё это и загулять))