Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 4 years ago

#48812 closed enhancement (duplicate)

REST API: Settings endpoint - read access

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


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:

Attachments (1)

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

Download all attachments as: .zip

Change History (8)

5 years ago

Patch for REST API

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

5 years ago

#2 @TimothyBlynJacobs
5 years 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
5 years 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.

5 years ago

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

5 years ago

#6 @spacedmonkey
4 years ago

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

#7 @spacedmonkey
4 years ago

  • Resolution changed from wontfix to duplicate

Duplicate of #38731.

Note: See TracTickets for help on using tickets.