XMLRPC method "wp.getUsers" not working correctly in Multisite

[dinomic]

Hi,

I have been testing some functionality in our app which uses XMLRPC, and it appears that I've found a bug with how the "wp.getUsers" method works on WordPress.com blogs.

Basically, the blog I'm testing this on has 3 administrators. Regardless of which one of those administrators' credentials I use, whenever we call the "wp.getUsers" method we ONLY get details for the SAME user back. So, if we have 3 admins ('admin1', 'admin2', 'admin2'), whenever 'admin1' queries for all users, they only get back 'admin1'.

I also tried adding a different type of user, specifically an author, and then used any of the above-mentioned administrator credentials to try and retrieve info on that author, but nothing is returned.

It should be noted that all the above functionality works as it should on self-hosted blog, just NOT on WordPress.com blogs.

[markoheijnen]

This isn't a support forum for WordPress.org. As you indicated it does work for self hosted blog. I don't know if WordPress.com changed something but I think it is best to ask for support at their forums.

[dinomic]

Hi markoheijnen. Thanks for your suggestion.

I appreciate that this is not a wordpress.org issue *at present*, but the main reason I had flagged it as an issue here was because I was under the impression that WordPress.com code eventually gets pulled over to WordPress.org. Eg, the software version numbers of Wordpress.com blogs reads as follows right now: "3.7-alpha-24954".

Also, I was under the impression that the WordPress.com blog was for regular user support, not for reporting bugs.

Anyway, I have now posted on the WordPress.com forum to see what happens...

[helen]

Replying to dinomic:

I was under the impression that WordPress.com code eventually gets pulled over to WordPress.org.

It's actually (usually) the other way around. :)

[markoheijnen]

WordPress.com does run the latest code or some kind of development version depending on the current state. I don't remember any recent changes in WordPress that would effect your behavior. The people of WordPress.com can look into way better then we can. Also since they use a lot of custom code what can effect this.

[nacin]

Replying to dinomic:

I appreciate that this is not a wordpress.org issue *at present*, but the main reason I had flagged it as an issue here was because I was under the impression that WordPress.com code eventually gets pulled over to WordPress.org. Eg, the software version numbers of Wordpress.com blogs reads as follows right now: "3.7-alpha-24954".

If you see that, you may not be looking at a WordPress.com blog. The meta generator tag for WordPress.com is always "WordPress.com".

While it works on a self-hosted blog, it would be good to confirm that it works in multisite for self-hosted, as that is what WP.com is.

[markoheijnen]

This is probably a cause of

if ( current_user_can( 'edit_user', $user_data->ID ) )
     $_users[] = $this->_prepare_user( $user_data, $fields );

I'm not sure but maybe this check can be removed since there is already a capability check current_user_can( 'list_users' )

I'm reopening it for further investigation.

[nacin]

In multisite, only super admins have the edit_users capability. To a mere administrator who can list users, _prepare_user() might return more data than they can otherwise see in a user list. (Granted, not much — like registered date, names other than the display name, etc.)

One option could be to only allow fields => basic in multisite. Or throw it out the window and allow all current fields. That said, let's create a unit test that verifies that a regular administrator only receives the current list of fields. That way if any more fields are added in the future, we don't get surprised that a regular administrator in multisite sees data that they shouldn't.

[SergeyBiryukov]

Related: [21824] (for #18428).

[wonderboymusic]

Anyone can patch this

Trac ticket:
https://core.trac.wordpress.org/ticket/25016

Use of AI Tools

[jorgelopezrepiso]

I've confirmed the bug on a local Multisite installation with 53 users (50 subscribers, 2 administrators, 1 author). Calling wp.getUsers with a regular site administrator returned only that administrator.

The patch removes the redundant edit_user capability check, which in Multisite is mapped to do_not_allow for non-super-admins and was discarding all users except the current one. It also forces fields => basic for non-super-admins in Multisite, as suggested by @nacin, so that site administrators can list users but only see basic fields.

I've added an unit test that verifies a regular site administrator receives all users with only the basic fields.