1376310 - Allow localhost CORS preflight requests without blocking it as mixed content

Biru, are you planning on completing this? We got a request on a duplicate bug 1440370. Want to let the reporter know if its on our roadmap in the near future. Thanks!

Flags: needinfo?(birunthan)

ctclements

Comment 5

•

7 years ago

Any update on this? Microsoft Edge had a similar issue and has just fixed it with their latest build available on Windows Insider. It would be great to have this work consistently between Edge, Chrome, and Firefox.

Simone Granata

Comment 6

•

7 years ago

Any update on this? This is very bad, because only Firefox blocks this kind of connection. If you try to do an ajax request from https://webapp/index to http://localhost:49100 you receive a mixed content error and if you do an ajax request to http://127.0.0.1:49100 you receive a CORS error, equal if I activate the CORS filter on my native app on 127.0.0.1:49100. Can you please fix this asap?

Simone Granata

Comment 7

•

7 years ago

It seems, that Firefox doesn't send any preflight request to the target server, when trying to make an ajax or fetch request from a https://website to http://127.0.0.1:<any free port>/api/<service>. @Developers: Is this a bug or is this really intended? Because Chrome and IE Edge allows that. I think is a bug. Can you please give a feedback to this?

Christoph Kerschbaumer [:ckerschb}

Updated

•

7 years ago

Comment 8

•

7 years ago

Same problem here. I want to access http://127.0.0.1 from a https://webapp and get the CORS error "CORS request did not succeed", so it seems that the preflight request is not sent at all. Edge and Chrome however work fine. So please fix this as soon as possible.

Benjamin Klaus

Comment 9

•

7 years ago

I am using FF 63.0.1 (64-Bit)

chris.veigl

Comment 10

•

7 years ago

Confirmed - same problem here. Please resolve the issue so that CORS preflight requests can also be used in FireFox ...

arcytech77

Comment 11

•

7 years ago

Still seeing this issue. I am going to have to drop support for our Firefox users until this is fixed.

ctclements

Comment 12

•

7 years ago

We have a lot of users finally leaving IE. Without having this fixed, we will likely have to recommend that our customers put all users on Chrome or whatever Microsoft comes up with now that Edge is done.

Benjamin Klaus

Comment 13

•

7 years ago

just discovered that opening an EventSource from a secure context to: 1) http://localhost:8080 -> fails 2) http://127.0.0.1:8080 -> fails 3) http://[::1]:8080 -> works! So using the IPv6 localhost "[::1]" could be a workaround for this issue.

Daniel

Comment 14

•

6 years ago

I have the same problem. I have to use chrome which I don't really want to use for developing, so problem has to be solved.

Adrian Florinescu [:aflorinescu]

Updated

•

6 years ago

Comment 16

•

6 years ago

We are heavily using communication between https client and a service on http://127.0.0.1.
Only in Firefox, we can send GET and POST requests, but PUT requests get blocked.
Cors headers are correctly set on the server, allowing the PUT method. PUT requests work in Chrome.

Benjamin Klaus

Comment 17

•

6 years ago

Is there anyone from Mozilla-Team seeing this bug? This is now open for more than 2 years and not a single reaction.

@s.mellal, @daniel:
did you try to change use IPv6 http://[::1] instead of http://127.0.0.1 ?

marwankhalili

Comment 18

•

6 years ago

@Benjamin Klaus
I'm having the same issue. Tried using IPv6 instead of IPv4 but it did not help (Firefox version 66.0.3).
My advice is to avoid triggering CORS preflight by using "simple requests" if possible until this issue has been resolved: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simple_requests

Benjamin Klaus

Comment 19

•

6 years ago

yeah, using "simple requests" is possible, if you are also developing the endpoint on localhost you're communicating with. However thats not always the case and it's also not amusing if I have to change the request methods of the REST API of an other application just to get it work with Firefox...

Benjamin Klaus

Comment 20

•

6 years ago

