blocks|key|102773|text|因为object标记在HTML文档中定义了一个嵌入的对象，所以它不是文档本身的一部分，因此必须像框架一样尊重CORS|type|unstyled|depth|inlineStyleRanges|entityRanges|data|102774|Same-origin+policy|offset|length|102775|here清楚地指出，object标记的内容被视为外部资源|102776|102777|元素表示外部资源，可以将其视为图像、嵌套的浏览上下文或要由插件处理的资源。|blockquote|style|BOLD|102778|102779|entityMap|0|LINK|mutability|MUTABLE|url|https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy|1|https://developer.mozilla.org/en-US/docs/Web/HTML/Element/object^0|0|0|I|0|0|0|4|1|0|0|4|4|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@$D|10|E|11|1|12]]|A|$]]|$1|F|3|G|5|6|7|13|8|@]|9|@$D|14|E|15|1|16]]|A|$]]|$1|H|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|18|8|@$D|19|E|1A|L|M]]|9|@]|A|$]]|$1|N|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|P|$Q|$5|R|S|T|A|$U|V]]|W|$5|R|S|T|A|$U|X]]]]

because the object tag defines an embedded object within the HTML document, it's not part of the document itself, and therefore must respect the CORS like a frame

<a href="https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy" rel="nofollow noreferrer">Same-origin policy</a>

<a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/object" rel="nofollow noreferrer">here</a> clearly states that the content of the object tag is considered an external resource

<blockquote>
 The HTML element represents an external resource, which can be treated as an image, a nested browsing context, or a resource to be handled by a plugin.
</blockquote>

