как лучше проверять права доступа?

[Духовность™]

как лучше проверять права доступа?

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

Варианты:

1. Принудительно проверять каждое действие на уровне колетроллера-родителя
2. Проверять вручную, всавляя метод проверки прав в каждый необходимый action:

public function action() 
{
    if (!$rules->check($user)) ... // header: Location  

}

Сейчас в админке использую вариант 1. Напрягает, что приходится на каждый public action писать право.

 

[CHEM_Eugene]

В свое время сделал для этого некое подобие АОП. В каждый контроллер добавляешь _call и именуешь те медоды, которые хочешь ограничить по правам каким-нибудь префиксом. Ну и правило для него пишешь.

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

Из твоих вариантов выбрал бы второй за гибкость.

 

[Alexandre]

за 2) - проверять только защищенные методы
я бы прикрутил кеширование в Autorizer

 

[Farsh]

В symfony, например, по умолчанию доступ есть ко всем action'aм. Если нужно что-то ограничить, то создается конф. файл, где можно указать фильтры доступа к какому-либо action'y : нужно ли быть авторизованным, какие должны быть credential'ы. После этого при запросе в одном из начальных фильтров идет проверка соответствия юзера этим фильтрам.
p.s. помоему удобно

 

[tf]

и замени вызов на

$rules->checkAccess($user);

 

[Активист]

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

 

[Духовность™]

не умею

 

[atv]

Я использую набор декораторов. Если необходимо ограничить доступ к компоненту, то используется один из декораторов, в котором и помещена логика проверки прав.

 

[Духовность™]

госсподя, какие вы тут страшные вещи то пишите.. декораторы.. битовые операции. кэширование... я щас испугаюсь и убегу.

 

[tf]

а как лучше права устанавливать?
хочется себе добавить вменяемый инструмент для установки прав
хранить в базе названия модулей, честно сказать, не очень охото, зато есть фс, где контролеры распиханы по папкам
news/edit
news/list
news/part/edit
news/part/list

хочу на основе этого строить дерево модулей
плюсы - можно права поставить сразу на news, news/part/, news/part/edit ресурc с id=5
минусы, непонятна необходимость дублирования, для разрешения операций с объектом id=5, для news/part/edit и news/part/list
можно это конешно решить путем наследования прав list от edit

 

[vegaplex]

лично я юзаю слегка облегчённый http://phpgacl.sourceforge.net/ , гибкости задания прав хватат как-бы на всё.

Автор оригинала: tf
где контролеры распиханы по папкам
news/edit
news/list
news/part/edit
news/part/list

я правильно понял - news, part и list это всё контроллеры, не екшины? тогда как права на екшины раздавать будите, используя этот подход?
разумеется, не вопрос "как это сделать", вопрос - зачем
не нравится БД - юзайте конфиги (xml например, разнесённый по папкам модулей верхнего уровня)

зы: для себя решил придерживаться "стандарта" ACL и не замарачиваться... разумеется, это всё ИМХО

-~{}~ 15.07.09 03:02:

Автор оригинала: atv
Я использую набор декораторов.

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

 

[Alexandre]

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

все правила реализуются как массив и имеплементируется в кеш

 

[tf]

"стандарта" ACL

и что это за стандарт в твоем понимании?

пока остановился на xml конфиге правил, и затем на основе их можно будет в админке устанавливать права на действия

для новостей у меня получилось вот такое нечто, для товаров соответсвенно http://phpclub.ru/paste/index.php?show=2311
elements - список контролеров подчиняющихся правилам
childs - правила подчиняющиеся этому

<?xml version="1.0"?>
<rules>
	<rule name="news">
		<elements>
			<element>edit</element>
			<element>list</element>
		</elements>
	</rule>
	<rule name="news.part">
		<elements>
			<child>part/edit</child>
			<child>part/list</child>
		</elements>
		<childs>
			<child parent="part">news</child>
		</childs>
	</rule>
</rules>

-~{}~ 20.07.09 17:04:

Я использую набор декораторов. Если необходимо ограничить доступ к компоненту, то используется один из декораторов, в котором и помещена логика проверки прав.

и насколько это удобно?

 

[atv]

и насколько это удобно?

Так как у меня стандартный набор компонентов (кнопка, поле ввода, форма, страница и т.д.), то для них используется стандартный набор декораторов.

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

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