Problem/Motivation
As documented in #3208830: [policy, no patch] Secondary subdomain for viewing oEmbed content is confusing and pointless:
When the oEmbed system was added to the core Media module, one of the protections added against malicious JavaScript was the suggestion that site owners configure their Drupal site to be visible through a subdomain alias (basically, oembed.example.com == example.com) so that malicious JavaScript served from an oEmbed provider would have an additional hoop to jump through. We felt strongly enough about this measure that, if oEmbed content is not served in a subdomain, we display a warning on the status report page.
However, this is tricky to set up -- it's poorly documented and the warning drives site builders crazy (as evidenced by discussion in #2965979: [PP-1] Validate alternate domain for oEmbed iFrame) until they get it set up properly. And even when they do, it's not clear that there is actually a security improvement here.
If a subdomain is used, browsers consider it to be part of the main site, so it can share cookies with the main domain.
If a completely different domain is used instead of a subdomain, users can go directly to the second domain, which, because it is the same Drupal site, is configured to use itself as the iFrame domain.The oEmbed specification recommends that the HTML within the iFrame be hosted on another domain. The intention is for the HTML within the iFrame to be entirely separate from the main site. It does not recommend using a subdomain, or that the entire site be accessible from the other domain.
Long story short, in #3208830-27: [policy, no patch] Secondary subdomain for viewing oEmbed content is confusing and pointless @longwave confirmed we can remove the warning while we pursue a more achievable fix.
Steps to reproduce
- Enable Media module
- Go to Drupal status page

Proposed resolution
Remove the warning, for all the reasons documented in #3208830: [policy, no patch] Secondary subdomain for viewing oEmbed content is confusing and pointless
Remaining tasks
Review by core maintainers
User interface changes
No more warning
Introduced terminology
No
API changes
No
Data model changes
No
| Comment | File | Size | Author |
|---|---|---|---|
| #37 | Befor Oembed warning.png | 89.23 KB | sagarmohite0031 |
| #37 | After Oembed warning.png | 74.17 KB | sagarmohite0031 |
| #36 | 2962753After.png | 24.35 KB | asawari |
| #36 | 2962753Before.png | 39.8 KB | asawari |
| #28 | 2024-08-12_11-55_.png | 68.13 KB | ivnish |
Issue fork drupal-2962753
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 2962753-expose-a-way
changes, plain diff MR !9074
- 2962753-remove
changes, plain diff MR !10311
Comments
Comment #2
phenaproximaThe main issue is in.
Comment #3
phenaproximaComment #6
phenaproximaComment #9
phenaproximaComment #16
simeI decided to work on a template site and clean up some warnings in the status report. I've never really focussed on this warning before and I can point to commodity government platforms that do not address this warning (I guess they made an assessment about the risk and decided to live with it).
Anyway here's just an anecdotal story about trying to remove this error on Platform.sh, and might be a good benchmark to consider the UX for non-technical people.
I figured the goal was to add another domain to my site. Like a multi-site I guess. Platform.sh allows you to add multiple domains to point to the same site, but the way all the examples are setup they assume you'll be redirecting to one domain at the edge. They have an option to handle all domains as legitimate (
"https://{all}/") - this functionality was likely added to support a traditional multisite setup with multiple legitimate domains, but that's not quite what I'm trying to do. One of the domains is legitimate, and one should only work in certain scenarios?I guess it wasn't too hard to set it up on Platform.sh after I decided how to set up my routes, but there was definitely not a way to generically set it up. Drupal 10 doesn't really have a domain setting since we removed
$base_url, which is something I take for granted when setting up a boilerplate site. This oembed setting appears to require a fully qualified domain, so I'm either faced with hardcoding this into the settings, or programmatically set it in settings.php. I guess the mum/dad site builders will just hardcode it once they work out how to add another domain to their site.For the sake of sharing my thinking patterns this is what i settled on. I decided to base the media domain on the main domain. I wanted to make this a subdomain like
media.demo-sitebut then I had to negotiate certificate setup on Cloudflare. If was using the apex this would have been a little easier i could have used www. and non-www. for eg.So then i have two domains. I really don't want them both to serve the main site. Redirect module doesn't provide any handling for this case in the global redirect handling - how could it, it doesn't know the base url since Drupal 8. I guess I'm going to code this redirect. I don't think this is a great option for site builders at all and it feels weird that Drupal is making me do all this to get rid of a warning that I know for a fact a lot of sites never address.
Am i missing something in how to address this issue?
Comment #17
ivnishComment #19
ivnishComment #20
smustgrave commentedWill need an upgrade hook for the new setting.
Comment #21
ivnishComment #22
smustgrave commentedThis one feel close
So the issue summary does need to be complete. Currently has TBD sections, proposed solution needs to be filled in. UI Changes should have a screenshot in that section, API and Data model probably N/A here.
Also the new setting will require a change record so tagging for that.
Thanks.
Comment #23
ivnishComment #24
ivnishComment #25
ivnishIssue summary fixed
New change record was created https://www.drupal.org/node/3467521
Comment #26
smustgrave commentedBelieve feedback has been addressed
Comment #27
quietone commentedI read the is, comment and the MR. Everything is in order here except there should be screen shots available from the issue summary.
I also think the red line in the 'after' screenshot in the change record should be removed and something like a diagonal arrow used to direct attention to the addition. But I am not setting to needs work for that small change. I am assuming the reader will understand.
Comment #28
ivnishComment #29
ivnishThanks @quietone! I fixed an image.
Comment #30
longwaveI'm not really sure we should be adding a setting for this, especially given #3208830: [policy, no patch] Secondary subdomain for viewing oEmbed content is confusing and pointless which might remove the feature entirely. Postponing this and will try to reactivate the discussion over there.
Comment #31
krakenbite commentedThe decision to remove it will take several years, but you can remove the annoying banner right now
Comment #32
pameeela commentedBased on #3208830-27: [policy, no patch] Secondary subdomain for viewing oEmbed content is confusing and pointless, the first agreed step is to remove this warning altogether. So let's do that!
Comment #33
pameeela commentedOh, I didn't notice there was already an MR for the setting.
Comment #35
ivnish@pameeela I added a second MR with removing this warning
Comment #36
asawari commentedHi,
Test status - Pass
Patch applied successfully.
Tested on Drupal Version - 11.X
Steps to reproduce -
1 Enable Media module
2 Go to Drupal status page
Oembed warning is no longer visible.
Please refer the screenshots.
Keeping it in review for further reviews.
Comment #37
sagarmohite0031 commentedHello,
Verified and Tested on Drupal 11,
Patch applied successfully.
Steps to reproduce -
1-Enable Media module
2-Go to Drupal status page
Warning is no longer visible.
attaching screenshots
RTBC+1
Comment #38
longwaveThere is test coverage for this message which also needs removing.
Comment #40
ivnishComment #41
ivnishComment #42
joelpittetBack to RTBC, thanks for removing the test as well ivnish
Comment #45
lauriiiCommitted 23ad40d and pushed to 11.x. Thanks!
Leaving this open in case that we want to backport this to specific release branches.
Comment #51
longwaveDiscussed with the release managers, additionally backported this to 11.1.x and 10.4.x/10.5.x so it can get into the forthcoming releases.
Comment #53
xjmAmending attribution.