blocks|key|2635851|text|这里的问题是，data:+URLs+are+treated+as+having+a+unique+origin与创建嵌入式data:上下文的上下文的来源不同：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2635852|2635853|+注意:现代浏览器将数据URL视为唯一的不透明来源，而不是继承负责导航的设置对象的来源。|blockquote|BOLD|2635854|2635855|2635856|WHATWG规范描述了how+content+documents+are+accessed，它包括交叉来源检查。WHATWG+same-origin+comparison永远不会将传统方案-主机-端口“元组”来源等同于“不透明”的data:来源。|2635857|取而代之的是，使用带有URL.createObjectURL的Blob来生成一个同源的临时URL，其内容将由外部环境读取：|2635858|var+svgUrl+=+URL.createObjectURL(new+Blob([svg],+{'type':'image/svg%2Bxml'}));
obj.setAttribute('data',+svgUrl);|code-block|syntax|javascript|2635859|我不知道这种方法被允许而原始data:+URL不被允许的安全原因，但它似乎确实有效。(我猜是因为生成的URL只能由生成它的源读取，而data:+URL不知道如何只由其原始上下文的原始上下文读取。)|2635860|另请注意，某些版本的Internet+Explorer支持createObjectURL，但错误地将生成的URL视为具有空源，这将导致此方法失败。|2635861|其他选项包括：|2635862|SVG不要使用SVG，而是从创建|2635863|和contentDocument的页面的同一来源提供data:内容，并使用inline++element+(fiddle)：|unordered-list-item|2635864|2635865|const+obj+=+document.createElement('div')；obj.innerHTML+=+svg；app.appendChild(obj)；setTimeout(()+=>+{+console.log(obj.querySelector('svg'))；}，1500)；|2635866|大多数浏览器都支持内联<svg>元素(特别是IE+9.0%2B；其他浏览器要早得多)。这意味着你可以根据你想要对SVG做什么来做|2635867|，你可以在解析器中load+it+into+a+DOMParser和做DOM探索/操作。|2635868|2635869|var+oParser+=新的DOMParser()；var+svgDOM+=+oParser.parseFromString(svg，“文本/xml”)；var|2635870|但是DOM模型将与在<object>中呈现的SVG分开。要更改<object>，您需要序列化已解析的DOM结构，并将其重新推送到data属性：|2635871|var+oSerializer+=新数据()；var+sXML+=+oSerializer.serializeToString(svgDOM)；obj.setAttribute('data'，data:image/svg%2Bxml;+base64,${btoa(sXML)})；|2635872|这看起来性能不是很好，因为它需要浏览器重新解析一个全新的SVG文档，但它将绕过安全限制。|2635873|可以将<object>看作一个单向黑洞，它可以接收要呈现的SVG信息，但不会公开任何返回的信息。不过，这不是一个信息学问题，因为您拥有刚刚输入到<object>中的信息：contentDocument可以告诉您的信息都是您已经知道的。|2635874|但是，如果您想通过将侦听器附加到在主页上执行代码的SVG结构中的组件来使SVG中的组件具有交互性，我认为这种方法是行不通的。与<iframe>.一样，<object>与其周围页面之间的分隔具有相同的嵌入关系|2635875|entityMap|0|LINK|mutability|MUTABLE|url|https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs|1|https://html.spec.whatwg.org/multipage/browsers.html#concept-bcc-content-document|2|https://html.spec.whatwg.org/multipage/origin.html#same-origin-domain|3|https://developer.mozilla.org/en-US/docs/Web/SVG/Element/svg|4|https://jsfiddle.net/31a9myjg/|5|https://developer.mozilla.org/en-US/docs/Web/Guide/Parsing_and_serializing_XML^0|7|5|1P|5|7|1C|0|0|0|1|9|0|0|0|37|5|B|Y|1|1K|T|2|0|B|J|V|4|0|0|E|5|1U|5|0|T|F|0|0|0|1|F|Q|5|11|F|3|1I|6|4|0|0|0|B|5|0|O|9|9|O|5|0|0|0|A|8|V|8|1S|4|0|2O|14|0|0|3|8|20|8|2D|F|0|1R|8|23|8|0^^$0|@$1|2|3|4|5|6|7|28|8|@$9|29|A|2A|B|C]|$9|2B|A|2C|B|C]]|D|@$9|2D|A|2E|1|2F]]|E|$]]|$1|F|3|-4|5|6|7|2G|8|@]|D|@]|E|$]]|$1|G|3|H|5|I|7|2H|8|@$9|2I|A|2J|B|J]]|D|@]|E|$]]|$1|K|3|-4|5|6|7|2K|8|@]|D|@]|E|$]]|$1|L|3|-4|5|6|7|2L|8|@]|D|@]|E|$]]|$1|M|3|N|5|6|7|2M|8|@$9|2N|A|2O|B|C]]|D|@$9|2P|A|2Q|1|2R]|$9|2S|A|2T|1|2U]]|E|$]]|$1|O|3|P|5|6|7|2V|8|@$9|2W|A|2X|B|C]|$9|2Y|A|2Z|B|C]]|D|@]|E|$]]|$1|Q|3|R|5|S|7|30|8|@]|D|@]|E|$T|U]]|$1|V|3|W|5|6|7|31|8|@$9|32|A|33|B|C]|$9|34|A|35|B|C]]|D|@]|E|$]]|$1|X|3|Y|5|6|7|36|8|@$9|37|A|38|B|C]]|D|@]|E|$]]|$1|Z|3|10|5|6|7|39|8|@]|D|@]|E|$]]|$1|11|3|12|5|6|7|3A|8|@]|D|@]|E|$]]|$1|13|3|14|5|15|7|3B|8|@$9|3C|A|3D|B|C]|$9|3E|A|3F|B|C]]|D|@$9|3G|A|3H|1|3I]|$9|3J|A|3K|1|3L]]|E|$]]|$1|16|3|-4|5|6|7|3M|8|@]|D|@]|E|$]]|$1|17|3|18|5|6|7|3N|8|@]|D|@]|E|$]]|$1|19|3|1A|5|6|7|3O|8|@$9|3P|A|3Q|B|C]]|D|@]|E|$]]|$1|1B|3|1C|5|15|7|3R|8|@$9|3S|A|3T|B|C]]|D|@$9|3U|A|3V|1|3W]]|E|$]]|$1|1D|3|-4|5|6|7|3X|8|@]|D|@]|E|$]]|$1|1E|3|1F|5|6|7|3Y|8|@]|D|@]|E|$]]|$1|1G|3|1H|5|6|7|3Z|8|@$9|40|A|41|B|C]|$9|42|A|43|B|C]|$9|44|A|45|B|C]]|D|@]|E|$]]|$1|1I|3|1J|5|6|7|46|8|@$9|47|A|48|B|C]]|D|@]|E|$]]|$1|1K|3|1L|5|6|7|49|8|@]|D|@]|E|$]]|$1|1M|3|1N|5|6|7|4A|8|@$9|4B|A|4C|B|C]|$9|4D|A|4E|B|C]|$9|4F|A|4G|B|C]]|D|@]|E|$]]|$1|1O|3|1P|5|6|7|4H|8|@$9|4I|A|4J|B|C]|$9|4K|A|4L|B|C]]|D|@]|E|$]]|$1|1Q|3|-4|5|6|7|4M|8|@]|D|@]|E|$]]]|1R|$1S|$5|1T|1U|1V|E|$1W|1X]]|1Y|$5|1T|1U|1V|E|$1W|1Z]]|20|$5|1T|1U|1V|E|$1W|21]]|22|$5|1T|1U|1V|E|$1W|23]]|24|$5|1T|1U|1V|E|$1W|25]]|26|$5|1T|1U|1V|E|$1W|27]]]]