We tried exactly what I wrote in the last comment in our application: We changed all PUT requests to POST and all Content-Type headers to "text/plain" in order to be categorized as "simple request" by Firefox where no CORS preflight request is sent. Result: basically it worked, but we also need to use EventSource() for server sent events -> this again resulted in the well-known CORS error. Unfortunately there is no possibility to change the characteristics of the browser-generated requests by constructing an EventSource and therefore this again breaks our app in Firefox...

Conclusion: Please, Firefox-Team fix this issue or at least comment on it, otherwise we have to drop Firefox-Support!

Alija Sabic

Comment 21

•

6 years ago

I can confirm the problems mentioned by @Benjamin Klaus. It would be awesome to have at least some kind of reaction of Team Firefox. Even if it is possible to work around this issue, by using the mentioned "simple requests", adapting the requests of the EventSource API for this scenario isn't possible after all.

Honestly, we don't want to drop the support for Firefox, because we really appreciate the work of you guys. However, we cannot make any clear decision until we have a reaction from you - other than to drop the support.

So.. Pretty Please with Sugar on Top. :) Please provide some thoughts and comments on this issue.

Christoph Kerschbaumer [:ckerschb}

Comment 22

•

6 years ago

(In reply to Alija Sabic from comment #21)

So.. Pretty Please with Sugar on Top. :) Please provide some thoughts and comments on this issue.

I am clearing the flags so this bug shows up in our weekly triage (which happens every Tuesday) in which we will re-evaluate the importance of this bug.

Priority: P3 → --

Whiteboard: [domsecurity-backlog1]

Benjamin Klaus

Comment 23

•

6 years ago

Thanks, great to hear that!

Just a comment for the re-evaluation:
As stated in the last note of https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content there is that decision that mixed content is allowed for 127.0.0.1. The current implementation of Firefox is inconsistent since normal requests to http://127.0.0.1 are allowed from a secure context, but preflight requests are not allowed. Therefore to my mind either both normal and preflight requests should be allowed (which I hope) or both denied.

Benjamin Klaus

Comment 24

•

6 years ago

Just noticed the same issue with an secure-only context (https). Our webapp from host https://grid.asterics.eu issues requests to https://couchdb.asterics-foundation.org - so its communication to another https page from an secure context. However I get the same issue:

Reason: CORS request did not succeed <<

Steps to reproduce:

Go to https://grid.asterics.eu/latest/app/#register
type any username in the first field
open console -> there is the CORS error because of an request made by the app to check if the username is valid

tested with latest Firefox (66.0.3, 64-Bit) on Win10 and Win7.

Christoph Kerschbaumer [:ckerschb}

Comment 25

•

6 years ago

The changes within Bug 1402530 will stop blocking 'localhost' as mixed content. Adding dependency to Bug 1402530 which should fix the problem here.

Depends on: 1402530

Priority: -- → P3

Whiteboard: [domsecurity-backlog1]

Christoph Kerschbaumer [:ckerschb}

Comment 26

•

6 years ago

Basti, after we have fixed Bug 1402530, could you verify that this bug has resolved as well? If so, we can mark this one as fixed as well. Thanks!

Flags: needinfo?(birunthan) → needinfo?(streich.mobile)

Jonathan Kingston [:jkt] he/him

Comment 27

•

6 years ago

So I didn't verify how Chrome behaves but it seems the source at least suggests it works the way I have been preventing you implementing basti, sorry about that.

So like https://chromium.googlesource.com/chromium/+/refs/heads/trunk/net/base/net_util.cc#2404 suggests localhost and various other odd names are localhost.
The code here uses that: https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/services/network/public/cpp/is_potentially_trustworthy.cc#184
Their mixed content blocker then uses this code here: https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/third_party/blink/renderer/core/loader/mixed_content_checker.cc#236

So it seems it is safe to start allowing this everywhere in Bug 1402530.

marwankhalili

Comment 28

•

6 years ago

