URL structure for providing oEmbed should be made easier to block at webserver

[mark-k]

This follows a very troolish discussion at the tavern ​http://wptavern.com/wordpress-4-4-streamlines-content-sharing, with the usual theme of not enough options in core, But there is one take away, that blocking features in PHP level is not ideal.

Right now if I don't want that my site will be an oEmbed provider, I still need to "pay" the price of loading core, plugins and parsing the URL. Worse scenarion is if I already was (wordpress default) and decided to turn it off, then I will still be hammered by requests from sites that still think I do provide oEmbed.

A site owner might want to fully disable the feature, or limit it to syndication partners, and the best way performance wise is to set the relevant rules in htaccess or any applicable web server config file. The current url structure seems to be too difficult for that (I assume you can block URLs that have oembed=1 but it is probably more error prone then blocking something like oembed.php)

[swissspidy]

Note that since [35436] the oEmbed endpoint URL looks like this:

http://example.com/wp-json/oembed/1.0/embed/?url=<url>

I assume this is enough for your use case as you can easily block that on the server if you want.

[pento]

The embed content also sends the HTTP header X-WP-embed: true. This can easily be used as the canonical method for blocking access to the embed content.

Finally, there are several filters available for you to programatically block access.

[mark-k]

Replying to pento:

The embed content also sends the HTTP header X-WP-embed: true. This can easily be used as the canonical method for blocking access to the embed content.

Please don't say that something is easy if you can't show that it is easy.I doubt that drupal twitter or facebook will send that header. oEmbed is intended hopfully to be used by all sites on the web and not just wordpress, otherwise I fail to find the feature usefull at all.

Finally, there are several filters available for you to programatically block access.

so what? why should I bwaste CPU on something I don't want to support? CPU for getting all options from DB and then parsing URL just to do nothing?

[mark-k]

grr maybe my misunderstanding. Is the JS supposed to send that header? In that case it may work, but this needs to be officially documented.

[swissspidy]

@mark-k For clarification, are you talking about the oEmbed endpoint (http://example.com/wp-json/oembed/1.0/embed/?url=<url>) or the embed endpoint for a specific post (http://example.com/my-post/embed/)?

[mark-k]

Replying to swissspidy:

@mark-k For clarification, are you talking about the oEmbed endpoint (http://example.com/wp-json/oembed/1.0/embed/?url=<url>) or the embed endpoint for a specific post (http://example.com/my-post/embed/)?

Essentially both. I don't know what will be the usage pattern and how will bots react to this feature, so IMHO it is better to err on the side of having too much security/performance related options then not having enough.

To clarify my position, I am not against any specific pattern, but blocking the features at the webserver level should be done in a way that not very technical people will be able to copy&paste into their htaccess file.

[dd32]

This is easily blocked/handled in server configurations, however that is the wrong place to do so.

I use something similar to the following (bad) nginx configuration lines to affect caching on my own site: (I'm only doing so for experimentation of how the feature works, not because it needs it - normal caching plugins still work great here)

if ( $request_uri ~* "/wp-json/oembed/|/embed/$" ) {
     # Magic happens here if they're using URL rewriting
}
if ( $request_uri ~* "\?rest_route=/oembed/|oembed=true" ) {
   # Magic for sites not using pretty permalinks 
}

The embed content also sends the HTTP header X-WP-embed: true. This can easily be used as the canonical method for blocking access to the embed content.

I doubt that drupal twitter or facebook will send that header.

There's a bit of confusion here, that header is sent by WordPress on output, as a way for the server to change it's behaviour when serving the request, it shouldn't/can't be used for blocking the request. It's not available during the oEmbed discovery or client-side embed requests.

Ultimately you're doing it incredibly wrong if you're wanting to block this at the server level, you'll still have the tags on the page advertising the functionality. A plugin is the correct route of disabling it.

The URL structures presented by WordPress are going to remain as-is, we're not going to create a single file for these requests to go through.
Trac is not for support either, if you require specific help on how to configure your server to work as you want it to, try the ​WordPress support forums or ideally a support resource dedicated to your webserver of choice.

[mark-k]

none of the rules answer for ​http://example.com/my-post/embed/ I wonder how easy it will be to do it while still providing access to the great page I have with the slug "embed". Anyway the second one is convoluted and will easily block things in a surprising way. Might as well just say that the oEmbed feature work only when mod_rewrite is active.

So far two closings of the ticket with neither fully answering the issue, except for really saying "we are smarter then you and know better then you so trust us". Guess it is time to avoid trac again.