Практикум Zend Framework. Часть третья: Zend_Acl

[Anexroid]

Огромное спасибо, как и заказывал, так сказать

[Anexroid]

Единственное, что забыли — про консультантов, но как их добавлять — понятно.

[dizballanze]

Рад помочь

[twi]

Честно говоря, не вижу в вашей статье преимуществ по сравнению с мануалом zendframework.com/manual/ru/zend.acl.introduction.html

[dizballanze]

Более расширенный практический пример по сравнению с тем что в мануале

[Voenniy]

Есть юзер Вася, который входит в группу admin5

Однако, именно этому юзеру надо добавить ещё некоторые привелегии, которых нету у группы admin5
Как это реализовать?

Как вообще в базе хранить права того или иного юзера?

И очень хотелось бы увидеть реализацию Acl на основе хранения прав в базе.

[dizballanze]

admin5 это не группа — это как раз таки конкретный админ Вася.
Вариантов хранения может быть очень много и они сильно зависят от того какие права нужно хранить.

[Voenniy]

Ок.
Но а как релизовать то, что я написал? Т.е. если есть группа admin5 и Васе надо добавить ещё прав, кроме тех, которые прописаны в группе? Делать двойную проверку для группы и для юзера?

[dizballanze]

Нет, просто расширить иерархию ролей, сделать каждого админа отдельной ролью, которая наследует от группы адмнов, а затем переопределить для него правило и проверять только для роли конкретного админа

[Voenniy]

Т.е. в данном случае надо будет всегда проверять не группу а именно юзера, правильно?

Вообщем мысль я уловил, спасибо :)

[dizballanze]

Да, все верно, нужно проверять юзера

[easterism]

$this->allow('admin-5', 'какой-то ресурс', 'какие-то права');

Автор не упомянул, что наследование ролей не является обязательным условием

[easterism]

когда уже хабр перестанет сам постить?

ну так вот… в мануале по Zend_Acl все хорошо расписано. Кроме того есть описание расширенного варианта, когда доступ нужен в зависимости от критериев.
В готовой реализации Acl на основе хранения прав в базе нет смысла, просто потому, что это никак не связанные сущности. Acl лишь регистрирует в себе абстрактные списки ролей, ресурсов и прав и обеспечивает между ними взаимосвязь. А как и где вы храните эти списки, исключительно ваша забота.

[resurection]

Ещё было бы интересно как реализовать такой уровень доступа:
role может редактировать только свои записи в resource

Например: модераторы могут редактировать только свои собственные новости; или юзеры могут редактировать только свои собственные комментарии. Админы при этом могут редактировать все комментарии и все новости.

[dizballanze]

Можно попробовать реализовать при помощи assertions

[eyeless]

в принципе у меня есть такая готовая система связанная вместе с доктриной 2, но можно использовать и отдельно, именно то что вам нужно, если интересует напишите мне.

[alexpogodin]

Интересует! Причем больше интересует именно связка с Doctrine2. Можно где-то глянуть?

[Anexroid]

Единственное, я так понял, что если будут добавляться еще админы — надо будет добавлять отдельно роли? Или можно как то сделать это при чтении из БД?

[dizballanze]

Да, в посте про это есть

[maxidler]

Вот всегда напрягали названия методов в Zend_Acl
AddRole — понятно
add — что add, куда add? Почему на AddResource?
$this->add(new Zend_Acl_Resource('admin_res'));
Я бы переписал, как $this->addResource('admin_res'), а уже внутри метода обворачивал бы в Zend_Acl_Resource
Кстати можно это сделать как раз в классе-наследнике.
Иногда очень странные решения и интерфейсы появляются у хороших и больших дядек и тетек…

[dizballanze]

Да, согласен, название не очень удачно выбрано