Closed
Bug 1094911
Opened 10 years ago
Closed 9 years ago
Cross-Origin Request Blocked error regardless of the actual failure reason
Categories
(Core :: DOM: Security, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: fischer.th, Unassigned)
References
Details
(Whiteboard: [domsecurity-backlog])
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141011015303
Steps to reproduce:
xhr = new XMLHttpRequest()
xhr.open('GET', 'http://a.web.server/with.Access.Control.Allow.Origin.*');
xhr.send();
setTimeout(function(){xhr.abort()}, 1)
Actual results:
The console logs:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://a.web.server/with.Access.Control.Allow.Origin.*. This can be fixed by moving the resource to the same domain or enabling CORS.
Expected results:
no error should be logged / thrown
Comment 1•10 years ago
|
||
Thomas:
Is this something new in Firefox33 ?
Could you provide a URL to test this ?
Component: Untriaged → DOM: Security
Product: Firefox → Core
Reporter | ||
Comment 2•10 years ago
|
||
Hi,
It also happens on Mac FF 31.0 and Win FF 33.02, 33.03
It also happens in case of DNS errors (e.g. if TLD is ".foobar" instead of ".org")
// Open "about:blank" and run this code in the console (with a actual CORS server):
xhr = new XMLHttpRequest();
xhr.open('GET', 'http://api.geonames.org/postalCodeLookupJSON?' + Math.random());
xhr.onabort = xhr.onerror = xhr.onload = function(evt){console.log(evt.type)};
xhr.send();
void setTimeout(function(){xhr.abort()}, 1);
Expected console output:
"abort"
Actual console output:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote
resource at http://api.geonames.org/postalCodeLookupJSON?0.14136032733959392.
This can be fixed by moving the resource to the same domain or enabling CORS.
"abort"
This bug still exists in FF 35.0 on Win7 (while Chrome, Safari, even IE perform well with this)
Was there anything researched/done about this last year?
When a pending request to a CORS resource is aborted, the internal logic should determine if this abort was explicitly triggered by an xhr.abort() through the user's own javascript (which may be desired behaviour) - or if this abort was triggered by some internal validation (e.g. server did not sent proper CORS headers).
For the user experience this bug is irrelevant, but as a developer one is constantly spammed by red messages in the console which is annoying. On the other hand one could disable the security messages, but then one could miss real security issue messages.
Comment 4•10 years ago
|
||
Bug 1133496 has another reason (blocked RC4 connections) of the inappropriate message.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Cross-Origin Request Blocked error when aborting an ongoing CORS XHR → Cross-Origin Request Blocked error regardless of the actual failure reason
Comment 5•9 years ago
|
||
I think I remember we fixed a similar problem a while ago. Kamil, Matt can we still reproduce that error?
Flags: needinfo?(mwobensmith)
Flags: needinfo?(kjozwiak)
Whiteboard: [domsecurity-backlog]
Updated•9 years ago
|
QA Contact: kjozwiak
Comment 6•9 years ago
|
||
Reproduced the original issue in OSX 10.11.3 x64 using the following build:
* https://archive.mozilla.org/pub/firefox/releases/31.0/mac/en-US/
Reproduced the original issue in Win 10 x64 VM using the following build:
* https://archive.mozilla.org/pub/firefox/releases/33.0.2/win32/en-US/
Received the following error via the browser console:
* Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://api.geonames.org/postalCodeLookupJSON?0.16570577151905164. This can be fixed by moving the resource to the same domain or enabling CORS. postalCodeLookupJSON
* "abort"
Went through verification with OSX 10.11.3 x64 and Win 10 x64 VM with the following build:
* https://archive.mozilla.org/pub/firefox/nightly/2016/03/2016-03-16-03-02-33-mozilla-central/
* https://archive.mozilla.org/pub/firefox/nightly/2016/03/2016-03-16-00-40-53-mozilla-aurora/
* https://archive.mozilla.org/pub/firefox/candidates/46.0b2-candidates/build2/
* https://archive.mozilla.org/pub/firefox/releases/45.0/
Results:
* fx48.0a1 - PASSED (Win 10/OSX)
** only received the "abort" message via the browser console
* fx47.0a2 - PASSED (Win 10/OSX)
** only received the "abort" message via the browser console
* fx46.0b2 - PASSED (Win 10/OSX)
** only received the "abort" message via the browser console
* fx45.0 - PASSED (Win 10/OSX)
** only received the "abort" message via the browser console
Chris, looks like this isn't an issue anymore. I reproduced the original problem using both fx31 and fx33.0.2 but can't reproduce the problem under fx48.0a1, fx47.0a2, fx46.0b2 and fx45.0.
Flags: needinfo?(mwobensmith)
Flags: needinfo?(mozilla)
Flags: needinfo?(kjozwiak)
Comment 7•9 years ago
|
||
(In reply to Kamil Jozwiak [:kjozwiak] from comment #6)
> Chris, looks like this isn't an issue anymore. I reproduced the original
> problem using both fx31 and fx33.0.2 but can't reproduce the problem under
> fx48.0a1, fx47.0a2, fx46.0b2 and fx45.0.
Awesome. Thanks Kamil!
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(mozilla)
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•