Opened 2 years ago
Last modified 11 months ago
#57829 new enhancement
Post "Read" Capability for Rest API
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | |
Component: | Posts, Post Types | Keywords: | has-patch |
Focuses: | rest-api | Cc: |
Description
Posttypes with the public attribute set to false are still queryable through the rest api. Since it seems there is no other capability to check for a general read permission of posts and the 'show_in_rest' attribute is needed for the block editor and to make the post queryable by authenticated users, i think it makes sense to either introduce said "read_post" capability or to make rest api requests only query editable posts when the posttype has public set to false.
Not having the option to have a non-public posttypes and the rest api enabled at the same time without any further workaround seems unintuitive to me.
Change History (2)
This ticket was mentioned in PR #6692 on WordPress/wordpress-develop by @snehapatil02.
11 months ago
#2
- Keywords has-patch added
### Ticket: https://core.trac.wordpress.org/ticket/57829
## Description
This PR aims to improve the REST API functionality in WordPress by modifying the permission checks for reading posts. Currently, non-public post types remain queryable through the REST API, which poses a challenge for developers seeking to restrict access to certain types of posts.
### Changes Made
- Enhanced Permission Check: Modified the
get_items_permissions_check
method in the REST API controller responsible for handling post requests. - Conditional Logic: Implemented conditional logic to check if the post type is non-public. If so, the permission check now ensures that only users with the capability to edit posts can read posts via the REST API for non-public post types.
### Why This Change is Necessary
- The current behavior of the REST API allows non-public post types to be queried, regardless of their accessibility.
- This modification provides developers with more control over post access via the REST API, particularly for non-public post types, aligning better with their intended permissions and restrictions.
- Enhances security and privacy by ensuring that only authorized users can access non-public posts via the REST API.
I would also agree.
I would go farther and say that the requirement of setting "show_in_rest" to true as a means to enable the Gutenberg editor on CPTs has probably led many developers to unintentionally expose private post types data via the REST API.
I don't understand the connection with enabling the post type to be visible in the rest API, with enabling the Gutenberg editor.
I've tried setting the following options to prevent CPTs from being visible when Gutenberg is also enabled, but none prevent visibility:
'public' => false,
'has_archive' => false,
'publicly_queryable' => false,
'exclude_from_search' => false
This seems like a security concern to me. I've personally needed to write additional code to disable the rest API output for a given CPT, that I also want Gutenberg to be enabled on.
I think enabling the Gutenberg editor on a CPT should be a separate option. Though I guess it is too late for that!