WordPress.org

Make WordPress Core

Opened 8 months ago

Last modified 8 months ago

#25016 assigned defect (bug)

XMLRPC method "wp.getUsers" not working correctly on WordPress.com

Reported by: dinomic Owned by: markoheijnen
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.5
Component: XML-RPC Keywords:
Focuses: Cc:

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 (9)

comment:1 markoheijnen8 months 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.

comment:2 follow-ups: dinomic8 months 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...

comment:3 in reply to: ↑ 2 helen8 months 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. :)

comment:4 markoheijnen8 months 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.

comment:5 in reply to: ↑ 2 nacin8 months 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.

comment:6 markoheijnen8 months 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.

comment:7 nacin8 months 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.

comment:8 SergeyBiryukov8 months ago

  • Version changed from trunk to 3.5

Related: [21824] (for #18428).

comment:9 markoheijnen8 months ago

  • Owner set to markoheijnen
  • Status changed from reopened to assigned
Note: See TracTickets for help on using tickets.