Allow publicly readable settings within WP_REST_Settings_Controller

[davecpage]

With register_setting() developers can expose a setting to appear within REST queries on /wp/v2/settings. Very useful I thought for API only based frontends. However though I agree that editing these settings is limited to those authenticated users who have 'manage_options' it appears that the reading of these settings is limited to the same.

Would it therefore be useful to allow exposing some/all of these settings to unauthenticated users. Maybe with a 'public' => true flag on each setting so that this can be opt-in from a security point of view?

The alternative appears to be for developers to effectively duplicate the WP_REST_Settings_Controller under a different namespace/endpoint exposing those fields they wish to be viewable.

[jnylen0]

There was some more discussion on "readonly settings" starting here: https://core.trac.wordpress.org/ticket/38490#comment:10

To summarize, a "readonly setting" is a misnomer because it's not really a "setting" as defined by the endpoint that lets you view and edit site settings. This is really "site info". As such, if it's going to live somewhere, it should probably be on the root /wp-json endpoint which already has some of these properties (site name, description, url, and home).

Here's what I think we should do about this (cc @joehoyle @rachelbaker for your opinions).

• Create a new ticket to enhance the /wp-json endpoint with any extra site properties (the current settings endpoint and the list here are both good starting points). We may also need a mechanism for versioning the response of this endpoint and having its response vary based on the user's capabilities. Addressing all of this can wait until a future release.
• Once we have a plan for adding more site info, close this ticket.

[jnylen0]

Another option would be to recognize that there are lots of reasons to need access to site settings data specifically, and go ahead and implement finer-grained read permissions on the settings endpoint anyway.

See also: ticket:38342#comment:48

[joehoyle]

@jnylen0 totally agree with the two options here. I think we should lead towards the first "Create a new ticket to enhance the /wp-json". I wonder if we could provide an easy way for developers to be able to do that. Right now, I'm not sure how simple this is to do.

[spacedmonkey]

#48812 was marked as a duplicate.

[spacedmonkey]

I think we should make the settings endpoint public and have a auth_callback callback on the setting schema.

        register_setting(
                'general',
                'blogname',
                array(
                        'show_in_rest' => array(
                            'name' => 'title',
                            'auth_callback' => 'manage_options',  
                        ),
                        'type'         => 'string',
                        'description'  => __( 'Site title.' ),
                )
        );

This callback would be called all registered settings, to see if should be displayed or not. To make a setting public, all that would be required would be.

'auth_callback' => '__return_true',  

By default, we would have to make 'auth_callback' => 'manage_options', to stop existing options going public.

I know this ticket would be especially useful to the gutenberg team to get data out of WordPress.

[TimothyBlynJacobs]

Closing as a duplicate of the newer #48885 since it has more context.