Open Bug 1221047 Opened 9 years ago Updated 2 years ago

Version 41.0.2 on Win requires Access-Control-Allow-Origin for the same domain.

Categories

(Core :: DOM: Security, defect)

41 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: chogata, Unassigned)

Details

(Whiteboard: [domsecurity-backlog])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20151014143721

Steps to reproduce:

I have a webpage that performs an XMLHttpRequest "GET" request to the _same_ domain as the original webpage (both load via https). 


Actual results:

Firefox version 41.0.2 on Mac OS 10.9 performs the request, the same version on Windows 7 does not and the console displays error message about required CORS header. AFAIK this should not be required with _same_ domain, but even if it is, the behaviour is not cross-platfrom consistent.


Expected results:

Should work the same on both platforms.
CORS requires that the request is to the same host, see https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy If that is valid, can you tell us the the page on which this happens?

If you open menu Tools > Web developer > Console and enable all logging under 'Net' (including XHRs), do the requests violate CORS in a different manner?
Component: Untriaged → Security
Product: Firefox → Core
A link to the relevant page would be very helpful here.  If that's not possible, please let me know and I'll try to think of some other way to figure out what you're seeing, exactly.
Flags: needinfo?(chogata)
I cannot provide you with the link to the page, as this is internal page of my company. But I enabled all the logging and the info is as follows:

*******************
GET XHR https://finance.lan/global/autoclicomp.php [HTTP/1.1 200 OK 47ms]

Zablokowano żądanie do zasobu innego pochodzenia: zasady „Same Origin Policy” nie pozwalają wczytywać zdalnych zasobów z „https://finance.lan/global/autoclicomp.php?q=728”. (brakujący nagłówek CORS „Access-Control-Allow-Origin”) <nieznane>

NS_ERROR_FAILURE:  fnew_invoice.php:107:0
*******************

(the polish error message is equivalent of this:
"Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at ... (missing CORS header „Access-Control-Allow-Origin”) <unknown>"

But the funny thing is now it works on the Windows machine I tested it on earlier, but does NOT work on another one (and the message is copied from there). Still works on Mac machine. All 3 machines have 41.0.2 (I know there is 42 now, but there are no automatic upgrades in my company).
Flags: needinfo?(chogata)
Also, one more thing. The XMLHttpRequest was in the webpage code for a long time and worked without CORS header, it just stopped working suddenly for some users one day (I cannot be sure, when, because the users tend to use the system on certain days of the month only, so I cannot narrow it down to specific Firefox upgrade).
After I investigated and reported it here, I added the header, so the system was usable again. I disabled it today for a while to provide more info here. But the first Windows browser (not working without CORS, working with CORS, working without CORS again) WAS restarted (I did not restart the whole Windows system). The second Windows browser (not working without CORS, working with CORS, not working without CORS again) is on a Windows system that is shut down for nights, so it was restarded along with Windows.
I don't know if it makes any difference (if the CORS header information can be cached in any way?), but just to be clear about what happend.
CORS headers can be cached in some ways, yes.

Just to check, are you possibly using HSTS headers on any of this stuff?

If you can reproduce while creating an HTTP log per the instructions at https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging and either attach it here or send it to me directly, that might shed some light on what's going on...
:chogata, are you still experiencing CORS issues. If so, please answer comment 5 and we'll find someone to take a closer look at the problem.
Component: Security → DOM: Security
Whiteboard: [domsecurity-backlog]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.