Youtube embeddings have stopped working for servers in Europe

When you are trying to one-box a youtube URL, Youtube automatically redirects to a page named consent.youtube.com. This page doesn’t have an oEmbed/OpenGraph tag, so oneboxing is unfortunately failing.

Screenshot 2021-04-01 at 18.42.07

This is definitely not Discourse’s flaw, but has to do with a (as it seems) breaking change on Youtube’s end. I suspect this happens due to some new Europe regulation, because I can’t reproduce on meta.

Our server is in Europe (Germany) and you can see the redirecting URL here.

12 Likes

Somewhat eleviated with Onebox Assistant plugin, but not fully (it will render the embed but no longer return the Title).

I think there must be a specific implementation for Youtube through an API key or something…

1 Like

I logged on here last night to report this exact issue as it’s been happening to us recently too, but when I pasted my example YouTube URL, it worked fine here on meta :roll_eyes:

My discourse is v2.7.0.beta5 ( 61860098d9 )

5 Likes

Most probably because meta’s server is not in Europe :sweat_smile:

2 Likes

Neither is the UK now :rofl:

The issue is related to the “Data Consent Form” and OneBox catches that instead of the actual content.

If instead of using the https://youtube.com/watch?v=XYZ you change it to https://youtu.be/XYZ it works because that’s the “Share URL” and that doesn’t pop the Consent Dialog. (However, this is not ideal).

Unless Discourse/OneBox “autochanges” the URL to the “Short Version” when oneboxing, maybe, as a quick fix? IDK, just giving more info/feedback.

10 Likes

As a media-heavy community we have thousands and thousands of YouTube videos shared by our members with several hundred being posted per month.

This change by YouTube is proving to be a real problem already but I don’t think it’s something that can be solved by Discourse if YouTube themselves are forcing a redirect to their consent page?

5 Likes

Just adding my +1 as this will be a big problem for our community too.

5 Likes

Update: Title is working again (as well as embed) with Onebox Assistant.

1 Like

So if discourse were to rewrite the url as you describe when the post was cooked that would fix it?

If that’s the case a plugin could fix it (maybe even a theme component?) , and I would guess that it would be PR welcome and/or that they’ll fix it pretty quick.

Technically, yes. I did many tests and it’s constant, it works with the short URL, not with the “official” one.

3 Likes

I wouldn’t consider that a stable workaround; there’s a good chance Google will apply the same policy to those in the near future too.

2 Likes

Yeah, it isn’t.

Just find it very “funny” because both: https://youtu.be/VIDEO and deleting “www” on the normal url, so: https://youtube.com/watch?v=VIDEO work. So the criteria for “blocking” with the consent popup is not very “logical” from a user’s perspective.

3 Likes

I don’t disagree, but that leaves the only solution being not to use YouTube. :man_shrugging:

1 Like

You’d also need to catch the composer preview, to prevent showing this catastrophic failure message to the user:

1 Like

Ouch, we should certainly investigate this! Thanks for reporting.

13 Likes

Just to add, the same problem occurs for /user/ account links too:

5 Likes

Is it possible for you to test those URLs again? This is what I’m currently seeing from a server in Frankfurt (wget output edited to just show the redirects):

wget 'https://youtu.be/KCyIfcevExE'

--2021-04-06 19:03:39--  https://youtu.be/KCyIfcevExE
Location: https://www.youtube.com/watch?v=KCyIfcevExE&feature=youtu.be [following]

--2021-04-06 19:03:39--  https://www.youtube.com/watch?v=KCyIfcevExE&feature=youtu.be
Location: https://consent.youtube.com/m?continue=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DKCyIfcevExE%26feature%3Dyoutu.be&gl=DE&m=0&pc=yt&uxe=23983172&hl=de&src=1 [following]

or

wget 'https://youtube.com/watch?v=KCyIfcevExE'

--2021-04-06 19:05:45--  https://youtube.com/watch?v=KCyIfcevExE
Location: https://consent.youtube.com/m?continue=https%3A%2F%2Fyoutube.com%2Fwatch%3Fv%3DKCyIfcevExE&gl=DE&m=0&pc=yt&uxe=23983172&hl=de&src=1 [following]

--2021-04-06 19:05:45--  https://consent.youtube.com/m?continue=https%3A%2F%2Fyoutube.com%2Fwatch%3Fv%3DKCyIfcevExE&gl=DE&m=0&pc=yt&uxe=23983172&hl=de&src=1
Location: https://consent.youtube.com/ml?continue=https://youtube.com/watch?v%3DKCyIfcevExE&gl=DE&hl=de&pc=yt&uxe=23983172&src=1 [following]

(i.e., those two URL formats are now also redirecting to the consent page)

3 Likes

I just tried that URL for you, on my UK-based server, and it onebox/previewed fine:

And if I change it to the full / long URL, I get the consent issue again:

3 Likes