WordPress.org

Make WordPress Core

Opened 6 years ago

Last modified 5 months ago

#25016 assigned defect (bug)

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

Reported by: dinomic Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.5
Component: XML-RPC Keywords: needs-patch
Focuses: multisite Cc:
PR Number:

Description

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.

Change History (11)

#1 @markoheijnen
6 years ago

  • Keywords needs-patch removed
  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Severity changed from critical to normal
  • Status changed from new to closed

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.

#2 follow-ups: @dinomic
6 years ago

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...

#3 in reply to: ↑ 2 @helen
6 years ago

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. :)

#4 @markoheijnen
6 years ago

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.

#5 in reply to: ↑ 2 @nacin
6 years ago

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.

#6 @markoheijnen
6 years ago

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

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.

#7 @nacin
6 years ago

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.

#8 @SergeyBiryukov
6 years ago

  • Version changed from trunk to 3.5

Related: [21824] (for #18428).

#9 @markoheijnen
6 years ago

  • Owner set to markoheijnen
  • Status changed from reopened to assigned

#10 @dd32
4 years ago

  • Focuses multisite added
  • Summary changed from XMLRPC method "wp.getUsers" not working correctly on WordPress.com to XMLRPC method "wp.getUsers" not working correctly in Multisite

#11 @wonderboymusic
4 years ago

  • Keywords needs-patch added
  • Owner markoheijnen deleted

Anyone can patch this

Note: See TracTickets for help on using tickets.