[wp-trac] [WordPress Trac] #28075: User Roles and permissions broken in 3.9 Multisite for XMLRPC API

[WordPress Trac]

#28075: User Roles and permissions broken in 3.9 Multisite for XMLRPC API
--------------------------+------------------------------
 Reporter:  dinomic       |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  XML-RPC       |     Version:  3.9
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Old description:

> Since upgrading a Multisite from 3.8.1 to 3.9 (and also when creating a
> new, clean 3.9 Multisite install), XMLRPC permissions do not work for
> anyone other that super admin.
>
> * The XMLRPC method "wp.getProfile" does not return any roles for any
> user other than "administrator"
> * Using "metaWeblog.newPost" to create a new post results in a 401
> "Sorry, you are not allowed to publish posts on this site."
> * Using "wp.newPost"  to create a new post results in a 401 "Sorry, you
> are not allowed to post on this site."
> * Using "wp.getPosts" to retrieve last 20 posts (post_type = post)
> results in a 401 "Sorry, you are not allowed to edit posts in this post
> type"
> * Using "metaWeblog.getRecentPosts" to retrieve last 20 posts results in
> 401 "Sorry, you cannot edit posts on this site."
> * Using "wp.getCategories" to retrieve categories results in a 401
> "Sorry, you must be able to edit posts on this site in order to view
> categories"
>
> I have actually discovered where the bug is, and it's to do with another
> bug (see https://core.trac.wordpress.org/ticket/28014).
>
> Basically, because the XMLRPC is no longer honouring the blog_id value,
> if the the XMLRPC calls are against the root /xmlrpc.php URL, then the
> above errors occur. If however the XMLRPCs calls are against the
> subsite's xmlrpc.php (eg /mytestsite/xmlrpc.php) then all works OK again.
>
> Since the discovery of the sites begins at the root xmlrpc.php file, and
> since renaming of XMLRPC files may occur, it should be safe to assume
> that you can use the root xmlrpc.php file for all subsites as long as you
> pass in the correct blog_id, IMHO.

New description:

 Since upgrading a Multisite from 3.8.1 to 3.9 (and also when creating a
 new, clean 3.9 Multisite install), XMLRPC permissions do not work for
 anyone other that super admin.

 * The XMLRPC method "wp.getProfile" does not return any roles for any user
 other than "administrator"
 * Using "metaWeblog.newPost" to create a new post results in a 401 "Sorry,
 you are not allowed to publish posts on this site."
 * Using "wp.newPost"  to create a new post results in a 401 "Sorry, you
 are not allowed to post on this site."
 * Using "wp.getPosts" to retrieve last 20 posts (post_type = post) results
 in a 401 "Sorry, you are not allowed to edit posts in this post type"
 * Using "metaWeblog.getRecentPosts" to retrieve last 20 posts results in
 401 "Sorry, you cannot edit posts on this site."
 * Using "wp.getCategories" to retrieve categories results in a 401 "Sorry,
 you must be able to edit posts on this site in order to view categories"

 I have actually discovered where the bug is, and it's to do with another
 bug (see #28014).

 Basically, because the XMLRPC is no longer honouring the blog_id value, if
 the the XMLRPC calls are against the root /xmlrpc.php URL, then the above
 errors occur. If however the XMLRPCs calls are against the subsite's
 xmlrpc.php (eg /mytestsite/xmlrpc.php) then all works OK again.

 Since the discovery of the sites begins at the root xmlrpc.php file, and
 since renaming of XMLRPC files may occur, it should be safe to assume that
 you can use the root xmlrpc.php file for all subsites as long as you pass
 in the correct blog_id, IMHO.

--

Comment (by SergeyBiryukov):

 Related: #26318

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