[wp-trac] [WordPress Trac] #48885: REST API: Add a route to read and update separate site settings

[WordPress Trac]

#48885: REST API: Add a route to read and update separate site settings
--------------------------------------------------+---------------------
 Reporter:  scruffian                             |       Owner:  (none)
     Type:  enhancement                           |      Status:  new
 Priority:  normal                                |   Milestone:  5.4
Component:  REST API                              |     Version:
 Severity:  normal                                |  Resolution:
 Keywords:  has-patch has-unit-tests 2nd-opinion  |     Focuses:
PR Number:                                        |
--------------------------------------------------+---------------------

Comment (by TimothyBlynJacobs):

 Yeah this is tricky. Even partial access could be a security concern as I
 described in #48812. We don't provide a filter to modify the response in
 the settings controller itself. So if you want to do any modification,
 you'd have to do it in `rest_request_after_callbacks`. Something like this
 for instance.

 {{{#!php
 <?php
 add_filter( 'rest_request_after_callbacks', static function ( $response,
 $route, WP_REST_Request $request ) {
         if ( 0 !== strpos( $request->get_route(), '/wp/v2/settings' ) ) {
                 return $response;
         }

         if ( is_wp_error( $response ) || $response->is_error() ) {
                 return $response;
         }

         $response->data['do_some'] = 'privileged thing';

         return $response;
 }, 10, 3 );
 }}}

 Returning a partial response when the user has no permissions would mean
 this previously valid mechanism of extending or modifying the response
 could now potentially reveal sensitive information.

 I'm not sure how to evaluate how prevalent this pattern is, but I don't
 think it is particularly "weird" so to speak. I'm not seeing anything
 concerning on the
 [https://wpdirectory.net/search/01DVSYP03SRRB5G5CQBE7WY7AT plugins
 directory], no idea about custom code.

 Making separate routes also doesn't necessarily solve this depending on
 how a developer is checking the route. `strpos` vs `===`.

 -----

 I think we also still need to figure out how to expose the "rendered"
 value of the site title to Gutenberg. That is where the `bloginfo` filter
 has been applied. I'm not sure if there's a great way of doing that on the
 existing settings route without breaking backwards compatibility. We
 couldn't just change the shape of the response to be a raw/rendered object
 like the title field. That would break anyone reading that field. So we
 would have to use something like `context`. Right now there is no context
 on the settings controller. A couple of possibilities.

 1. Introduce a `view` and `edit` context. Make `edit` the default context.
 When the resource is requested in a `view` context, change the value to
 the rendered version. This would work for public access, but doesn't solve
 the editing requirement. Gutenberg would need to maintain both a `view`
 and `edit` version of the response in the data store.
 2. Effectively "version" the endpoint based on a request parameter of some
 sort. If that request parameter is present, returns an object for the site
 title that includes the raw and rendered version. When returning the
 public version of the response, only return the rendered property.
 3. Introduce the single option endpoints and use the desired response
 format there. This would lead to inconsistencies between the collection
 and single item responses.

 -----

 I'm not wild about any of these options. They all would introduce
 complexity into the security sensitive settings controller. To me, it
 doesn't seem like any more of a desirable solution than handling it in the
 client. It feels strange to expose settings to the public in a manner like
 this.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/48885#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform