[wp-trac] [WordPress Trac] #40450: Introduce REST API endpoint for proxying requests to external oEmbed providers

WordPress Trac noreply at wordpress.org
Fri Apr 14 19:04:33 UTC 2017


#40450: Introduce REST API endpoint for proxying requests to external oEmbed
providers
----------------------------------------+-------------------------
 Reporter:  westonruter                 |       Owner:  swissspidy
     Type:  enhancement                 |      Status:  reviewing
 Priority:  normal                      |   Milestone:  4.8
Component:  Embeds                      |     Version:
 Severity:  normal                      |  Resolution:
 Keywords:  has-patch needs-unit-tests  |     Focuses:  rest-api
----------------------------------------+-------------------------
Changes (by westonruter):

 * milestone:  Awaiting Review => 4.8


Old description:

> When doing oEmbed previews in the client, both in the media modal `embed`
> frame and in the TinyMCE embed preview, a `parse-embed` admin-ajax
> request is currently made to do the parsing. This request requires a
> `post_ID` parameter because the WP Embed logic caches oEmbed responses in
> postmeta (see #34115). There is a need for this in the media widgets to
> be able to obtain the `thumbnail_url` for a given oEmbed URL.
> Unfortunately the oEmbed preview in the media modal fails because there
> is no `post_ID` for context.
>
> There is currently an `wp-json/oembed/1.0/embed` endpoint for serving
> oEmbed responses for posts on a given site. It would be a useful
> improvement to extend this endpoint to also allow for proxying the oEmbed
> provider lookup and fetching, as handled internally in
> `\WP_oEmbed::get_html()`: https://github.com/WordPress/wordpress-
> develop/blob/4.7/src/wp-includes/class-oembed.php#L333-L360
>
> I understand there is also a concern for using such an `embed` endpoint
> for doing DDoS attacks, so I imagine any external URL lookups would
> require auth.
>
> Once this is implemented, the use of the `embed` endpoint can potentially
> replace the `parse-embed` request, at least when there is no `post_ID`
> for context.
>
> For background, see:
> https://wordpress.slack.com/archives/C02RQC26G/p1492038272597233
> https://github.com/xwp/wp-core-media-
> widgets/pull/53#issuecomment-294131744

New description:

 This essentially proposes adding the functionality from noembed.com into
 WordPress.

 When doing oEmbed previews in the client, both in the media modal `embed`
 frame and in the TinyMCE embed preview, a `parse-embed` admin-ajax request
 is currently made to do the parsing. This request requires a `post_ID`
 parameter because the WP Embed logic caches oEmbed responses in postmeta
 (see #34115). There is a need for this in the media widgets to be able to
 obtain the `thumbnail_url` for a given oEmbed URL. Unfortunately the
 oEmbed preview in the media modal fails because there is no `post_ID` for
 context. Also, the client cannot reliably make requests to oEmbed
 providers directly since they inconsistently support CORS.

 There is currently an `wp-json/oembed/1.0/embed` endpoint for serving
 oEmbed responses for posts on a given site. It would be a useful
 improvement to extend this endpoint to also allow for proxying the oEmbed
 provider lookup and fetching, as handled internally in
 `\WP_oEmbed::get_html()`: https://github.com/WordPress/wordpress-
 develop/blob/4.7/src/wp-includes/class-oembed.php#L333-L360

 I understand there is also a concern for using such an `embed` endpoint
 for doing DDoS attacks, so I imagine any external URL lookups would
 require auth.

 Once this is implemented, the use of the `embed` endpoint can potentially
 replace the `parse-embed` request, at least when there is no `post_ID` for
 context.

 For background, see:
 https://wordpress.slack.com/archives/C02RQC26G/p1492038272597233
 https://github.com/xwp/wp-core-media-
 widgets/pull/53#issuecomment-294131744

--

Comment:

 The patch guards against DDoS by requiring the `edit_posts` cap. It does't
 currently cache responses, but I'm guessing this would be added from what
 lands for #34115.

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


More information about the wp-trac mailing list