(In reply to Benjamin Klaus from comment #24)
I do not believe this issue is related to CORS. Firefox does not trust the certificate provided by https://couchdb.asterics-foundation.org:3001/ (you should get an error if you open the URL in FF).

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #26)
Thanks for re-evaluating this bug! Hoping that Bug 1402530 will resolve this as well

Sebastian Streich [:sstreich]

Assignee

Comment 29

•

6 years ago

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #26)

Basti, after we have fixed Bug 1402530, could you verify that this bug has resolved as well? If so, we can mark this one as fixed as well. Thanks!

Hey! I just checked that case and can confirm that this will is fixed with the Patch for Bug 1402530

Flags: needinfo?(streich.mobile)

Benjamin Klaus

Comment 30

•

6 years ago

Great to hear that! We really appreciate it that someone takes care of resolving this issue, thank you very much!

Boris Zbarsky [:bzbarsky]

Comment 31

•

6 years ago

So is this fixed now? At least for the IP address case?

Alija Sabic

Comment 32

•

6 years ago

I think it should be fixed now, but I guess it will be only available with newer versions of FireFox. Let's hear what the developers will say...

Boris Zbarsky [:bzbarsky]

Comment 33

•

6 years ago

Bug 1402530 was fixed for Firefox 68, which is the current Firefox release version as of a few days ago. So either this is fixed in Firefox release, or bug 1402530 did not fix it.

Alija Sabic

Comment 34

•

6 years ago

Okay. I just checked the version of firefox I'm using. I'm still on 67. But I'll try to upgrade it tomorrow, run some test, and then post the results. Anyway, where can I look up the version of firefox for which bugs are fixed?

Boris Zbarsky [:bzbarsky]

Comment 35

•

6 years ago

Anyway, where can I look up the version of firefox for which bugs are fixed?

It can be a little complicated. Bug 1402530 is a simple case: if you load it and look in the "Tracking" section it says: "Target: mozilla68". That means the fix was checked in while 68 was in development, and generally means that 68 should have the fix.

There can be complications when fixes are backported to beta or release branches or when fixes are backed out on beta or release branches. Generally that information will be in the "Firefox Tracking flags" section, where bug 1402530 has "fixed" for "firefox68". An example of how this can work is bug 1409773 which has "Target: mozilla70" and "fixed" for both "firefox70" and "firefox69" in the tracking flags, because it was fixed for 70 and then backported to beta 69.

Maybe we always set the tracking flags now; if so, things are simpler than last I looked and you can just ignore the "Target" bit altogether. ;)

Benjamin Klaus

Comment 36

•

6 years ago

just tested this with Firefox 68.0.1 (64-Bit), but unfortunately it still looks the same:

from a secure context I tried HTTP PUT requests to the following addresses:

all still failing with the error: "CORS request did not succeed".

pmsvarela

Comment 37

•

5 years ago

I'm having the same problem with Firefox 72.0.2 (64-bit) and Firefox Nightly 74.0a1 (2020-01-22) (64-bit)

https website with a POST request to http://localhost:5000 or http://127.0.0.1:5000
if the authentication header is set, i get a "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://127.0.0.1:5000/status. (Reason: CORS request did not succeed)" error
if there's no authentication header, everything is ok

The same code runs on the latest versions of Chrome, Opera and Edge (chromium)

Sebastian Streich [:sstreich]

Assignee

Comment 38

•

5 years ago

Attached file Bug 1376310 - Ensure a nsIDocShell after checking IsOriginPotentiallyTrustworthy r=ckerschb — Details

Phabricator Automation

Updated

•

5 years ago

Assignee: nobody → sstreich

Status: NEW → ASSIGNED

Pulsebot

Comment 39

•

5 years ago

Pushed by apavel@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b0c31dc335db Ensure a nsIDocShell after checking IsOriginPotentiallyTrustworthy r=ckerschb

Natalia Csoregi [:nataliaCs]

Comment 40

•

5 years ago

bugherder

https://hg.mozilla.org/mozilla-central/rev/b0c31dc335db

Status: ASSIGNED → RESOLVED

Closed: 5 years ago

status-firefox75: --- → fixed

Resolution: --- → FIXED

Target Milestone: --- → mozilla75