Rule of rbac in yii2, and rbac in yii2

Rule of rbac in yii2, and rbac in yii2

In our previous yii2 background and rbac detailed tutorials, I don't know if you have ever wondered what the rule table is. Why didn't we involve this table in the whole process?

I believe not to mention that some people will try it, or Baidu or google. In the end, there will be little content to explain!

For general permission systems, the previously implemented rbac is generally sufficient, and there is no rule in real time. I believe you can also implement the functions implemented using rule.

Let's take an example on the official website to show you how this mysterious rule works!

View requirements:

We have administrators and common users. For the article system, we allow administrators to perform any operations on the article, but only allow common users to create articles and modify their own articles, allow users to modify their own articles, not all articles that are not allowed to be modified!

Let's look at how yii2 rbac rule is implemented. The focus is to teach you how to use this rule and to solve many popular sections!

Before we add rule, we need to implement the execute method of the yii \ rbac \ Rule class.

<? Phpnamespace backend \ components; use Yii; use yii \ rbac \ Rule; class ArticleRule extends Rule {public $ name = 'Article'; public function execute ($ user, $ item, $ params) {// set it to false first, and then improve return false after logic ;}}

Then, we can go to the background rule list (/admin/rule/index) to add rule. For more information, see the following section.

Note: many of the above steps will die in adding class names. Remember to add the namespace where our ArticleRule file is located!

Let's take a look at step 3, which is also prone to errors! Please pay attention to this tutorial!

In the access permission list (/admin/permission/index), we add the permission. This permission is only modified for the article, and then we assign it to the user's role.

Note that a severe warning is given here. The route controlled by the newly added permission is the update operation of the article (/article/update) assigned to the current user only once, if you repeatedly allocate the current operation to the role or user, the rule may be invalid because the failure is overwritten!

Refresh the update page (/article/update/1) of the article again. It is clear that the 403 forbidden has no access permission, that is, the newly added rule takes effect! If it does not take effect at the moment, check the two notes mentioned above!

Then we implement the business logic in the ArticleRule: execute method, which can be referred to as follows:

Class ArticleRule extends Rule {public $ name = 'Article';/*** @ param string | integer $ uid of the user currently logged on * @ param Item $ rule of the item, that is, the new rule we will follow * @ param array $ params parameters carried by the current request. * @ return true or false. true users can access false users. */public function execute ($ user, $ item, $ params) {$ id = isset ($ params ['id'])? $ Params ['id']: null; if (! $ Id) {return false;} $ model = Article: findOne ($ id); if (! $ Model) {return false;} $ username = Yii: $ app-> user-> identity-> username; $ role = Yii :: $ app-> user-> identity-> role; if ($ role = User: ROLE_ADMIN | $ username = $ model-> operate) {return true ;} return false ;}}

Finally, it is verified. Does the rule authentication work?

The test procedure is as follows:

[Considering that most of the articles collected on Chinese websites are very frequent at present, the author does not specify the source of the original article. The original author prefers the readers to check the original article to avoid updating all the articles due to any problems and avoid misleading.]

View Original