WordPress.org

Make WordPress Core

Opened 10 days ago

Closed 10 days ago

Last modified 40 hours ago

#48812 closed enhancement (wontfix)

REST API: Settings endpoint - read access

Reported by: scruffian Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.7
Component: REST API Keywords: has-patch 2nd-opinion dev-feedback
Focuses: Cc:
PR Number:

Description

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

Attachments (1)

patch.diff (2.0 KB) - added by scruffian 10 days ago.
Patch for REST API

Download all attachments as: .zip

Change History (6)

@scruffian
10 days ago

Patch for REST API

This ticket was mentioned in Slack in #core-restapi by scruffian. View the logs.


10 days ago

#2 @TimothyBlynJacobs
10 days ago

  • Keywords 2nd-opinion dev-feedback added
  • Version set to 4.7

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.

#3 @peterwilsoncc
10 days ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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.

This ticket was mentioned in Slack in #core-restapi by spacedmonkey. View the logs.


3 days ago

This ticket was mentioned in Slack in #core-editor by scruffian. View the logs.


40 hours ago

Note: See TracTickets for help on using tickets.