X
點擊此處開啟此網站的行動版。

技術支援討論區

Firefox local development "CORS request not http"

已張貼

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!

被選擇的解決方法

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

從原來的回覆中察看解決方案 1
引用

額外的系統細節

已安裝的外掛程式

  • Shockwave Flash 28.0 r0

應用程式

  • User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

更多資訊

philipp
  • Top 25 Contributor
  • Moderator
5306 個解決方法 23424 個答案

選擇的解決方法

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

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).
這篇文章有幫助嗎? 1
引用

提出問題者

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!

''philipp [[#answer-1236131|said]]'' <blockquote> 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). </blockquote> You are a star! Everything now is back to normal. This is pretty stupid on mozilla's part!
這篇文章有幫助嗎? 0
引用
mcdow 0 個解決方法 4 個答案

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

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).
這篇文章有幫助嗎?
引用
jscher2000
  • Top 10 Contributor
8695 個解決方法 71066 個答案

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.

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.
這篇文章有幫助嗎?
引用
mcdow 0 個解決方法 4 個答案

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.

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.
這篇文章有幫助嗎?
引用
jscher2000
  • Top 10 Contributor
8695 個解決方法 71066 個答案

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

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
這篇文章有幫助嗎?
引用
mcdow 0 個解決方法 4 個答案

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.

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.
這篇文章有幫助嗎?
引用
jscher2000
  • Top 10 Contributor
8695 個解決方法 71066 個答案

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.

''mcdow [[#answer-1237587|said]]'' <blockquote>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?</blockquote> 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.
這篇文章有幫助嗎?
引用
mcdow 0 個解決方法 4 個答案

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.

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.
這篇文章有幫助嗎?
引用
Arne 0 個解決方法 1 個答案

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 :(

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 :(
這篇文章有幫助嗎?
引用
jscher2000
  • Top 10 Contributor
8695 個解決方法 71066 個答案

有幫助的回覆

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.

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: * https://developer.mozilla.org/docs/Web/HTTP/CORS/Errors/CORSRequestNotHttp * https://www.mozilla.org/security/advisories/mfsa2019-21/#CVE-2019-11730 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.
這篇文章有幫助嗎? 1
引用
opeongo 0 個解決方法 3 個答案

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.

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.
這篇文章有幫助嗎?
引用
jscher2000
  • Top 10 Contributor
8695 個解決方法 71066 個答案

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.

''opeongo [[#answer-1248560|said]]'' <blockquote> 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. </blockquote> You can still set the title and the innerHTML of elements. However, you can't use XMLHttpRequest to read local files. <blockquote> 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. </blockquote> 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 [[#answer-1237879|earlier in this thread]].
這篇文章有幫助嗎?
引用
opeongo 0 個解決方法 3 個答案

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.

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.

由 opeongo 於 修改

這篇文章有幫助嗎?
引用
jscher2000
  • Top 10 Contributor
8695 個解決方法 71066 個答案

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.

''opeongo [[#answer-1248581|said]]'' <blockquote> Setting titles does seem to partially work, but I am getting this error in the console:<br> SecurityError: Permission denied to access property "document" on cross-origin object <Br> The line that triggers the error is: parent.document.title=title; </blockquote> I guess you use frames or iframes in your layout? In that case I see why the patch causes a problem. <blockquote> 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? </blockquote> Is aTarget the name of a frame or iframe? (I wouldn't expect a problem if aTarget = "_blank", for example.) <blockquote> 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. </blockquote> 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.
這篇文章有幫助嗎?
引用
opeongo 0 個解決方法 3 個答案

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

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...
這篇文章有幫助嗎?
引用
jscher2000
  • Top 10 Contributor
8695 個解決方法 71066 個答案

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">

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:'' &lt;a onclick="window.open(url, framename); return false"> ''After:'' &lt;a href="url" target="framename">
這篇文章有幫助嗎?
引用
問個問題

如果您還沒有帳號,您必須先 登入您的帳號 來回覆文章。請 開始一個新問題