1

I have a very basic ASP.NET MVC 5 application, hosted on an intranet server, where one of the pages has an iframe to display a document:

<div class="document-view-container">
    ...
    <iframe class="document-frame" src="@Url.Action("GetDocumentImage", "Imaging", ...)" ></iframe>   
    ...
</div>

The returned document is sometimes a PDF served as application/pdf, sometimes a piece of text served as text/plain, and sometimes an XML served as text/xml.

The GetDocumentImage method retrieves the document contents from a database and returns it using File:

return File(doc.document.ToArray(), doc.mime_type);

When the document happens to be an XML, it often includes a reference to a stylesheet with which it should be viewed:

<?xml-stylesheet type="text/xsl" href="//server.local/folder/content/grn.xslt"?>
<document>
   ...
</document>

Sometimes that stylesheet comes from the same subdomain as what the @Url.Action() returns (i.e. same origin with the iframe), but sometimes it does not.

When it does not, the stylesheet is successfully loaded and used in Firefox, but Chrome refuses to load the stylesheet and displays an error in console,

Unsafe attempt to load URL http://server.local/folder/content/grn.xslt from frame with URL http://documents.server/imaging/GetDocumentImage/52855. Domains, protocols and ports must match.

This is a known problem, but my understanding was that it only applies to local files, not to files served from a server, and one of the solutions is specifically to host the files on a server. Besides, it works in Firefox.

What is the source of this problem?

  • Is it Chrome, that treats the XML in an iframe as a local file and therefore incorrectly prevents it from requesting a stylesheet from the server?
  • Is it Firefox, that has a security issue where it would allow an XML file from an iframe request a stylesheet when it should be prohibited?
  • Is it me, who is not serving the XML from the server properly enough making Chrome mistake it for a local file?

What is the proper way to fix it?

GSerg
  • 76,472
  • 17
  • 159
  • 346
  • I am surprised that you say the cross domain access works in Firefox, unless perhaps you have CORS enabled for the `http://server.local` and that way Firefox allows the request. I don't think the issue is related to iframes, the restriction is for the cross domain access in general. Can you post the Firefox developer tools network protocol that shows that the request for an XML from `http://documents.server/` to an XSLT from `http://server.local/` goes through? – Martin Honnen Sep 23 '19 at 11:52
  • @MartinHonnen All content actually comes from the same local server/app, it's just that there happens to be several URLs that lead there. I [can see](https://i.stack.imgur.com/VhPPN.png) the request in the developer tools. There is `access-control-allow-origin: *` and `access-control-allow-headers: content-type` in both responses (the one that fetches the XML for the iframe and the one that loads the XSLT - like I said, they come from the same server). The page address is `http://local.XXXXXXXX.co.uk/etc`, same for the iframe, the XSLT is hardcoded in the XML as `//go.swift.local/etc`. – GSerg Sep 23 '19 at 12:24
  • Does Firefox send an `Origin` header on the request to the stylesheet? If the responses have `access-control-allow-origin: *` it looks like CORS is being used and it might be that Firefox allows CORS or uses CORS for `xml-stylesheet` based requests while Chrome might not allow it or might not use it, I don't remember. – Martin Honnen Sep 23 '19 at 12:38
  • @MartinHonnen Firefox does send `Origin`, and the response does have `access-control-allow-origin: *`. Chrome does not send the stylesheet request to begin with. – GSerg Sep 23 '19 at 13:00

1 Answers1

2

I think there are different policies, in Firefox you are able to request the stylesheet as Firefox uses CORS (https://www.w3.org/wiki/CORS#xml-stylesheet_processing_instruction_.28XMLSS.29) on xml-stylesheet based requests while Chrome does not apply CORS on such requests, nor does Safari/Webkit (https://bugs.webkit.org/show_bug.cgi?id=110880).

So the latter block the attempt, the former only fulfills it as it uses CORS for the request and your app on http://documents.server/ is set up to allow requests to anyone by answering with access-control-allow-origin: *. If http://documents.server/ would not do that then the cross origin loading would fail even in Firefox.

Martin Honnen
  • 160,499
  • 6
  • 90
  • 110
  • So, to summarize, Firefox is kind of correct, but the rest are not really going to comply? – GSerg Sep 23 '19 at 13:28
  • These days its considered "correct" by browser implementors to follow Chrome, at least judging by Opera giving up on their on rendering engine and using Chrome's one, Microsoft on the way to integrate Chrome's rendering engine in Edge and Mozilla making breaking changes like disallowing local file system based `xml-stylesheet` completely because Chrome does it anyway. I haven't researched the CORS stuff in detail, it seems that W3C stuff I linked to was explicitly removed from the CORS spec https://www.w3.org/TR/cors/ and is only considered community notes. – Martin Honnen Sep 23 '19 at 13:45
  • https://fetch.spec.whatwg.org/ also exists and contrary to the https://www.w3.org/TR/cors/ spec mentions XSLT (well, "xslt") explicitly and seems to prescribe its use together with CSP and CORS. Will need to check later what it means for `xml-stylesheet` initiated XSLT. – Martin Honnen Sep 23 '19 at 13:47