Vyhľadajte odpoveď

Vyhnite sa podvodom s podporou. Nikdy vás nebudeme žiadať, aby ste zavolali alebo poslali SMS na telefónne číslo alebo zdieľali osobné informácie. Nahláste prosím podozrivú aktivitu použitím voľby “Nahlásiť zneužitie”.

Learn More

Firefox local development "CORS request not http"

more options

As of update to v68 I get errors like these: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at file:///D:/website/fonts/fontawesome-webfont.woff?v=4.2.0. (Reason: CORS request not http).

What the heck is this? Why did silly mozila messed up the development of local files? How can I bypass that WITHOUT ALTERING my code? It broke fontawesome functionality! Very stupid!

As of update to v68 I get errors like these: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at file:///D:/website/fonts/fontawesome-webfont.woff?v=4.2.0. (Reason: CORS request not http). What the heck is this? Why did silly mozila messed up the development of local files? How can I bypass that WITHOUT ALTERING my code? It broke fontawesome functionality! Very stupid!

Vybrané riešenie

hi, perhaps due to this security fix: https://www.mozilla.org/en-US/security/advisories/mfsa2019-21/#CVE-2019-11730

try to change privacy_file_unique_origin to false in about:config, restart firefox and see if this can make a difference (please note that this makes you vulnerable to the described security problem though).

Čítať túto odpoveď v kontexte 👍 1

Všetky odpovede (17)

more options

Vybrané riešenie

hi, perhaps due to this security fix: https://www.mozilla.org/en-US/security/advisories/mfsa2019-21/#CVE-2019-11730

try to change privacy_file_unique_origin to false in about:config, restart firefox and see if this can make a difference (please note that this makes you vulnerable to the described security problem though).

more options

philipp said

hi, perhaps due to this security fix: https://www.mozilla.org/en-US/security/advisories/mfsa2019-21/#CVE-2019-11730 try to change privacy_file_unique_origin to false in about:config, restart firefox and see if this can make a difference (please note that this makes you vulnerable to the described security problem though).

You are a star! Everything now is back to normal. This is pretty stupid on mozilla's part!

more options

The proposed solution is not ideal in that it requires local HTML files that use local fonts to change their default about:config settings. It would be better if FireFox allowed fonts such as: font-awesome to load without going through CORS. Here is the warning: The Same Origin Policy disallows reading the remote resource at file:///.../font-awesome/fonts/fontawesome-webfont.woff2?v=4.7.0. (Reason: CORS request not http).

more options

Hi mcdow, the security patch redefined the "origin" of a document with a file:// URL, which is why the console now reports cross-origin blocks on some retrievals. If you decide to reverse that, please make sure to open untrusted pages from their own folders (for example, create Download\untrusted) to limit access to potentially valuable files.

more options

Hi jscher,

Understood, but redefining all local file resources to have a unique origin breaks Mozilla's previous standard:

https://developer.mozilla.org/en-US/docs/Archive/Misc_top_level/Same-origin_policy_for_file:_URIs

This seems severe as the other browser vendors are NOT doing that with their origin definitions. This also makes using browsers for local help very limited. I hope Mozilla will reconsider.

more options

Hi mcdow, is there a page documenting how it works in other browsers?

Help systems that were taking advantage of the broader functionality in Firefox will need to change. For example, treating Firefox as having the more limited capabilities that have been available in Chrome: https://discourse.mozilla.org/t/firefox-68-local-files-now-treated-as-cross-origin-1558299/42493

more options

Hi jscher2000,

The link I posted describes how it works on other browsers. For 'file:' resources, origin should be the same for files in the same or child directories as defined in the statement here.

https://developer.mozilla.org/en-US/docs/Archive/Misc_top_level/Same-origin_policy_for_file:_URIs

Currently, in v68 this breaks many (1000s if not more) users accessing local help content using FireFox. User's can switch to another browser and the local resources will work. Is there a place where I can upload an example? Thank you.

more options

mcdow said

Currently, in v68 this breaks many (1000s if not more) users accessing local help content using FireFox. User's can switch to another browser and the local resources will work. Is there a place where I can upload an example?

If copyright permits, sure, or perhaps there is a sample online that could be downloaded for testing.

By the way, I did file a bug yesterday proposing an exception for .woff and .woff2 font files. Waiting to see whether that is considered feasible.

more options

Hi jscher2000,

>By the way, I did file a bug yesterday proposing an exception for .woff and .woff2 font files.

Thank you, this would help. I would add .ttf font files as well.

more options

I have this problem too. It wouldn't be so bad if FF would let me keep using v. 67.x until the problem was fixed, but the new (broken) version 68.0 is automatically installed, even though my settings says to ask me for confirmation first :(

