Zend_Db + Zend_Acl = ограничение доступа к записям || вопросы извращенца

Зуфар Самигуллин

unread,

Apr 12, 2010, 2:01:14 PM4/12/10

to ru-zend-framework

Никак не могу понять как можно ограничить доступ группам пользователей
к записям бд

Имеем таблицу категорий информационных материалов

Нужно при помощи Zend_Acl гостям разрешить просматривать только
Новости компании притом так чтобы мы не получали лишних данных из БД

Александр Ильин

unread,

Apr 12, 2010, 3:35:21 PM4/12/10

to ru-zend-...@googlegroups.com

Прочитай соответствующий раздел мануала, и статьи на зендфреймворк.ру

12 апреля 2010 г. 22:01 пользователь Зуфар Самигуллин <prof...@gmail.com> написал:

--
To unsubscribe, reply using "remove me" as the subject.

Зуфар Самигуллин

unread,

Apr 12, 2010, 9:04:51 PM4/12/10

to ru-zend-framework

Спасибо за исчерпывающий ответ, но я везде искал уже... ничего не
нашол..

On 12 апр, 23:35, Александр Ильин <mecomma...@gmail.com> wrote:
> Прочитай соответствующий раздел мануала, и статьи на зендфреймворк.ру
>
> 12 апреля 2010 г. 22:01 пользователь Зуфар Самигуллин

> <profb...@gmail.com>написал:

Alexander Steshenko

unread,

Apr 12, 2010, 9:31:53 PM4/12/10

to ru-zend-...@googlegroups.com

Искать костыли, несколько есть вроде типа в гугл Zend_Acl + db

либо писать самому, причем в том что придется писать самому Zend_Acl уже скорее всего и не понадобится.

ничего приличного готового для организации действительно универсального acl на php я не видел. хотя попадаются (В том числе кажется на нашем форуме (zendframework.ru) схемы бд близкие к правде)

Это один из моментов (acl вообще), переосмысливания и перереализации в том или ином виде которого ждут очень многие разработчики. (либо в виде переделанного Zend_Acl или может быть многообещающий Zend_Rbac)

2010/4/13 Зуфар Самигуллин <prof...@gmail.com>

--
Alexander Steshenko | http://lcf.name

matera.ttp

unread,

Apr 13, 2010, 1:45:13 AM4/13/10

to ru-zend-...@googlegroups.com

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

ЗЫЖ И в чем принципиальное отличие Rbac? По моему те же яйца.

Alexander Steshenko

unread,

Apr 13, 2010, 2:03:39 AM4/13/10

to ru-zend-...@googlegroups.com

Это мне? Или для топик стартера?

Хотя в обоих случаях первая часть заявления вводит в ступор. Если уж прямо ВСЮ логику вы должны реализовать сами, тогда как следствие становится совершенно не понят нафиг нужен вообще инструмент. А когда вы поймете какую часть логики реализует обсуждаемый "инструмент", изучите его и на практике использования узнаете какие там есть узкие места - тогда вам автоматически станет понятно о чем спрашивал автор или то что ему ответил я.

По поводу второй части - вся информация есть в сети, почитайте госты, если интересно чем rbac отличается и каким образом он лучше чем mac и dac. Хотя я имел в виду не эти отличия, а то как он будет реализован. Это просто вариант развития событий, если Zend_Acl по человечески перепишут с нуля это также устроит практически всех я думаю.

2010/4/13 matera.ttp <huma...@gmail.com>

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

ЗЫЖ И в чем принципиальное отличие Rbac? По моему те же яйца.

Jurij Bachkov

unread,

Apr 13, 2010, 2:52:34 AM4/13/10

to ru-zend-...@googlegroups.com

А что в Zend_Acl плохого? Мне лично кажиться он со своей задачей справляется на ура, и к тому же относительно гибкая вещь для довольно не простой задачи, где обычно все решения довольно узкоспециализированные.
Обычно вся проблема в том, что программист пытается динамически поменять роль, исходя из ресурса. Я считаю этого делать нельзя, надо менять ресурс. Типа если пользователь не является автором текста, то ресурс "просто текст" иначе ресурс "мой текст". И не в коем случае нельзя менять роль, типа если пользователь не является автором текста, то он "просто пользователь" иначе он "модератор". С таким вот простым подходом Zend_Acl сразу становится довольно удобным инструментом.
А RBAC - только усложнит программу. Может он нужен в каких нибудь огромных корпоративных сетях, но в прекладном веб программировании, где обычно не больше 10 типа ресурсов я считаю что это излишек.

