[wp-trac] [WordPress Trac] #14066: has_cap() bug when logged in as super-admin
WordPress Trac
wp-trac at lists.automattic.com
Wed Jun 23 23:29:39 UTC 2010
#14066: has_cap() bug when logged in as super-admin
-----------------------------+----------------------------------------------
Reporter: bigdawggi | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Unassigned
Component: Role/Capability | Version: 3.0
Severity: normal | Keywords: capabilities, user, permissions
-----------------------------+----------------------------------------------
I've working with a site that has a plugin that adds custom capabilities.
When logged in as a super-admin, on the user edit screen (editing a
subscriber, not my own profile) all the capabilities were checked.
The plugin (Role Manager) properly grabs the currently-edited user object
and calls the has_cap() method on it to see if the user has the current
capability.
During the has_cap() check WordPress does the following:
{{{
if ( is_multisite() && is_super_admin() ) {
if ( in_array('do_not_allow', $caps) )
return false;
return true;
}
}}}
The is_super_admin() function defaults to the logged-in user if no user ID
is passed. Since has_cap() isn't passing the current object's user ID
(i.e., $this->ID) it's checking my super-user's capabilities and returning
a false positive.
I suggest we pass the current object's user ID into the is_super_admin()
method in this instance, so that it's properly checking the object's
capabilities instead of falling back to the currently logged in user.
{{{
if ( is_multisite() && is_super_admin($this->ID) ) {
if ( in_array('do_not_allow', $caps) )
return false;
return true;
}
}}}
Patch is attached.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/14066>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list