Cwebuser::checkaccess() Issue When Used With Bizrule

[hshhbd (Shenghua He)]

Hello guys,

I am new to the forum and new to Yii as well. I am having some issues when using the CWebUser::checkAccess() method with the $bizRule parameter and hopefully someone could lend a helping hand.

Basically the issue is around if the business rule is invalid (such as having a typo or parse error), I don’t get any error logs generated nor any notices from Yii. I looked into the source code and I can see the reason is all warnings are suppressed (’@’ is used) when CAuthManager evaluates the business rules in CAuthManager::executeBizRule().

I can see why it does this but I almost pulled my hair off yesterday trying to debug what was going on with my bizrule and at the end I found it was a typo.

For example,

//define business rule and assign the rule to a Role and a User Id

$bizRule = ‘return isset($params[“blah”]) && $params[“blah”]->isUserInRole(“owner”);’;

$auth->assign(‘member’, $row1[‘user_id’], $bizRule);

//check access

$params = array(‘blah’ => $model);

Yii::app()->user->checkAccess(‘updateBlah’, $params);

The problem is if I modify my $bizRule to

$bizRule = ‘return isset($param[“blah”]) && $param[“blah”]->isUserInRole(“owner”);’; //missing ‘s’ on $params

It does not generate any warnings.

Could someone give me some suggestions with regards to what’s the best way to debug the business rules under these circumstances.

Thanks very much in advance!

[boaz (Boaz Rymland)]

Yep, debugging PHP can be a pain.

Some comments:

• You can take out the bizrule code to some external method. Say, static method in some class, and in that method you can more easily inspect your code
• You can extend CAuthManager and override executeBizRule() to remove the ‘error silence operator’.
• using $param instead of $params will in not trigger an error in stock PHP environment so its somewhat of a PHP matter than Yii’s
• You can use a decent IDE. Such an IDE will warn you of usages of variable that you insert but where never initialized before and might have helped you catch that $param instead of $params.
• Finally, your bizrules should be as simple as they can be (and they are - but do remember this).

[hshhbd (Shenghua He)]

Yep, debugging PHP can be a pain.

Some comments:

• You can take out the bizrule code to some external method. Say, static method in some class, and in that method you can more easily inspect your code
• You can extend CAuthManager and override executeBizRule() to remove the ‘error silence operator’.
• using $param instead of $params will in not trigger an error in stock PHP environment so its somewhat of a PHP matter than Yii’s
• You can use a decent IDE. Such an IDE will warn you of usages of variable that you insert but where never initialized before and might have helped you catch that $param instead of $params.
• Finally, your bizrules should be as simple as they can be (and they are - but do remember this).

Thanks very much, that’s certainly very helpful. I think I might take the extend and override route which gives me full flexibility to handle errors extensively.

One thing I found very helpful debugging in PHP is to follow the PHP error log in Unix Terminal. E.g. type “tail -f /etc/httpd/logs/error_log” (this can vary based on php.ini settings). This can monitor all PHP errors in real time. Undefined variables will also be reported here as long as php.ini is configured to “error_reporting = E_ALL & ~E_NOTICE” instead of “error_reporting = E_ALL” on development platform. However, this wouldn’t help if the error silence operator is used.

Thanks a lot Boaz!

[boaz (Boaz Rymland)]

Thanks very much, that’s certainly very helpful. I think I might take the extend and override route which gives me full flexibility to handle errors extensively.

One thing I found very helpful debugging in PHP is to follow the PHP error log in Unix Terminal. E.g. type “tail -f /etc/httpd/logs/error_log” (this can vary based on php.ini settings). This can monitor all PHP errors in real time. Undefined variables will also be reported here as long as php.ini is configured to “error_reporting = E_ALL & ~E_NOTICE” instead of “error_reporting = E_ALL” on development platform. However, this wouldn’t help if the error silence operator is used.

Thanks a lot Boaz!

Right.

The best practice I can recommend is to configure PHP (php.ini) to explode on any type of error - the smallest it can be. This should be configured on development machines and of course turned off on staging/qa/prod. That allows detecting the smallest issues during development - where its the cheapest to fix.