2010/4/13 Alexander Steshenko <lcf...@gmail.com>

Alexander Steshenko

unread,

Apr 13, 2010, 3:19:47 AM4/13/10

to ru-zend-...@googlegroups.com

Ммм.. не совсем понял что с чем вы сравниваете...

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

Я не понял про "динамическое изменение роли" тоже. Первый раз слышу о таком приеме и могу только догадываться что это значит. Про изменение ресурса и пример про модератора/пользователя/их текст аналогично, впрочем.

Если под прИкладным веб программированием вы имели в виду типовые сайтики (самые простейшие варианты), тогда я могу согласится с утверждением про количество ресурсов, однако во многих веб проектах количество ресурсов/ролей велико, а иерархия их сложна, поэтому для хранения/работы с ними и используются такие инструменты как реляционные базы данных. Из чего и вытекает поставленный вопрос.

Вообще, я высказал свое мнение для автора исключительно в контексте решения задачи управления acl на основе данных из БД. Перед тем как спрашивать что плохого в Zend_Acl, предлагаю сначала предложить автору решение его задачи, хотя бы в описательном порядке.

2010/4/13 Jurij Bachkov <unrea...@gmail.com>

Jurij Bachkov

unread,

Apr 13, 2010, 3:22:35 AM4/13/10

to ru-zend-...@googlegroups.com

Зуфар Самигуллин - я бы на твоём месте дополнил таблицу типом ресурса, и дёргал тексты в зависимости от роли. Так будет лучше и быстрей, чем например загонять всё это дело в ACL или в RBAC

2010/4/13 Alexander Steshenko <lcf...@gmail.com>

matera.ttp

unread,

Apr 13, 2010, 3:23:50 AM4/13/10

to ru-zend-...@googlegroups.com

Вам я задал один конкретный вопрос, но раз уж вы ответили "умничеством" вместо конкретного ответа.

Знаете есть инструмен лопата? Вот эта самая лопата сама огород вам не вскопает. ВСЮ работу по вскапыванию огорода вы делаете сами. Что именно в этой простой истине ввело вас в ступор?

Бегло осмотрев интерфейс взаимодействия я ее не увидел. Отсюда опять вопрос, в чем принципиальная разница?
Еще один вопрос вам, Zend_Acl это rbac или нет?

FYI когда говорится о логике, почти всегда имеется в виду логика приложения.

2010/4/13 Alexander Steshenko <lcf...@gmail.com>

Это мне? Или для топик стартера?

Хотя в обоих случаях первая часть заявления вводит в ступор. Если уж прямо ВСЮ логику вы должны реализовать сами, тогда как следствие становится совершенно не понят нафиг нужен вообще инструмент. А когда вы поймете какую часть логики реализует обсуждаемый "инструмент", изучите его и на практике использования узнаете какие там есть узкие места - .

Alexander Steshenko

unread,

Apr 13, 2010, 3:58:31 AM4/13/10

to ru-zend-...@googlegroups.com

Значит я вас не правильно понял. Подумал все сообщение предназначалось мне.

Насчет умничества, почему же... ну загуглите "сравнение rbac, mac и dac, ограничения", если интересно, что уж тут заумного.

Насчет примера про лопату... у нас с вами очевидно разные понимания работы, будь то физическое понятие или что-то более бытовое. С моей точки зрения при любых вариантах лопата делает часть работы. Ну да ладно.

Про "логику приложения". Скажите, если я для своего приложения разработаю альтернативу Zend_Acl с гибкой системой хранения данных о ресурсах, ролях и тд и тп - будет ли это считаться "логикой приложения"?

Что такое логика приложения вообще по вашему и откуда вы взяли определение... Не очередное ли это "лично для меня mvc это..."? :)

Может быть под "логикой приложения" вы имели в виду "бизнес логику"? Если да, то с точки зрения бизнес процессов конечно должно быть фиолетово как там реализован метод isAllowed(...) внутри. Вопрос то автор задал не про бизнес логику, очевидно. Или нет?

Отвечаю на вопрос Zend_Acl можно назвать реализацией Rbac, да.

