[wp-trac] [WordPress Trac] #52076: Checking anonymous user's exist capability returns inconsistent results across functions.

[WordPress Trac]

#52076: Checking anonymous user's exist capability returns inconsistent results
across functions.
-------------------------------------------------+-------------------------
 Reporter:  peterwilsoncc                        |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  5.7
Component:  Role/Capability                      |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  early has-patch needs-unit-tests     |     Focuses:
  needs-dev-note                                 |
-------------------------------------------------+-------------------------

Comment (by peterwilsoncc):

 Replying to [comment:11 TimothyBlynJacobs]:
 > Though, thinking on that more. If someone is intentionally doing
 `wp_get_current_user()->has_cap()` so that logged out users were handled.
 If we do care about that risk, I guess we could pass a flag to `has_cap`
 when called from `(current_)user_can` that would enable that stricter
 checking. But that sounds a bit ugly.

 Here's a search of
 [https://wpdirectory.net/search/01EWC5P6EHC5RMXN6QB955AJM2 plugins using
 the `user_can()` function rather than `current_user_can()`], the regex is
 `( |(->)|(::))user_can\(`. I've also
 [https://wpdirectory.net/search/01EWC6K8QZ8D4S5GWM1M7NH6VZ searched for
 the string `exist`] with the regex `[\'\"]exist[\'\"]`.

 Upon a sample review, I couldn't find any using the `exist` capability. To
 discount the logged out user, the documented method is
 `wp_get_current_user()->exists()` but it's certainly worth considering
 that `user_can( $u_id, 'exist' )` might be used as a shortcut.

 > So I suppose the obvious risk here is someone writing a `map_meta_cap`
 filter that doesn't handle user_id = 0 properly. Some bad code like `if (
 ! $user_id ) { return []; }`. But I imagine there are more plausible
 scenarios you could end up writing code that would wind up having the same
 effect.

 I'm not too concerned about this as `current_user_can()` already
 frequently passes the user ID `0` for logged out users.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/52076#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform