[wp-trac] [WordPress Trac] #53131: Disjunctive normal form for WP_User::has_cap
WordPress Trac
noreply at wordpress.org
Tue May 18 23:52:47 UTC 2021
#53131: Disjunctive normal form for WP_User::has_cap
-----------------------------+------------------------------
Reporter: manfcarlo | Owner: (none)
Type: feature request | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Users | Version:
Severity: normal | Resolution:
Keywords: | Focuses:
-----------------------------+------------------------------
Comment (by peterwilsoncc):
Thanks for expanding on your use case, I really appreciate it.
I've been doing some thought experiments on this over the last couple of
weeks and am a little concerned about how this would work with plugins
expecting the older one-dimensional array vs plugins making use of the
multi-dimensional array.
The cap check array might become:
{{{#!php
<?php
$caps = [
'first_plugin_alternative_one' => [ /* set one */ ],
'first_plugin_alternative_two' => [ /* set two */ ],
'second_plugin_alt_one' = [ /* set one */ ],
'second_plugin_alt_two' = [ /* set two */ ],
'edit_published_posts',
'edit_others_published_posts',
'third_plugin_custom_capability_actions'
];
}}}
I've been trying to work out how WordPress could safely resolve such an
array and have been unable to do so. It becomes even more complicated if a
`do_not_allow` is in all of one plugin's sets but not another plugin's, or
even at the top level from a plugin expecting a single dimensional array.
I do understand why you think including `current_user_can()` in a meta cap
check isn't ideal but I think it might be the most secure solution.
Rather than immediately close the ticket, I am wondering if you have any
suggestions on a way WordPress could handle such a situation?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/53131#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list