REST API: Settings endpoint - read access

[scruffian]

With Full Site Editing in Gutenberg, we will be letting people see site level settings in the editor (for example Site Title). Only users with manage_options should be able to change these settings, but we'll need to show them to all users who can edit posts, so that they can preview the editor with these elements displayed.

This patch changes the capabilities needed to read the settings endpoint, so that anyone with edit_posts can read the settings, but not edit them.

This is needed by this Gutenberg PR: ​https://github.com/WordPress/gutenberg/pull/18760

[scruffian]

Patch for REST API

[TimothyBlynJacobs]

My understanding is when grabbing settings values that are public has come up before, they've been added to the Site Index instead. For instance #39854. The site title is already available via the index in this way.

Changing the permissions globally here to be less restrictive would be pretty much a no-go from my perspective. If there is setting data that can't be exposed in the index for some reason, then we'd need to allow for settings to have a custom capabilities check specified via register_setting.

Even with that, though, making it looser could still have some implications. Right now, someone can expect that if a valid settings response is returned, the user has passed the permissions callback. This would impact the rest_request_after_callbacks and rest_post_dispatch filters.

[peterwilsoncc]

I agree with @TimothyBlynJacobs that this is a no go due to security implications.

A plugin could be registering confidential data via the settings API and using the REST API to update the options, exposing them in the endpoint as a result.

The first example that comes to mind is storing a social media access token or key/secret pair to allow posting via the WordPress admin or displaying the posts on the site.

There are 75K+ ​instances of `register_setting()` in the plugin directory so it's a pretty safe bet unintended data would become available as a result.

[spacedmonkey]

I think we should focus on #38731 that adds a new param to register_setting

[spacedmonkey]

Duplicate of #38731.