Opened 9 years ago
Closed 9 years ago
#28075 closed defect (bug) (duplicate)
User Roles and permissions broken in 3.9 Multisite for XMLRPC API
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Priority: | normal | |
| Severity: | normal | Version: | 3.9 |
| Component: | XML-RPC | Keywords: | |
| Focuses: | Cc: |
Description (last modified by )
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.
Related: #26318