Make WordPress Core

Opened 7 years ago

Closed 4 years ago

#41159 closed enhancement (wontfix)

REST API: Add a way to determine if a request is an embedded "sub-request"

Reported by: jnylen0's profile jnylen0 Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.4
Component: REST API Keywords: needs-patch needs-unit-tests
Focuses: rest-api Cc:


Currently it's difficult to determine whether a request is the "root" request or a "child" embedded request due to ?_embed using multiple WP_REST_Request objects. #38964 will help a bit, but we should also add a way to directly track whether a request is part of an embed tree. Something like this:

  • $request->is_embed: boolean property indicating whether the request is a "child" embedded request
  • $request->embed_parent: WP_REST_Request object pointing to parent request, or null if none

Change History (4)

#1 @rmccue
7 years ago

Right now, we have context=embed, but that's not guaranteed to be set (it can be overridden if the URL contains a context parameter).

What's the rationale for adding this? Responses should be context-free generally, so any variation should be included in the request data (hence, context=embed).

#2 @jnylen0
7 years ago

The rationale is that an ?_embed response is not truly context-free - it's a tree of requests that are all returned at the same time, and it's occasionally useful to be able to decipher this structure.

For some background, the v1 REST API does not allow listing or fetching users or media unauthenticated, so we decided to preserve that contract when adding the WP REST API and prohibit the same operations there.

However, it should still be possible to get limited user or media item details via ?_embed. My specific use case here is to make this possible.

Currently this is achieved by watching rest_request_before_callbacks and remembering some information about the "root" request. The solution described in this ticket would be much less hacky.

#3 @jnylen0
7 years ago

Found a bug in our current approach today: rest_request_before_callbacks will be triggered (perhaps multiple times) for every rest_do_request call, but there is no filter to use at the *end* of this call chain. So any usage of rest_do_request will probably break this code.

The cleanest solution I can think of is as described in the ticket.

#4 @TimothyBlynJacobs
4 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

I agree with @rmccue that each of these requests should be context free. The variation is entirely controlled by setting context=embed. I also don't think we should encourage users to use the fact that the given request is an embed in lieu of proper permission checks. It also breaks the contract that you should be able to follow an embedded link and get results if the results are only accessible when doing an ?_embed request.

Note: See TracTickets for help on using tickets.