Audit user_can() and 'exist' cap usages, related to anonymous users

[johnjamesjacoby]

See: ​#WP52076, ​[WP50490].

WordPress 5.8 will ensure current_user_can(), current_user_can_for_blog(), and user_can() return the same results for anonymous (logged out) users.

I have not yet identified any incompatibilities with this upstream change, but I am expecting at least a single something somewhere to be adversely affected. 🤣

[johnjamesjacoby]

Here's the brief outline as I imagine it, that may or may not be 100% accurate:

• Audit user_can() function calls
• Audit function calls that pass in a literal capability string as a parameter, that use exist
• Ensure user/member component unit tests continue to pass as intended against WordPress 5.8
• Ensure REST API tests continue to pass
• Ensure that code expecting false or a mock/empty WP_User object continues to return the correct type of value
• Ensure hooks continue to pass in correctly typed variable values related to roles/capabilities

[imath]

Thanks a lot for bringing this to our attention 👍. I've just ran PHPUnit Test against WP 5.8/trunk and no tests failed.

I agree we should follow the steps you're recommanding. I'll do it for BP Core. @espellcaste, can you have a look at the BP REST API ?

[espellcaste]

@imath Also tested against WordPress master/trunk and saw no issues with the unit tests. Here is one pull request as an example: ​https://github.com/buddypress/BP-REST/pull/389

[imath]

Thanks a lot @espellcaste 👍. I'll work on the BuddyPress Core part asap 😉

[imath]

Here's what I've checked so far about the user_can( 0, 'exist' ) change in WP 5.8

1. user_can() is used twice in BP Core code:

• In bp_core_login_redirect() to check the 'edit_posts' cap.
• In bp_user_can() to possibly check any caps.

2. bp_user_can() is used 15 times in BP Core code:

• by bp_current_user_can() to possibly check any caps.
• directly 14 times. The exist cap is never checked, it is used twice to check for the user ID 0 in BP_Members_Invitation_Manager->allow_invitation() and in BP_Members_Invitation_Manager->allow_request()

3. The 'exist' cap is checked twice in BP Core code:

• In BP_Members_Admin->user_profile_menu() to generate a WP Admin menu.
• In bp_xprofile_map_meta_caps() as the default capability to return. This cap is always checked with bp_current_user_can() except once in bp_xprofile_grant_bp_xprofile_change_field_visibility_for_logged_out_users() which filters bp_user_can() to allow a logged out user to customize the field visibility (probably during signup)

4. Unit tests are not failing with WP Master which is containing the ​WP changeset since march 4th

Next steps are to:

• Ensure that code expecting false or a mock/empty WP_User object continues to return the correct type of value
• Ensure hooks continue to pass in correctly typed variable values related to roles/capabilities

[imath]

I've checked the last two points. I believe we're safe 😇. I'm going to mark the ticket as fixed. Don't hesitate to reopen it, if you think we need to 👌