Отвечаю на вопрос про принципиальную разницу - разница чего? способов реализации acl? или Zend_Acl или Zend_Rbac? я говорил что-то про принципиальную разницу между конкретно этими компонентами фреймворка? Я наоборот дважды сказал и повторяю - что если сделают нормально Zend_Acl то это всех или почти всех устроит. Под словом "многообещающий" Zend_Rbac я имел в виду то что вроде по нему хоть что-то делалось а тикеты по Zend_Acl давно и старательно игнорируются (эти сведения я уже не проверял несколько месяцев но не думаю что ситуация сильно изменилась...)

2010/4/13 matera.ttp <huma...@gmail.com>

Jurij Bachkov

unread,

Apr 13, 2010, 3:58:46 AM4/13/10

to ru-zend-...@googlegroups.com

Знаете есть инструмен лопата? Вот эта самая лопата сама огород вам не вскопает.

Про лопату понятно, но тут вопрос надо ставить по другому, можно ли лопатой полоть клубнику. В данном случае, если надо сделать выборку текстов из ДБ, то я не уверен что надо прикручивать RBAC...

2010/4/13 matera.ttp <huma...@gmail.com>

Андрей Касьян

unread,

Apr 13, 2010, 4:44:31 AM4/13/10

to ru-zend-...@googlegroups.com

http://github.com/kandy/system/blob/master/System/Acl/Loader/Db.php

2010/4/12 Зуфар Самигуллин <prof...@gmail.com>:

matera.ttp

unread,

Apr 13, 2010, 5:08:24 AM4/13/10

to ru-zend-...@googlegroups.com

"Может быть под "логикой приложения" вы имели в виду "бизнес логику"?"

именно

"разница чего?"
Разница в использовании этого инструмента/библиотеки для разработчика. Если интерфейс взаимодействия не изменится, то и разницы разработчику от этого никакой.

"если я для своего приложения разработаю альтернативу Zend_Acl с гибкой системой хранения данных о ресурсах, ролях и тд и тп - будет ли это считаться логикой приложения?"

Систему хранения можно и отдельно построить, зачем весь Асл переписывать. Для меня как разработчика который будет использовать вашу систему хранения она никакой логики не несет. Логикой как раз есть тот факт что для гостей ми даем доступ только к новостям.

Например по вопросу топикстартера.


<?php

$acl = new Zend_Acl();

...

// грузим наши роли, права и т.д., и нам в общем побоку где они хранятся и 

// какой инструмент мы используем



if ($acl->isAllowed($role, 'materials/all')) {

    $materials = $model->getMaterials();

} else {

    $materials = $model->getNews();

}

Как то чем вы пользуетесь и где у вас хранятся роли/ресурсы/права может помочь вам в этом?

"Нужно при помощи Zend_Acl гостям разрешить просматривать только Новости компании притом так чтобы мы не получали лишних данных из БД"

Эту логику нужно реализовать кодом и никакая библиотека за вас это не сделает, это то что я хотел сказать(сказал) в своем первом посте автору темы.

Orin

unread,

Apr 13, 2010, 5:43:07 AM4/13/10

to ru-zend-...@googlegroups.com

пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅ, пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅ-пїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅ пїЅпїЅпїЅпїЅпїЅ-пїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ, пїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅ пїЅ пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ )

пїЅпїЅпїЅпїЅпїЅпїЅ, пїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅ,пїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅ пїЅ.пїЅ. пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ, пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅ пїЅпїЅпїЅ, пїЅ пїЅпїЅ пїЅпїЅ пїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅ пїЅпїЅ пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅ.

--- пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ ---
пїЅпїЅ пїЅпїЅпїЅпїЅ: "matera.ttp" <huma...@gmail.com>
пїЅпїЅпїЅпїЅ: ru-zend-...@googlegroups.com
пїЅпїЅпїЅпїЅ: Apr 13, 2010 12:08:24
пїЅпїЅпїЅпїЅ: Re: [ru-zend-framework:8466] Re: Zend_Db + Zend_Acl = пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ || пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ

"пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅ пїЅпїЅпїЅ "пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ" пїЅпїЅ пїЅпїЅпїЅпїЅпїЅ пїЅ пїЅпїЅпїЅпїЅ "пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ"?"
пїЅпїЅпїЅпїЅпїЅпїЅ

"пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅ?"
пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ/пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ. пїЅпїЅпїЅпїЅ
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ, пїЅпїЅ пїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅ пїЅпїЅпїЅпїЅпїЅ
пїЅпїЅпїЅпїЅпїЅпїЅпїЅ.