more options

Hi Arne, Firefox 68 contains a security patch which restricts the kinds of files that pages can load (and methods of loading) when you open them from a file:// URL. This change was made to prevent exfiltration of valuable data within reach of a local page, as demonstrated in an available exploit. More info:

There is a bug on file proposing that fonts be an exception, but it will take time to implement. For now, you can roll back the patch as follows:

(1) In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button promising to be careful or accepting the risk.

(2) In the search box above the list, type or paste uniq and pause while the list is filtered

(3) Double-click the privacy.file_unique_origin preference to switch the value from true to false

To mitigate the vulnerability: If you save pages from untrusted sites in a separate folder, e.g., Downloads\Untrusted, then it would be difficult for an attacker to find any valuable content using local file links.

more options

This has broken my scripts that set document properties such as window title and innerHtml because the related files are no longer same-site origin.

These scripts work fine when served from the web, but no longer work when the entire site is saved and viewed statically using the file:/// uri.

Is this collateral damage or was this really the intention?

My use case is generating large folders of html showing simulation results and saving these to disk. A browser is then used to navigate through the files in either online or offline mode. The html includes a few scripts to aid in navigation. Unfortunately the navigation scripts are now broken. There may be a workaround going forward, but years worth of folders of results can no longer be navigated.

more options

opeongo said

This has broken my scripts that set document properties such as window title and innerHtml because the related files are no longer same-site origin.

You can still set the title and the innerHTML of elements. However, you can't use XMLHttpRequest to read local files.

My use case is generating large folders of html showing simulation results and saving these to disk. A browser is then used to navigate through the files in either online or offline mode. The html includes a few scripts to aid in navigation. Unfortunately the navigation scripts are now broken. There may be a workaround going forward, but years worth of folders of results can no longer be navigated.

I don't know how your script works. Is it centralized -- not repeated in every file -- so that it would be worthwhile to detect the failure to retrieve the external file and provide an alternate method to view it?

Regarding your existing results, you could consider using the workaround earlier in this thread.

more options

Setting titles does seem to partially work, but I am getting this error in the console:

 SecurityError: Permission denied to access property "document" on cross-origin object

The line that triggers the error is:

  parent.document.title=title;

I tried disabling the privacy.file_unique_origin property and this error goes away.

More importantly it appears that the following doesn't to anything under V68 when the privacy.file_unique_origin is set (no error, but also no action), but it works when the property is unset (I am only 95% sure that this is the problem line):

  window.open(aReport, aTarget, "");

This method is more important to my navigation scheme than title setting. Perhaps this uses XMLHttpRequest under the hood?

I can change this property in my browser, but it does not fix the situation for others who view the archive, and I am not sure that I should recommend to them to change their properties the same way.

Upravil(a) opeongo dňa

more options

opeongo said

Setting titles does seem to partially work, but I am getting this error in the console:
SecurityError: Permission denied to access property "document" on cross-origin object
The line that triggers the error is: parent.document.title=title;

I guess you use frames or iframes in your layout? In that case I see why the patch causes a problem.

More importantly it appears that the following doesn't to anything under V68 when the privacy.file_unique_origin is set (no error, but also no action), but it works when the property is unset (I am only 95% sure that this is the problem line): window.open(aReport, aTarget, ""); This method is more important to my navigation scheme than title setting. Perhaps this uses XMLHttpRequest under the hood?

Is aTarget the name of a frame or iframe? (I wouldn't expect a problem if aTarget = "_blank", for example.)

I can change this property in my browser, but it does not fix the situation for others who view the archive, and I am not sure that I should recommend to them to change their properties the same way.

I think you can provide them the information in my earlier post and let them decide whether they are okay with that or prefer to use a different browser that doesn't have this restriction.

more options

Yes, I am using frames. I have a frame on the left with an explorer-style tree of links. The content frame takes up the rest of the space. Clicking on a item in the tree on the left is supposed to replace the content on the right. Also supposed to set the window title appropriately for the page being shown. Still works fine when served by http.

If reading from the local file system is out, then is the approach I am using obsoleted? It is no longer possible in Firefox to control content of a sibling frame when loading from a file:/// uri?

Why does the "_blank" target work, but a sibling frame target does not? Is there any other middle ground on this, or any other possibilities to get something working without throwing the lot away?

If I ditch the frames I suppose I can just make plain links open in the current window, it will mean reworking the navigation to maintain context. Bleh, at lot of churn...

more options

Hi opeongo, perhaps you will need to go back to basics and change the link from using a script to just targeting the frame, assuming that is not blocked. I don't know what your code looks like, but for example:

Before:

<a onclick="window.open(url, framename); return false">

After:

<a href="url" target="framename">