Где лучше всего хранить параметры доступа ACL?

[Solid]

Где лучше всего хранить параметры доступа ACL?

Возник вопрос с хранением параметров прав доступа к страницам в Access Control List. Есть два варианта:

• hard-code'ить в каждом контроллере
• в БД

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

• Нагрузка базы;
• Сложность в реализации (не подскажите решения?);
• Возможно существуют и другие минусы... в общем-то именно по этому я сюда этот вопрос и запостил.

 

[Bred Vilchec]

Re: Где лучше всего хранить параметры доступа ACL?

У меня есть некоторый опыт в работе над access control'ерами. Точнее опенсорс проект разрабатывается невообразимо медленно, практически никак. Но пару советов дать постараюсь.

Нагрузка базы

Не уверен, что сколько-нибудь значительно. В нашей модели пользователь мог входить в несколько групп, были права групп на объекты и отдельных пользователей на объекты. Для выгрузки ACL из БД удалось обойтись одним простым запросом (на страницу). К тому же ACL можно закешировать, в сессии, например.

Сложность в реализации (не подскажите решения?);

Посмотрите Zend_Acl, у них вроде неплохо, но я не ковырял толком, поэтому не скажу.

Возможно существуют и другие минусы

Вроде нет. Скорее всего не стоит городить суперсложную схему с иерархией групп, ролей, объектов.

 

[ustas]

в базе, и кешируй навсегда, при изменении очищай. кстати кешировать можно все группы и права даже если больше 500 обьектов(все равно быстрей) кеш проверяй (мd5), по юзеру выбираешь его права, и в сессию. К базе можно подключаться только для регистрации юзера.

 

[Solid]

ustas
А что насчёт реазиации или "более продвинутой" теории?

 

[grigori]

Автор оригинала: Solid
А что насчёт реазиации или "более продвинутой" теории?

Вопрос был о выборе между 2х подходов, что имеется ввиду под "более продвинутой теорией" и в чем именно вопрос относительно реализации?

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