SomeRandomGuy

So, apparently, even on a valid request, that response is sent. The test site has the same output but embed is successful. It’s the admin account and both have full permissions to edit posts. Not sure if there is some other kind of misconfiguration.

The only difference I can see is that the failed request results with a 404. The proxied URL is still processed over https however isn’t covered by the SSL certificate.

Ex.

Successful Embed

https://ibb.co/JwnrwQ0r

https://domain.com/wp-json/oembed/1.0/proxy?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DZJ4DLIuxjvw&_locale=user still responds with

{"code":"rest_forbidden","message":"Sorry, you are not allowed to make proxied oEmbed requests.","data":{"status":401}} 

Failed Embed

https://ibb.co/fGQ06Ss0

https://domain.com/wp-json/oembed/1.0/proxy?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DZJ4DLIuxjvw&_locale=user responds with

The webpage at https://domain.com/wp-json/oembed/1.0/proxy?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DZJ4DLIuxjvw&_locale=user might be temporarily down or it may have moved permanently to a new web address.

and

{"code":"oembed_invalid_url","message":"Not Found","data":{"status":404}}

Test site is running the same headers.

It’s got to be something blocking the request from reaching the endpoint?

Not sure how to verify the security token.

• This reply was modified 5 months, 2 weeks ago by SomeRandomGuy.
• This reply was modified 5 months, 2 weeks ago by SomeRandomGuy.
• This reply was modified 5 months, 2 weeks ago by SomeRandomGuy.
• This reply was modified 5 months, 2 weeks ago by SomeRandomGuy.

UPDATE: Been pulling my hair out trying to figure out how to fix this since I have nearly a thousand articles written and quite a lot of them now have dysfunctional YouTube embeds.

Steps taken

• Disabling all plugins
• Switching to default Twenty Twenty Five theme
• Disabling DNS (Cloudflare)
• Removing security headers
• Disabling all caching plugins
• Disabling object cache and backend (Memcached/Redis)
• Clearing server cache (NGINX – Apache/NGINX)
• Reinstalling WordPress 6.9
• Downgrading to WordPress 6.8
• Using third party plugins (Such as Better YouTube Embed Block and EmbedPress) which do work

I was able to reproduce the issue with my old Memcached drop-in on a test environment but not with Redis, although the issue persists on the production environment with Redis.

For some reason, the embeds were restored for a moment when removing the X-Content-Type header but then they failed again and I haven’t been able to reproduce the results again either. This issue does not occur on the test environment.

The web console/developer tools show that the oEmbed API is failing to retrieve proxied content for the embeds from YouTube and removing proxy from the URL does allow it to show up, but this can’t be implemented sitewide or at the very least, I don’t know how as the proxy seems to be ingrained in WordPress’s core.

Search engines pull up some similar events of this happening with older WordPress versions which were resolved with updates or figuring out where a conflict was, although there’s not much else to go on.

Example 1:

https://ww.wp.xz.cn/support/topic/not-allowed-to-make-proxied-oembed-requests/

Example 2:

https://siteorigin.com/thread/unable-to-add-video-could-be-wp-json-rest-api/

If anyone with more skills can help a brother out, that’d be great. Otherwise, I think a bug submission with Gutenberg on GitHub is the right step.

Will update if I find a solution.

• This reply was modified 5 months, 3 weeks ago by SomeRandomGuy.
• This reply was modified 5 months, 3 weeks ago by SomeRandomGuy.

So, it was looking like the X-Content-Type-Options: nosniff header which is implemented on both sites was causing oEmbed to fail and that the object cache was not the real culprit. After disabling the header, I got the videos to embed, but they stopped working again.

Browser console shows that proxied oEmbed requests are failing and returning a 404.

https://ibb.co/r2PJNVyZ

https://ibb.co/pjNQmKLV

For example:

domainname.tld/wp-json/oembed/1.0/proxy?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DTRikFgD2TyY%26themeRefresh%3D1&_locale=user

So, I disabled my CDN (Cloudflare) and disabled any caching plugins to see if that made a difference, of which it didn’t.

I also tested with no Referrer policy as well. Still nothing.

Edit: Removing proxy from the URL works.

• This reply was modified 5 months, 3 weeks ago by SomeRandomGuy.

I found the conflict. It is the Memcached Object cache drop-in provided by https://ww.wp.xz.cn/plugins/memcached-redux/

It may also be Memcached in whole that is preventing embeds, not the drop-in.

Are you aware of any changes to the WP core that are causing this?

• This reply was modified 5 months, 3 weeks ago by SomeRandomGuy.

I’m still working on reproducing the issue with a fresh install. So far I’ve noticed that it only occurs when using links in the embed block.

https://ibb.co/s93XXcNX

No issues with iFrame embeds.

https://ibb.co/xqRzKkcM

Any ideas?

• I am not able to load that page. In fact, I can’t access the dashboard at all as something in the plugin forces a redirect to /wp-admin/options-general.php?page=akismet-key-config&view=start
• I am logged in as admin.
• The most recent version available, 5.6.
• I’m not sure which plugin updates could have caused this but I’ve tried disabling all plugins and also temporarily disabling my DNS, Cloudflare.

Late reply but just in case anyone sees this, figured I’d update. Was SendInBlue issue. Using my own SMTP fixed it.

• This reply was modified 7 years, 2 months ago by SomeRandomGuy.