Комментарии 19
Так это же разные вещи? Yii::app()->getModule('user') вернет экземпляр CModule, а Yii::app()->user вернет CWebUser
+4
все необходимые методы модуля теперь в Yii::app()->user, т.е. для получения данных любого юзверя достаточно написать Yii::app()->user->user($user_id)
так же атрибуты моделей user и profile (Yii::app()->user->first_name) что удобно использовать в лейаутах
так же атрибуты моделей user и profile (Yii::app()->user->first_name) что удобно использовать в лейаутах
+1
Такие костыли ни к чему, достаточно у роли Authenticated в Business rule прописать return !Yii::app()->user->isGuest;
0
Ооо, про знакомое и близкое пишут))
Я эти два модуля именно в такой связке и юзаю.
Есть еще моя ветка в репозитории Yii-user с мелкими правками, без которых (лично мне) никак, в основном это вынос всего что чаще всего приходится кастомизировать в конфиг, чтобы можно было обвешать проектно-специфическими миксинами, фильтрами, обработчиками событий.
Я эти два модуля именно в такой связке и юзаю.
Есть еще моя ветка в репозитории Yii-user с мелкими правками, без которых (лично мне) никак, в основном это вынос всего что чаще всего приходится кастомизировать в конфиг, чтобы можно было обвешать проектно-специфическими миксинами, фильтрами, обработчиками событий.
0
Могу вставить свои пять копеек:
1) От общего контроллера конечно же не обязательно наследоваться.
У меня в проектах все контроллеры наследуются от класса Controller, который создается по дефолту консольными инструментам и это, можно сказать, неписаное правило (а может и есть какие-то рекомендации), наследовать все свои контроллеры не напрямую от CController, а от Controller (очень многие разработчики расширений именно так и делают), который в свою очередь является прекрасным способом внедрения проектно-специфческого функционала в 3rd-party расширения без вмешательства в их код.
Так вот, еще одна хорошая практика — мерджить фильтры каждого контроллера с фильтрами родительского класса, если нужно что-то добавить.
И если мы используем такой подход, не нужно в сотнях мест что-то править, достаточно добавить фильтр модуля Rights в класс Controller.
2) Раздел «на сладкое» я бы рекомендовал убрать/перечеркнуть, т. к. это, как уже сказали, реализуется бизнес-правилами (!Yii::app()->user->isGuest;) и не нужно ничего хранить в базе для каждого пользователя.
Кстати, аналогично можно написать бизнес-правило для определения админов, чтобы не городить лишнего: UserModule::isAdmin();
(я так и делаю)
1) От общего контроллера конечно же не обязательно наследоваться.
У меня в проектах все контроллеры наследуются от класса Controller, который создается по дефолту консольными инструментам и это, можно сказать, неписаное правило (а может и есть какие-то рекомендации), наследовать все свои контроллеры не напрямую от CController, а от Controller (очень многие разработчики расширений именно так и делают), который в свою очередь является прекрасным способом внедрения проектно-специфческого функционала в 3rd-party расширения без вмешательства в их код.
Так вот, еще одна хорошая практика — мерджить фильтры каждого контроллера с фильтрами родительского класса, если нужно что-то добавить.
И если мы используем такой подход, не нужно в сотнях мест что-то править, достаточно добавить фильтр модуля Rights в класс Controller.
2) Раздел «на сладкое» я бы рекомендовал убрать/перечеркнуть, т. к. это, как уже сказали, реализуется бизнес-правилами (!Yii::app()->user->isGuest;) и не нужно ничего хранить в базе для каждого пользователя.
Кстати, аналогично можно написать бизнес-правило для определения админов, чтобы не городить лишнего: UserModule::isAdmin();
(я так и делаю)
+3
А не подскажете, как можно реализовать наложение политик на поля в профиле пользователя? То есть условно пользователь А в зависимости от роли видит или не видит какую-то информацию в профиле пользователя B.
0
править шаблон
Yii::app()->user->checkAccess('Role'); ни кто не отменял )
Yii::app()->user->checkAccess('Role'); ни кто не отменял )
0
Про шаблон это так. Но я говорю про то, чтобы каждый атрибут модели сделать объектом политики безопасности. И на мой взгляд это должно решаться в контроллере. И такое решение будет более универсальным.
0
Я использовал долгое время свое, но, его приходилось каждый раз допиливать, со временем скорость написания с нуля стала соизмерима скорости прикрутки и доработки готового решения. Поэтому использую всего одно расширение сейчас — для работы с формами.
0
чтобы rights заинсталилось без лишних телодвижений нужно не включать сразу этот модуль в конфиге, а сначала заинсталить user, авторизоваться под админом, и уже после включить модуль rights, а за тем перейти по адресу /index.php?r=rights/install
0
Полезно было бы добавить о возможности заменить названия таблиц для модуля Rights (опция 'tablePrefix' не поддерживается).
'components' => array(
'authManager' => array(
// ...
'itemTable' => 'yii_AuthItem',
'itemChildTable' => 'yii_AuthItemChild',
'assignmentTable' => 'yii_AuthAssignment',
),
),
0
Я не являюсь разработчиком данного расширения.
github.com/schmunk42/yii-rights
Форкайте на здоровье )
github.com/schmunk42/yii-rights
Форкайте на здоровье )
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как заставить работать расширения yii-user и rights совместно?