Issue metadata
Sign in to add a comment
|
Changing localhost in /etc/hosts allows unsecure service workers
Reported by
claff...@naz.edu,
Oct 16 2016
|
||||||||||||||||||||||
Issue descriptionI was going through the tutorial at https://codelabs.developers.google.com/codelabs/your-first-pwapp/ and was stopped with this error: Uncaught (in promise) DOMException: Only secure origins are allowed (see: https://goo.gl/Y0ZkNV). I went into /etc/hosts and added the following line: 192.168.56.10 localhost This allowed me to get around the error and access an external server through http://localhost/ I'm not sure if this is actually a bug or if it's intended. Chrome Version : 53.0.2785.143 OS Version: OS X 10.12.0 URLs (if applicable) : Other browsers tested: Add OK or FAIL after other browsers where you have tested this issue: Safari 5: Firefox 4.x: IE 7/8/9: What steps will reproduce the problem? 1. 2. 3. What is the expected result? What happens instead of that? Please provide any additional information below. Attach a screenshot if possible. UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
,
Nov 4 2016
,
Nov 7 2016
As per 7.1 in the spec, "A user agent may allow localhost, 127.0.0.0/8, and ::1/128 for development purpose." https://w3c.github.io/ServiceWorker/#secure-context localhost should be recognized as the secure origin.
,
Nov 7 2016
There's actually ongoing spec discussion here: https://github.com/w3c/webappsec-secure-contexts/issues/43
,
Nov 7 2016
That spec discussion captures my ticket pretty well. Feel free to close this, I just wanted to bring it up as a an oddity.
,
Apr 19 2017
,
Apr 19 2017
Ah, should I looked up the spec discussion first. "https://w3c.github.io/webappsec-secure-contexts/#localhost says that localhost MAY be considered totally awesome iff folks promise to resolve it to a loopback address as per the IETF draft noted above." So according to language, this is a bug since localhost is not being resolved to a loopback address. However the service worker spec contains somewhat redundant and contradictory language: "A user agent may allow localhost, 127.0.0.0/8, and ::1/128 for development purpose. (Note that they may still be secure contexts.) " I suspect the answer is to remove that text from the service worker spec and just rely on the webappsec-secure-contexts spec. Will raise a ticket on SW spec.
,
Apr 19 2017
,
Sep 1 2017
The NextAction date has arrived: 2017-09-01
,
Oct 6 2017
Spec issue was resolved and now SW spec points to Secure Contexts spec. So the remaining work is to respect Secure Contexts spec: "...user agents MAY treat localhost names as having potentially trustworthy origins if and only if they also adhere to the localhost name resolution rules spelled out in [let-localhost-be-localhost] (which boil down to ensuring that localhost never resolves to a non-loopback address)." I suspect this is something Chromium as a whole needs to implement and isn't a Service Worker-only bug.
,
Oct 6 2017
After a lot more discussion around https://tools.ietf.org/html/draft-west-let-localhost-be-localhost than I expected, we locked `localhost` to loopback addresses in https://chromium-review.googlesource.com/c/chromium/src/+/598068.
,
Mar 1 2018
The NextAction date has arrived: 2018-03-01 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by sureshkumari@chromium.org
, Oct 17 2016Labels: Needs-Feedback