WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 7 years ago

#25240 closed defect (bug) (invalid)

current_user_can( $capability, $args ) returns true for invalid $args (post ID)

Reported by: akshay_raje Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.6
Component: Role/Capability Keywords: 2nd-opinion
Focuses: Cc:

Description

The function current_user_can( $capability, $args ) currently returns true even if we pass a junk / non-existent post ID to it.

Change History (5)

#1 @akshay_raje
7 years ago

  • Cc akshay.raje@… added
  • Keywords has-patch removed

#2 @SergeyBiryukov
7 years ago

  • Keywords reporter-feedback added

Could not reproduce.

var_dump( current_user_can( 'edit_post', -1 ) ) returns bool(false) for me. I do, however, get the notices mentioned in #13905.

#3 @akshay_raje
7 years ago

Am sorry, but what I was doing is using a custom capability 'edit_job' defined via add_role(). So possibly this bug is just restricted custom capabilities.

#4 @akshay_raje
7 years ago

  • Keywords reporter-feedback removed

#5 @nacin
7 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

If you have a custom capability, that capability needs to properly handle extra arguments if that's what you want. See also map_meta_cap().

That said, "primitive" capabilities added by something like add_role() or add_cap() are not meant to be checked against individual arguments. They are meant to be possessed by a user/role, or not.

You'll see that we pass post IDs to things like 'edit_post' — which is *not* a capability normally assigned to users or roles. It then maps to capabilities that users/roles do have, like edit_posts, edit_others_posts, etc.

Note: See TracTickets for help on using tickets.