The problem here is that <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs" rel="noreferrer"><code>data:</code> URLs are treated as having a unique origin</a> that differs from the origin of the context that created the embedded <code>data:</code> context:

<blockquote>
 Note: Data URLs are treated as unique opaque origins by modern browsers, rather than inheriting the origin of the settings object responsible for the navigation.
</blockquote>

The WHATWG specification describes <a href="https://html.spec.whatwg.org/multipage/browsers.html#concept-bcc-content-document" rel="noreferrer">how content documents are accessed</a>, which includes a cross origin check. The <a href="https://html.spec.whatwg.org/multipage/origin.html#same-origin-domain" rel="noreferrer">WHATWG same-origin comparison</a> will never treat a traditional scheme-host-port "tuple" origin as equal to an "opaque" <code>data:</code> origin.

Instead, use <code>Blob</code> with <code>URL.createObjectURL</code> to generate a same-origin temporary URL whose contents will be readable by the outer environment:

<pre><code>var svgUrl = URL.createObjectURL(new Blob([svg], {'type':'image/svg+xml'}));
obj.setAttribute('data', svgUrl);
</code></pre>

I don't know the security reason why this approach is allowed while a raw <code>data:</code> URL is not, but it does appear to work. (I guess because the generated URL is readable only by the origin that generated it, whereas a <code>data:</code> URL doesn't know how to be readable only by the original of its originating context.)

Note also that some versions of Internet Explorer support <code>createObjectURL</code> but erroneously treat the generated URLs as having a null origin, which would cause this approach to fail.

Other options are:

<ol>
<li>Don't use a <code>data:</code> URL and instead serve the SVG content from the same origin as your page that creates the <code>&lt;object&gt;</code> element.</li>
<li>Ditch the <code>&lt;object&gt;</code> and <code>contentDocument</code> altogether and use an <a href="https://developer.mozilla.org/en-US/docs/Web/SVG/Element/svg" rel="noreferrer">inline <code>&lt;svg&gt;</code> element</a> instead (<a href="https://jsfiddle.net/31a9myjg/" rel="noreferrer">fiddle</a>):

<pre><code>const obj = document.createElement('div');
obj.innerHTML = svg;
app.appendChild(obj);
setTimeout(() =&gt; {
 console.log(obj.querySelector('svg'));
}, 1500);
</code></pre>

Most browsers support inline <code>&lt;svg&gt;</code> elements (notably, IE 9.0+; other browsers much earlier). This means you can do

