id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc
20629,wp.getPages response includes bogus content for pages lacking edit permission,redsweater,ryan,"In the event that the authenticated user for wp.getPages does not have editing permissions for a given page, instead of that page being completely omitted from the resulting array, the array is filled with bogus entries. The practical implication of this bug is that for XMLRPC clients that do not expect the bogus values to appear, they will strain to interpret the error blocks as actual page entries.

The bogus entries appear like this:

{{{
<value><struct>
  <member><name>code</name><value><int>401</int></value></member>
  <member><name>message</name><value><string>Sorry, you cannot edit this page.</string></value></member>
</struct></value>

}}}

This doesn't match the documented behavior that the result should be an array of page structures.

I believe the expected behavior would be for the resulting array to simply omit any pages the user doesn't have permission to edit.

The crux of this issue is in the implementation of wp.getPages, and that it reuses the wp_getPage() method to fulfill the getPages request:

{{{
for ( $i = 0; $i < $num_pages; $i++ ) {
	$page = wp_xmlrpc_server::wp_getPage(array(
		$blog_id, $pages[$i]->ID, $username, $password
	));
	$pages_struct[] = $page;
}
}}}

It is within this wp_getPage() method that the page-specific permission check is made, and a bogus error is returned instead of the page.

Probably the wp_getPages() method should check for this bogus error result and, if present, omit the page from the return $pages_struct.
",defect (bug),closed,normal,3.4,XML-RPC,3.4,normal,fixed,has-patch,maxcutler