Manual:Hooks/userCan

Details

 * $title


 * reference to the title in question (see the use in $IP/includes/Title.php)


 * $user


 * reference to the current user (see the use in $IP/includes/Title.php)


 * $action


 * action concerning the title in question


 * $result


 * reference to the result propagated along the chain of hooks (see $IP/includes/Hooks.php)


 * $result can be left untouched, or set to true or false, according to the opinion of the particular hook function


 * true means that the user is allowed, and false means that the $user is disallowed for the $action concerning the $title


 * leaving untouched means that the hook function has no opinion about the situation


 * return value of the hook function


 * the individual hook functions of the possibly nested list of hooks are processed in order of their natural occurrence, from the beginning until either the end of the list is reached, or the current hook function doesn't return true


 * a particular hook function on the list will stop the processing, if it returns false.


 * intentional side effect of the chain of hook function


 * $result given by reference to each hook function contains the resulting opinion of the hook functions processed so far


 * to be the first in the list of hooks has the disadvantage, that later hook functions have the opportunity to change the $result


 * to be the last in the list of hooks has the disadvantage, that the processing of the hooks will simply not reach that point, hence less chance to have an impact on the $result

The final decision concerning the $title - $user - $action triple is the value can be found in $result, when the processing of the list of hooks is finished.

Risk of returning a string value
Note - Unlike most other hooks, you cannot return a string value from the userCan hook. Normally, returning a string value will cause an error page to be displayed, containing the returned string. However, the process of displaying the error page calls the userCan hook to determine the available UI elements, and so returning a string from this function will cause an infinite recursion! This was tested on v1.6.10 and may have subsequently been fixed.

Limitations
Warning: Even if a user doesn't have access rights to read a given article, that article can still appear in lists (e.g. recent changes list, search lists, etc). See Security issues with authorization extensions

In MediaWiki 1.12, if a site is globally readable (i.e. $wgGroupPermissions['*']['read'] = true) then userCan is never called to check for article read permissions. Other permissions will still be checked as normal. This bug was introduced in 1.12.0 and fixed in 1.13.0 (specfifically, it was introduced in r29725, fixed in r32324, re-introduced in r32326 and finally fixed properly again in r32354, but not back-ported to the 1.12 branch).