<pre><code>&lt;div&gt;
 &lt;svg&gt;
 ...
 &lt;/svg&gt;
&lt;/div&gt;
</code></pre>

and it will just render the SVG document inside the <code>&lt;div&gt;</code> as you would expect.</li>
<li>Depending on what you want to do with the SVG, you can <a href="https://developer.mozilla.org/en-US/docs/Web/Guide/Parsing_and_serializing_XML" rel="noreferrer">load it into a <code>DOMParser</code></a> and do DOM exploration/manipulation within the parser.

<pre><code>var oParser = new DOMParser();
var svgDOM = oParser.parseFromString(svg, "text/xml");
console.log(svgDOM.documentElement.querySelector('path'));
svgDOM.documentElement.querySelector('path').remove();
</code></pre>

But the DOM model will be separate from the SVG rendered in the <code>&lt;object&gt;</code>. To change the <code>&lt;object&gt;</code>, you need to serialize the parsed DOM structure and re-push it to the the <code>data</code> property:

<pre><code>var oSerializer = new XMLSerializer();
var sXML = oSerializer.serializeToString(svgDOM);
obj.setAttribute('data', `data:image/svg+xml; base64,${btoa(sXML)}`);
</code></pre>

This doesn't seem super performant, because it needs the browser to re-parse a brand-new SVG document, but it will get around the security restrictions.

Think of the <code>&lt;object&gt;</code> as a one-way black hole that can receive SVG information to render, but will not expose any information back. This isn't an informatic problem, though, since you have the information that you just fed into the <code>&lt;object&gt;</code>: there's nothing that <code>contentDocument</code> can tell you that you don't already know.

However, if you want to make components within the SVG interactive by attaching listeners to components within the SVG structure that execute code on your main page, I don't think this approach will work. The separation between an <code>&lt;object&gt;</code> and its surrounding page has the same kind of embedding relationship as an <code>&lt;iframe&gt;</code>.</li>
</ol>

Consider the following JavaScript snippet:

<pre><code>const app = document.getElementById('root');
const svg = `&lt;svg version="1.1" id="Layer_1"...`;
const obj = document.createElement('object');

obj.setAttribute('type', 'image/svg+xml');
obj.setAttribute('data', `data:image/svg+xml; base64,${btoa(svg)}`);

app.appendChild(obj);

setTimeout(() =&gt; {
 console.log(obj.contentDocument.querySelector('svg'));
}, 1500);
</code></pre>

(See <a href="https://jsfiddle.net/4gqby5cy/" rel="noreferrer">this JSFiddle</a> for a full example)

When this runs, the following error is given in the console (Google Chrome):

<blockquote>
 Uncaught DOMException: Failed to read the 'contentDocument' property from 'HTMLObjectElement': Blocked a frame with origin "<a href="https://fiddle.jshell.net" rel="noreferrer">https://fiddle.jshell.net</a>" from accessing a cross-origin frame.
 at setTimeout (<a href="https://fiddle.jshell.net/_display:77:19" rel="noreferrer">https://fiddle.jshell.net/_display:77:19</a>)
</blockquote>

With that in mind; 

<ol>
<li>Why is this considered a cross-origin request when trying to access the <code>contentDocument</code> of the object that has been created entirely dynamically, with no external resources?</li>
<li>Is there a way to generate SVGs dynamically in this way, without offending the browsers cross-origin policy?</li>
</ol>

Why does dynamically generating an SVG using HTMLObjectElement lead to a Cross-Origin error?

请考虑以下JavaScript代码片段：const app = document.getElementById('root');const svg = `<svg version="1.1" id="Layer_1"...`;const obj = document.createElement('object');ob...

问为什么使用HTMLObjectElement动态生成SVG会导致跨域错误？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么使用HTMLObjectElement动态生成SVG会导致跨域错误？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么使用HTMLObjectElement动态生成SVG会导致跨域错误？
EN