Implement RBAC about yii2 HOT 19 CLOSED

I think that storing PHP code processed with eval should be avoided (CdbAuthManager). That's not good for security. Any code injection could cause serious damages, not only to the app. Eval could run injected code that could harm the whole server. Even php.net warns about evals and recommands not to use it.
I think bizrules should be removed.
If a special logic has to be processed to check access, we should use classe inheritance.
I've found some posts of people saying they use Zend_Acl in Yii because of that problem, that's a pity.

Something nice would be to store a relation between the user table, the authitem table and any other table of the app corresponding to a model.
So it would be possible to store that a given user has a given authItem on a given record of the third table.

from yii2.

bizrules may be anonymous php functions stored in a config file like it is done with CPhpAuthManager.

from yii2.

@cebe what if backend isn't a PHP file?

from yii2.

The idea could be to put the code of the bizrule in the method of a class.
CheckAccess() would not call executeBizrule() anymore.
checkAccess() could have a parameter which could be the name of a class specific to the app that contains the logic of the bizrule. Then checkAccess would instanciate that class if given, and call a method of that class with $data as a parameter. That method will return a boolean.

from yii2.

Could adding behaviors to the AuthManager service be an option? The bizrule on an item should then contain the name of a bizrule. This bizrule name should be a method of the AuthManager service (a method of the AuthManager class or a method of a behavior added to the AuthManager service).
Such a method could be of the form bizMyRule. The item would then contain the bizrule 'myRule'.
This way it is also possible to supply commonly used bizrules, like 'my own ...' or 'newest ...'.

from yii2.

@samdark you can store anonymous functions in a file and refer to them from db backend by name which may be the array key.

from yii2.

@qiangxue You working on this already or not yet?

from yii2.

Nope. Only issues labelled as "under development" are being worked on.

from yii2.

@qiangxue I'm starting working on this. ETA: up to week, maybe less.

from yii2.

Cool. Would be great if you could check whether there are other enhancement requests in our forum and take this chance to improve RBAC.

from yii2.

@qiangxue I'll implement base version at start, than check forum for possible improvements.

from yii2.

#198

from yii2.

Done for preview.

from yii2.

@qiangxue Where we should put needed *.sql files? Under yii/rbac directory ?

from yii2.

yii/rbac is fine.

from yii2.

Where we should put needed *.sql files? Under yii/rbac directory ?

The database should be created via migrations in the end. A simple execute($sql) would be fine. But where should we store this migration?

from yii2.

Do we want to force people to use migrations?
If not it would be fine if we provide SQL file and everyone who wants to use migrations can apply the sql file inside of a migration.

from yii2.

@cebe I'm sure NOT.

from yii2.

If not it would be fine if we provide SQL file and everyone who wants to use migrations can apply the sql file inside of a migration.

May I create a PR with a migration, which executes the SQL files according to the used DB-connection?
Placed in the same directory, this directory could be registered as a migration "module" (speaking in EMigrateCommand terms) for the advanced-app in the end.

from yii2.