"пїЅпїЅпїЅпїЅ пїЅ пїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ Zend_Acl пїЅ пїЅпїЅпїЅпїЅпїЅпїЅ
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ, пїЅпїЅпїЅпїЅпїЅ пїЅ пїЅпїЅ пїЅ пїЅпїЅ - пїЅпїЅпїЅпїЅпїЅ пїЅпїЅ пїЅпїЅпїЅ
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ?"
пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅ пїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ, пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅ пїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ.
пїЅпїЅпїЅ пїЅпїЅпїЅпїЅ пїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ
пїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅ пїЅпїЅпїЅпїЅпїЅ. пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅ пїЅпїЅпїЅ пїЅпїЅпїЅпїЅ пїЅпїЅпїЅ пїЅпїЅпїЅпїЅ пїЅпїЅпїЅ пїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅ
пїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ.

пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ.

Alexander Steshenko

unread,

Apr 13, 2010, 11:53:55 AM4/13/10

to ru-zend-...@googlegroups.com

Автор спросил "Нужно при помощи Zend_Acl гостям разрешить просматривать только Новости компании притом так чтобы мы не получали лишних данных из БД"

Тщательно вчитайтесь в то что выделено жирным и подумайте как ваш кусок кода решает задачу. То есть из того куска кода что вы привели он спросил именно то, как реализовать то что у вас закомментировано / опущено:

// грузим наши роли, права и т.д., и нам в общем побоку где они хранятся и
// какой инструмент мы используем

Нам побоку? У меня в проекте тысячи ролей и тысячи ресурсов, предлагаете загружать все данные по acl из бд каждый запрос? Памяти не хватит. Это тонкости инфраструктуры, которые могут быть успешно разрешены в рамках фреймворка.

По поводу инструментов, интерфейсов, библиотек, работы, логики приложения, даже по поводу лопаты вы вообще не понимаете, что говорите. Либо, вы абсолютно не поняли ни вопрос ни ответы на него и рассуждаете тут о чем-то другом. В связи с этим, извините, не собираюсь продолжать эту дискуссию.

2010/4/13 matera.ttp <huma...@gmail.com>

matera.ttp

unread,

Apr 13, 2010, 1:16:54 PM4/13/10

to ru-zend-...@googlegroups.com

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

Я бы с радостью посмотрел как вы средствами Zend_Acl или вашей крутой системы показали всем как это правильно сделать, и как система хранения/загрузки прав/ролей влияет на конкретно обсуждаемую задачу(особенно второе), вместо того что бы твердить что "вы абсолютно не поняли ни вопрос ни ответы". Если вы все "поняли" так покажите решение задачи остальным вместо пустых слов.

2010/4/13 Alexander Steshenko <lcf...@gmail.com>

Автор спросил "Нужно при помощи Zend_Acl гостям разрешить просматривать только Новости компании притом так чтобы мы не получали лишних данных из БД"

Тщательно вчитайтесь в то что выделено жирным и подумайте как ваш кусок кода решает задачу. То есть из того куска кода что вы привели он спросил именно то, как реализовать то что у вас закомментировано / опущено:

// грузим наши роли, права и т.д., и нам в общем побоку где они хранятся и
// какой инструмент мы используем

Нам побоку? У меня в проекте тысячи ролей и тысячи ресурсов, предлагаете загружать все данные по acl из бд каждый запрос? Памяти не хватит. Это тонкости инфраструктуры, которые могут быть успешно разрешены в рамках фреймворка.

По поводу инструментов, интерфейсов, библиотек, работы, логики приложения, даже по поводу лопаты вы вообще не понимаете, что говорите. Либо, вы абсолютно не поняли ни вопрос ни ответы на него и рассуждаете тут о чем-то другом. В связи с этим, извините, не собираюсь продолжать эту дискуссию.

matera.ttp

unread,

Apr 13, 2010, 1:26:58 PM4/13/10

to ru-zend-...@googlegroups.com

Свое решение я привел, создать ресурс materials/all и дать на него права необходимым ролям. Если права на ресурс у пользователя есть, отдавать все материалы, иначе отдавать только новости. Укажите на ошибки или дайте правильное решение если оно неверное вместо того чтобы уходить от дискусии.

matera.ttp

unread,

Apr 13, 2010, 1:50:37 PM4/13/10

to ru-zend-...@googlegroups.com

