Data storage layer should properly handle both context=view and context=edit

[danielbachhuber]

For better or for worse, the REST API has an architectural feature called context. context roughly relates to user permissions, and denotes the context in which the response data will be used:

• context=view denotes attributes used for frontend presentation.
• context=edit denotes attributes used for editing the resource.

To provide a specific example:

• GET /wp-json/wp/v2/posts/1?context=view returns post.content.rendered.
• GET /wp-json/wp/v2/posts/1?context=edit also includes post.content.raw, but requires the user to be able to edit the Post.

Seems simple, right? Not quite.

In the editor context (i.e. Gutenberg), a given WordPress user may have context=edit for a Post but only context=view for other resources. For instance, an Editor can edit others' Posts but cannot edit other Users. As such, when the Post Authors UI is presented to the Editor, the REST API request needs to be made with context=view. Similarly, Authors and Contributors cannot edit Terms, but they must be able to view them in order to assign Categories and Tags to Posts.

The broader implications of this issue originally surfaced in #11335 (comment). @youknowriad opened a core Trac ticket https://core.trac.wordpress.org/ticket/45252 to solve this within the REST API, but I'm not optimistic that it's possible. context was a topic we discussed at depth years ago — for some past conversation, please read through WP-API/WP-API#702 and linked issues.

It would be more robust if Gutenberg's data layer could handle context=view and context=edit.

[danielbachhuber]

As such, when the Post Authors UI is presented to the Editor, the REST API request needs to be made with context=view

As it turns out, it's already the case that Post Authors are fetched into the data store layer with context=view:

gutenberg/packages/core-data/src/resolvers.js

Lines 26 to 29 in aec9408

	export function* getAuthors() {
	const users = yield apiFetch( { path: '/wp/v2/users/?who=authors&per_page=-1' } );
	yield receiveUserQuery( 'authors', users );
	}

So I suppose the current implementation is incorrect in this way at the moment (although the interface is getAuthors() which could be expected to be different than a later getUsers()).

[youknowriad]

We probably don't use users elsewhere that's why we didn't see any breakage but yes, I think this is suboptimal.

What about a new context ?context=all that behave like suggested:

• Always return all the available fields for the logged-in user.

I think it's the best compromise as it doesn't break backward compatibility for the REST API, doesn't break backward compatibility for the data module and doesn't alienate the Data module role (doesn't force an external API because of an internal implementation).

[danielbachhuber]

What about a new context ?context=all that behave like suggested:

* Always return all the available fields for the logged-in user.

Potentially, although I'm quite terrified of changing something so substantial within the REST API given the information disclosure risks involved. My preference would be to solve for this within Gutenberg. We can discuss, though.

[youknowriad]

I'm also willing to do experiments on a potential integration in the data module and see how that might look like. When we have a bit more time though :)

[bobbingwide]

Just like to point you back to original issue #5376.
See Expected behaviour - Clean lean and mean.

[nerrad]

This issue was brought on my radar by @aduth. I wonder if one way of handling this is to create middleware for the api-fetch package that maps the correct context for endpoint usage in the editor (i.e. editor-contexts-middleware.js). It'd be fairly heavy but might be useful for requests made in the editor context?