REST API: Hide schema/args for site-customized endpoints unless authenticated

[jnylen0]

Migrated from ​https://github.com/WP-API/WP-API/issues/2895 - we should consider hiding the list of site-registered custom settings from the schema and endpoint arguments unless the requesting user has the permissions necessary to actually use these arguments.

It seems unwise to publicly expose the list of non-core settings that a site has added to the API for customization purposes; all this does is expose information about custom code that the site is running.

I'm not sure whether this is truly a 'bug' but we should discuss it before 4.7.

Should we also do something similar for meta? Anywhere else?

[danielbachhuber]

Replying to jnylen0:

we should consider hiding the list of site-registered custom settings from the schema and endpoint arguments unless the requesting user has the permissions necessary to actually use these arguments.

Few questions about this:

• Can you provide some examples of setting schema you'd like to put behind authentication?
• How would you determine whether or not a user has authorization to view the schema?
• Have you considered not declaring the setting in the schema, and just conditionally including it in the response?

[jnylen0]

1. I'll defer to @rachelbaker for specific examples and rationale behind hiding them.
2. For settings, I'm thinking the full schema would be shown if current_user_can( 'manage_options' ). Otherwise we would show only the settings registered by core (which are already public because WP is open source).
3. This is an option, but it seems better if it's possible to get a complete and accurate schema when authenticated.

[danielbachhuber]

Ok. At this point, I'm against the intent of this ticket for a few different reasons:

1. Authentication is different then authorization, and we don't currently have an architecture for checking authorization on specific schema properties.
2. Although we haven't explicitly stated as such, schemas aren't intended to be dynamic based on the request. The schema is meant to be a relatively fixed representation of the WordPress site.
3. Because of 2, it's conceivable a client would cache the schema between users. If the schema was dynamic between users, then it would be incorrect in some uses.

Given these points, it'd be worthwhile to document the intended nature of schemas somewhere.

[joehoyle]

How about we only include the schema in the OPTIONS request and the wp-json?context=help if you are allowed to GET | POST | DELETE on the endpoint? We already do these checks on sending an OPTIONS request (and some others) anyway, so there's probably little overhead to this.

[jnylen0]

I thought about this some more, and I think we should avoid adding more calls to permission_callback etc.

Also, if a site registers settings that are sensitive enough where the public existence of their name and description is a concern, they should probably be set to 'show_in_rest' => false. If they still need to be set via the API, they should live in a separate endpoint with 'show_in_index' => false.

[joehoyle]

@jnylen0 given that, do you think we could just close this out?

[jnylen0]

Sounds OK to me.