По поводу того что вы выделили, как раз все новости и "притом так чтобы мы не получали лишних данных из БД" возвращает метод

$materials = $model->getNews();

например с флагом public

matera.ttp

unread,

Apr 13, 2010, 3:00:16 PM4/13/10

to ru-zend-framework

Jurij Bachkov

"я бы на твоём месте дополнил таблицу типом ресурса, и
дёргал тексты в зависимости от роли. Так будет лучше и быстрей, чем
например
загонять всё это дело в ACL или в RBAC"

вот это от части то что я имел ввиду, тоисть в асл заганять права на
критерии поиска(типы нодов), а не создавать ресурсы на каждую статью

Kirby Rs

unread,

Apr 13, 2010, 3:21:12 PM4/13/10

to ru-zend-...@googlegroups.com

Наблюдал эту "мягкую" дискуссию :), и думал что можно было бы добавить.

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

Пример.

Есть таблица с какими-то записями. У которых есть свойства: тип, цвет, размер.

Пишем в модели:

$params = array();

if ($acl->isAllowed('rec_type_video')) {

$params['type'][] = 'video';

}

if ($acl->isAllowed('rec_type_news')) {

$params['type'][] = 'news';

}

if ($acl->isAllowed('rec_color_red')) {

$params['color'][] = 'red';

}

if ($acl->isAllowed('rec_color_grey')) {

$params['color'][] = 'grey';

}

if ($acl->isAllowed('rec_size_big')) {

$params['size'][] = 'big';

}

if ($acl->isAllowed('rec_size_small')) {

$params['size'][] = 'small';

}

$this->_db->getItems($params);

.... //in db model

function getItems($params)

