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

  1. Enable Media module
  2. Go to Drupal status page

screenshot

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

Issue fork drupal-2962753

Command icon 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:

Comments

phenaproxima created an issue. See original summary.

phenaproxima’s picture

Status: Postponed » Active

The main issue is in.

phenaproxima’s picture

Title: [PP-1] Expose a way to suppress oEmbed security warnings » Expose a way to suppress oEmbed security warnings

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

phenaproxima’s picture

Issue tags: +oembed

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

phenaproxima’s picture

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

sime’s picture

I 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-site but 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?

ivnish’s picture

Assigned: Unassigned » ivnish

ivnish’s picture

Assigned: ivnish » Unassigned
Status: Active » Needs review
smustgrave’s picture

Status: Needs review » Needs work
Issue tags: +Needs upgrade path

Will need an upgrade hook for the new setting.

ivnish’s picture

Status: Needs work » Needs review
Issue tags: -Needs upgrade path
smustgrave’s picture

Status: Needs review » Needs work
Issue tags: +Needs change record

This 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.

ivnish’s picture

Issue summary: View changes
StatusFileSize
new58.45 KB
ivnish’s picture

Issue summary: View changes
StatusFileSize
new33.63 KB
ivnish’s picture

Status: Needs work » Needs review
Issue tags: -Needs change record

Issue summary fixed

New change record was created https://www.drupal.org/node/3467521

smustgrave’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: +Needs Review Queue Initiative

Believe feedback has been addressed

quietone’s picture

I 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.

ivnish’s picture

Issue summary: View changes
StatusFileSize
new68.13 KB
ivnish’s picture

Thanks @quietone! I fixed an image.

longwave’s picture

Status: Reviewed & tested by the community » Postponed
Related issues: +#3208830: [policy, no patch] Secondary subdomain for viewing oEmbed content is confusing and pointless

I'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.

krakenbite’s picture

which might remove the feature entirely.

The decision to remove it will take several years, but you can remove the annoying banner right now

pameeela’s picture

Title: Expose a way to suppress oEmbed security warnings » Remove oEmbed security warning
Issue summary: View changes
Status: Postponed » Active

Based 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!

pameeela’s picture

Status: Active » Needs work

Oh, I didn't notice there was already an MR for the setting.

ivnish’s picture

Status: Needs work » Needs review

@pameeela I added a second MR with removing this warning

asawari’s picture

StatusFileSize
new39.8 KB
new24.35 KB

Hi,
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.

sagarmohite0031’s picture

Status: Needs review » Reviewed & tested by the community
StatusFileSize
new74.17 KB
new89.23 KB

Hello,
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

longwave’s picture

Status: Reviewed & tested by the community » Needs work

There is test coverage for this message which also needs removing.

Drupal\Tests\media\Functional\MediaSettingsTest::testStatusPage
Behat\Mink\Exception\ResponseTextException: The text "It is potentially insecure to display oEmbed content in a frame" was not found anywhere in the text of the current page.

longwave changed the visibility of the branch 2962753-expose-a-way to hidden.

ivnish’s picture

Assigned: Unassigned » ivnish
ivnish’s picture

Assigned: ivnish » Unassigned
Status: Needs work » Needs review
joelpittet’s picture

Status: Needs review » Reviewed & tested by the community

Back to RTBC, thanks for removing the test as well ivnish

  • lauriii committed 23ad40d8 on 11.x
    Issue #2962753 by ivnish, asawari, sagarmohite0031, phenaproxima,...

lauriii’s picture

Status: Reviewed & tested by the community » Patch (to be ported)

Committed 23ad40d and pushed to 11.x. Thanks!

Leaving this open in case that we want to backport this to specific release branches.

  • longwave committed 416a7796 on 10.4.x authored by lauriii
    Issue #2962753 by ivnish, asawari, sagarmohite0031, phenaproxima,...

  • longwave committed 697318c5 on 10.5.x authored by lauriii
    Issue #2962753 by ivnish, asawari, sagarmohite0031, phenaproxima,...

  • longwave committed b04a9465 on 11.1.x authored by lauriii
    Issue #2962753 by ivnish, asawari, sagarmohite0031, phenaproxima,...

longwave credited catch.

longwave credited xjm.

longwave’s picture

Version: 11.x-dev » 10.4.x-dev
Status: Patch (to be ported) » Fixed

Discussed 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.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

xjm’s picture

Amending attribution.