[wp-trac] [WordPress Trac] #36376: current_user_can/has_cap fails when user has multiple roles
WordPress Trac
noreply at wordpress.org
Mon Dec 4 08:19:33 UTC 2017
#36376: current_user_can/has_cap fails when user has multiple roles
-----------------------------------------------+---------------------------
Reporter: mikejolley | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting
Component: Role/Capability | Review
Severity: normal | Version:
Keywords: has-unit-tests dev-feedback close | Resolution:
| Focuses:
-----------------------------------------------+---------------------------
Comment (by knutsp):
A tested capability may be true, false or undefined (null). If false or
null, false is returned.
Explicitly setting a capability to false (denied) should take precedence,
even over later added roles or explicit capabilities, since this is a
special and more rare case. The lack of a capability is normal way of not
giving that capability.
But when a user is explicitly denied a capability, adding a later role
than includes this capability should not invalidate the first denial.
Granting something that once was denied should be done by removing the
denial, explicitly, or else it may be unintentional. Or there should be a
warning that the new role invalidates an earlier denial, but I see that
highly impractical to implement.
Logic (pseudo code):
{{{#!php
<?php
$has_cap = false;
foreach ( $roles as $role ) {
if ( isset( $role['my_cap'] ) && $role['my_cap'] ) {
$has_cap = true;
break;
} elseif ( isset( $role['my_cap'] ) ) { // $role['my_cap'] must be
false
$has_cap = false;
break;
}
}
}}}
If I understand it correctly, the Members
plugin[https://wordpress.org/plugins/members/] uses a logic like this, if
set to. This should be the default.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/36376#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list