{

$select = $this->getAdapter()->select();

if (! empty($params['type']) {

$select->where('type IN (?)', $params['type'])

}

if (! empty($params['color']) {

$select->where('color IN (?)', $params['color'])

}

if (! empty($params['size']) {

$select->where('size IN (?)', $params['size'])

}

Это очень просто пример, и не претендует на эталон. Но думаю принцип понятен. Не думаю что что-то новое предложил, но что пришло на ум.

--
С уважением, Kirby :)

matera.ttp

unread,

Apr 13, 2010, 3:42:56 PM4/13/10

to ru-zend-...@googlegroups.com

Я понимаю еще если у нас действительно сложная система, где нам действительно нужно дать права на каждую запись отдельно, но в данном случае, где нужно просто выделить определенную часть новостей которые будут показыватся гостям, смысла в такой системе прав я не вижу. Проще эти новости как то выделить из всей кучи, флагом, параметрами(как выше) и т.д.

Constantine Karnacevych

unread,

Apr 13, 2010, 7:31:30 PM4/13/10

to ru-zend-...@googlegroups.com

О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫.
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫.
ACL О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.
О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫ - О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫ ACL
> О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
> О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫
>
> О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
>
> ID | TITLE | PARENT_ID
> 0 | О©╫О©╫О©╫О©╫О©╫О©╫О©╫ | null
> 1 | О©╫О©╫О©╫О©╫О©╫О©╫О©╫ | 0
> 2 | О©╫О©╫О©╫О©╫О©╫ | 0
> 3 | О©╫О©╫О©╫О©╫О©╫О©╫О©╫ | 0
> 4 | О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ | 3
>
> О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ Zend_Acl О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫
> О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫
>
>

Антон

unread,

Apr 14, 2010, 12:35:43 AM4/14/10

to ru-zend-framework

Скажите пожалуйста, а вы как то пытались ограничить доступ и не
получается (можно в этом случае поподробнее, о том как пытались) ИЛИ
вы совсем не можете понять как это сделать?

приведенная вами "таблица категорий информационных материалов" чем то
напоминает "дерево сайта" :о|

Kirby

unread,

Apr 14, 2010, 3:14:57 AM4/14/10

to ru-zend-framework

On 14 апр, 07:35, Антон <aqw.no...@gmail.com> wrote:
> приведенная вами "таблица категорий информационных материалов" чем то
> напоминает "дерево сайта" :о|

Ну да, если это меню-дерево сайта, т.е. надо ограничить доступ к
пунктам меню, то для это можно использовать Zend_Navigation, который
дружит с Zend_Acl.

Александр Ильин

unread,

Apr 14, 2010, 7:02:53 AM4/14/10

to ru-zend-...@googlegroups.com

/me достал линейку

matera.ttp

unread,

Apr 15, 2010, 4:34:17 AM4/15/10

to ru-zend-framework

Ну так поделитесь опытом, если кто использовал такие системы.
Представить себе ситуацию где на каждую запись в базе будут отдельные
Acl я себе представить не могу. По своему опыту могу сказать что такие
ситуации всегда разруливают кодом приложений и струтурой базы, а Acl
влияет только на запросы которые будут в результате выполнены для
получения данных или выполнения определенного действия. При чем либо
эти записи уже имеют какие либо отличия(идентификаторы, типы и т.д.),
либо эти отличия нужно добавить. И какая Acl используется и где она
хранит свои правила по моему никакой логической нагрузки не дает.

2Alexander Steshenko Вы уж извините что разговаривали на разных
языках, и не принимайте каждое мое высказывание как критику в свою
сторону.

Alexander Steshenko

unread,

Apr 15, 2010, 6:07:02 PM4/15/10

to ru-zend-...@googlegroups.com

Вы тоже извините, погорячился.

Такие ситуации разруливают в коде (то есть по сути усложняют бизнес логику там где это не нужно) с использованием всяких assertions или просто if elseif else if else....

Все варианты что видел я - в той или иной степени костыли, нарущающие абстракцию бизнес логики от других частей системы и узкозаточенные под какуюто определенную проверку.

Конечно оно может быть все зависит от того как эта бизнес логика спроектирована и того как на нее смотреть, но вообще это все расходится с тем за что в идеале должно отвечать acl.

Если делать без костылей, то есть acl отвечает за проверку всех аспектов прав доступа, то та ситуация которую вы не можете представить будет иметь место почти в любом приложении (не сайтике).

Не каждую запись в бд, но смотрите - каждый пользователь - роль, почти любая сущность - ресурс, который может принадлежать пользователю (приватный ресурс так сказать), быть расшаренным в какой-то группе пользователей и этим всем нужно управлять и где-то хранить. Это не вдаваясь в подробности по поводу разнообразия ресурсов и сложности их иерархии. Согласитесь, это (группы, пользователи, сущности) ведь почти типовые требования любого более менее сложного проекта. Просто загружать все правила для всех ролей/ресурсов/привилегий каждый запуск приложения (то есть каждый Http запрос) - не вариант, не важно беруться они из кеша или из бд, потому что их может быть оч много.

Подобный подход реализован (без Zend_Acl вообще), например в проекте, где я работаю - http://norada.com/, CRM система, не помню насчет фри аккаунта, кажется сейчас остался только trial, если есть желание - попробуйте зарегестрироваться. Или, может быть, сложность можно оценить посмотрев ролик который на главной.

Но. Сталкиваюсь с необходимостью делать что-то в этом духе я постоянно в процессе проектирования различных систем, не обязательно таких сложных как эта.

Для простых или сознательно плохо спроектированных вещей или содержащих определенные компромиссы я допускаю использование Zend_Acl со строго определенным набором ролей / ресурсов / правил для них, захардкоденых или даже гибридные подходы с хранением каких-то вещей в бд (как в статьях на codeutopia.net (всем кстати must read кто только начинает свой путь в понимании acl - там же есть ссылки на перевод любезно осуществленный Рашадом).

Но это все - компромиссы не решающие конкретно поставленную здесь задачу. И вместо того чтобы предложить решение, тут по сути все начинают говорить что задача плохая и скорее всего такое не понадобиться и что нельзя представить такую систему. Странно как-то. Хотя я не отрицаю того что автору, возможно, нужно что-то другое на самом деле, но сам вопрос более чем резонный.

В каком-то смысле для более общего случая сущностей доменной модели чем acl проблему эту (и не только) решают так называемые ORM, например Doctrine (особенно интересна 2ая версия, так как доменную модель она не ограничивает).

2010/4/15 matera.ttp <huma...@gmail.com>

--
To unsubscribe, reply using "remove me" as the subject.

dr.ZLO

unread,

Apr 16, 2010, 7:56:38 PM4/16/10

to ru-zend-framework

Для работы с данными, атрибутами таблиц - Zend_Acl не к чему. Вся
идеология
строится на работе уже EAV модели (сущность-атрибут-значение). Многие
программисты эту технологию не воспринимают и могут запинать кого
угодно.
Но технология живёт сама собой и решает многие задачи. Я не буду
описывать
как работает эта модель - инфы в интернете хватает. Скажу одно - ВЫ
уже
работаете не с плоскими таблицами, как привыкли - а таблицы строятся
вертикально. Совокупность таблиц - есть сущность entity, (бывшая
плоская
таблица, но только в 3-х мерном измерении :)

Имея такую структуру данных Вы можете на любой атрибут ставить
привилегии
и избавиться навсегда от if..elseif..else
Здесь Вам понадобиться написать свой инструмент для работы с данными,
я
говорю про модельку new Entity_Select('news'). Это ваша альтернатива
на
Zend_Db_Table + Zend_Db_Select, т.е собирать необходимо будет сущность
с
помощью механизма запросов. Работа с Entity_Select практически не
отличается от сути и интерфейса Zend_Db_Select. Дальше Вы уже сами
будете распоряжаться атрибутами сущности, что давать пользователю!?
Повторюсь, что технология имеет свои плюсы-минусы и для простых
смертных
она не подойдёт.
Я где-то видел у магента диаграммку на эту тему. Но реализация
модельки
у них туманное, скорее извращённое.

Желаю успехов!

--
Subscription settings: http://groups.google.com/group/ru-zend-framework/subscribe?hl=ru

Alexander Steshenko

unread,

Apr 17, 2010, 3:06:33 AM4/17/10

to ru-zend-...@googlegroups.com

А вот представить такую ситуацию что на разные атрибуты одной сущности нужны разные привилегии уже я не могу. Может быть пару примеров приведете из жизни?

Решение предложенное вами ближе к правде, хотя не совсем... и не совсем не раскрыто (это я про так называемый "Entity_Select"). Хотя возможно что-то другое имелось в виду. Вообще такая схема, если я правильно понял что вы предлагаете удобна только в случае применения Transaction Script или разновидности.

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

А насчет EAV... в проекте что я упомянул именно этот подход и используется, но я не упомянул об этом, потому что это фиолетово абсолютно. Ну вот только если не вешать привилегии на аттрибуты сущностей. А зачем это делать я не могу сходу придумать и жду примеров применения :)

2010/4/17 dr.ZLO <teleg...@gmail.com>

dr.ZLO

unread,

May 14, 2010, 8:11:29 PM5/14/10

to ru-zend-framework

> Alexander Steshenko |http://lcf.name

On 17 апр, 10:06, Alexander Steshenko <lcfs...@gmail.com> wrote:
> А вот представить такую ситуацию что на разные атрибуты одной сущности нужны
> разные привилегии уже я не могу. Может быть пару примеров приведете из
> жизни?

Сущность product имеет атрибуты name, description, price, dealer,
comment, img и т.д. Пользователю "editor" отображать данные name,
description, и img. Пользователю "manager" отображать данные ... price
и т.д. И это всё проходит на уровне запросов к БД без Zend_Acl. Т.е.
смысл прост - отображать/редактировать цену только людям которые
отвечают за стоимость товара. Простые смертные "editor" даже не знают
о её существовании. У каждого своя часть работы.

> Насчет того что Zend_Acl ни к чему для работы с данными, тут вы правы в том
> что с Zend_Acl задачу эту решить представляется невозможным, однако проблема
> глубже - Zend_Acl пригодился бы, как представитель домена, модель
> олицетворяющая бизнес логику процессов управления правами доступа.
> Скрывающий доступ к данным каким-бы то ни было, как бы то ни было хранящимся
> и так далее.

Zend_Acl я использую только для работы с ресурсами. Хотя его можно
юзать под всё что угодно - было бы за что и имело бы своё место

> А насчет EAV... в проекте что я упомянул именно этот подход и используется,
> но я не упомянул об этом, потому что это фиолетово абсолютно. Ну вот только
> если не вешать привилегии на аттрибуты сущностей. А зачем это делать я не
> могу сходу придумать и жду примеров применения :)

Вот как раз EAV модель решает многие проблемы по работе с данными (не
побоюсь этого слова "все проблемы"), т.к. она олицетворяет мощь ORM.
Вы можете давать доступ как к атрибутам так и к самим данным. Здесь
фантазия не имеет границ. Используется, как я сказал, для контроля/
ограничения доступа к данным. Вроде бы заголовок поста так и звучит...

Желаю успехов!

Reply all

Reply to author

Forward