Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.See:
- http://en.wikipedia.org/wiki/Same_origin_policy
- http://www.w3.org/TR/cors/
- http://hacks.mozilla.org/2009/07/cross-site-xmlhttprequest-with-cors/
Basically, this is the problem: when loading JS via
tags, there is no problem, since tags don't need to honor the same origin policy. When you load JS dynamically (e.g. TinyMCE, Panels, etc.), you're violating the same origin policy. The only way around that in older browsers is by using JSONP. Newer browsers support the CORS specification, which allows you to safely load resources from other origins. See http://www.metaltoad.com/blog/using-jsonp-safely for a nice explanation. Browser support (source: http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing):CORS is supported by all browsers based on the following layout engines: - Gecko 1.9.1 (Firefox 3.5[3], SeaMonkey 2.0[4]) and above - WebKit (Initial revision uncertain, Safari 4 and above[5], Google Chrome 3 and above... possibly earlier[6]) - MSHTML/Trident 4.0 (Internet Explorer 8) provides partial support via the XDomainRequest object.[5] The following browsers are also noteworthy in their lack of CORS support: - Opera does not implement CORS as of version 10.61[7]. - Camino does not implement CORS in the 2.0.x release series as these versions are based on Gecko 1.9.0.[8] - As of version 0.10.2, Arora exposes WebKit's CORS-related APIs, but attempted cross-origin requests will fail. [9]So, unfortunately, we'll still have to use JSONP maintain a blacklist of files (specifically JS files) until all browsers (or at least the majority of all internet visits) support CORS. That's at least a few years away. So there's no real rush to support CORS in the CDN module. However, there is one already fairly common case: the loading of web fonts in Firefox >= 3.5. Web fonts are only supported in recent browsers, and recent browsers support CORS. Hence it makes sense to add CORS support for those files (also see #895064: @font-face doesn't work in firefox). See http://openfontlibrary.org/wiki/Blocking_font_linking_from_other_websites for an example. So at least this subset of CORS should be supported by the CDN module. It should at least be documented, but preferably, the CDN module would update the .htaccess file. This does not block the release of version 2.0, it can easily be added later on.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | 982188-10-cdn-cross-domain-docs.patch | 1.34 KB | mr.baileys |
| #3 | cdn-cross-domain-fonts.patch | 835 bytes | mr.baileys |
Comments
Comment #1
tombigel CreditAttribution: tombigel commentedYou have one mistake:
Web Fonts (the EOT format) is supported since IE 4, and SVG fonts are also supported in fairly older browsers.
See here: http://webfonts.info/wiki/index.php?title=@font-face_browser_support
Comment #2
Wim LeersYou're absolutely right. I should have worded that better. But the only combination for which CORS support makes sense today, are today's web font standards in Firefox.
Comment #3
mr.baileysI had filed #1427178: Firefox, CDN, fonts and the W3C Access Control Specification. before finding this issue, so I've marked that one as duplicate of this. Text from that issue copied below:
Firefox 3.5 and above implement the W3C Access Control specification. This causes Firefox to reject requests to cross-domain resources when the request is initiated by XHttpRequest or when requesting fonts, unless the server serving those requests specifically allows cross-domain usage of the resource, for example by using the Access-Control-Allow-Origin header.
We discovered this while troubleshooting missing/incorrect fonts on our site when viewing it with Firefox. The fonts were served by CloudFront based off a CDN far-future URL. All other browsers succesfully rendered the font.
Attached is a patch that we have currently implemented to circumvent the problem. It could be improved by specifying the actual domains in the access control directive (although I don't know how to reliably get a list of possible domain names for a site), and maybe by only setting the Access Control directive for those files where it is needed.
References:
Comment #4
Wim LeersThis would work for your case, but:
- it would not work when the Far Future expiration setting is not enabled; we'll need to document that
- it could be more specific (as you already indicate): it could list only the allowed domains, which would prevent other domains from hotlinking — though this would probably also break pages served from Google's cache, for example. So I'm not sure adding this specificity is a good idea in the first place
We could hardcode a check that only adds this header for font files. But OTOH, it doesn't hurt to have this enabled for other resources.
Thoughts?
Comment #5
Wim LeersMentioned this at #1413156-7: .htaccess rules for Far Future expiration: make it possible to use the Far Future feature directly in Apache, avoiding PHP.
Comment #6
Wim LeersAlso, this won't work on Amazon Cloudfront (which I know you're using) or even S3. See https://forums.aws.amazon.com/thread.jspa?threadID=34281 and https://forums.aws.amazon.com/thread.jspa?threadID=84659.
Solution: store the font as a data URI in a CSS file.
Comment #7
mr.baileysDon't know about S3, but it does seem to work for Amazon Cloudfront:
Comment #8
Wim LeersI see. Hurray, then! :)
Comment #9
Wim LeersAlso: thoughts regarding #4?
Comment #10
mr.baileysWhile the patch in #3 fixed the issue for us, I agree with you that it only works when using the far-future option, might not work with different CDN providers and the "*" could be considered to broad.
Hence it's probably best not to add the header via code, but rather document the issue and tell people how to fix it (and tailor the solution to their specific set-up). Here's a draft blurb, might need some polishing... (Let me know if you think there should be a similar text for the Advanced Help).
Comment #11
mr.baileys(Note that the "exclude files from being served by CDN" in the patch might not work yet due to #1428530: Override CSS aggregation to ensure correct file URL altering for files referenced by CSS files)
Comment #12
Wim LeersI'm going to a combination of #3 and #10. I think it makes sense to support the 90% use case of allowing all origins to load all "farfutured" files. The documentation you've provided helps in understanding all aspects of the problem.
Comment #13
Wim LeersWith only minor changes, plus an entry in the Advanced Help and a (trivial) backport to D6, I've committed #3 and #10. Of course, I've credited you :) Keep the patches coming!
D7: http://drupalcode.org/project/cdn.git/commit/bb99307
D6: http://drupalcode.org/project/cdn.git/commit/6d42fe8