Implement RBAC

[qiangxue]

No description provided.

[joujou]

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.

[cebe]

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

[samdark]

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

[joujou]

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.

[onman]

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 ...'.

[cebe]

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

[creocoder]

@qiangxue You working on this already or not yet?

[qiangxue]

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

[creocoder]

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

[qiangxue]

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

[creocoder]

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

[samdark]

#198

[creocoder]

Done for preview.

[creocoder]

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

[qiangxue]

yii/rbac is fine.

[schmunk42]

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?

[cebe]

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.

[creocoder]

@cebe I'm sure NOT.

[schmunk42]

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.