Hot Module Reloading (HMR) Not Working

[bntzio]

Gatsby version: 0.12.46
Node version: 6.4.0
OS version: OSX El Capitan 10.11.6

Some hours ago I noticed that the hot module reloading (HMR) wasn't working, when I run npm run develop to start developing and make a change in my component, I get this error and warning in the chrome console:

Error:

XMLHttpRequest cannot load http://0.0.0.0:8000/032760b3db0a507954fb.hot-update.json. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8000' is therefore not allowed access. The response had HTTP status code 404.

Warning:

[HMR] Update check failed: Error: Manifest request to http://0.0.0.0:8000/032760b3db0a507954fb.hot-update.json timed out.
    at XMLHttpRequest.request.onreadystatechange (http://localhost:8000/bundle.js?t=1493255843490:34:23)

I did some research and it seems that this issue has to do with webpack-dev-server as mentioned here.

A webpack-dev-server/middleware security issue found some days ago, and I think the update breaks some configuration on various projects.

I found these disscussion in the webpack-dev-server github issues as well:

• Hot module / hrm not working anymore?
• --host 0.0.0.0 Not working
• Host checking breaks multi-host proxy

It's strange, yesterday I was working with HMR without any problems.

Is anyone facing the same issue?

[KyleAMathews]

Gahhh that explains it. There's been several people complaining about this and I couldn't figure out why. Thanks for the research!

So I think we just need to change https://github.com/gatsbyjs/gatsby/blob/master/lib/utils/develop.js#L167
to headers: { "Access-Control-Allow-Origin": "localhost:8000" }.

[bntzio]

Yeah I've read that it should work by specifying that in the devServer configuration.

That said, it won't work for some people based on my research, for me that isn't working either, I just tested it and same error.

I'm going to continue digging into this.

[bntzio]

Mm... I've tried using disableHostCheck: true as mentioned here but it didn't work, that should skip the security changes and be able to go back to normal, I just wanted to check if that way works, obviously it shouldn't be in production.

[bntzio]

For the moment, developing on 0.0.0.0:8000 instead of the localhost version fixes the issue.

[michaeljdeeb]

Hey! I haven't been up to date on the codebase in awhile, but a security vulnerability in a static site is such a rarity that I ended up catching up. Feel free to correct any of this if it's off.

From what I can see, gatsby actually uses hapi and hapi-webpack-plugin in lieu of webpack-dev-server so disableHostCheck: true isn't valid anywhere in develop.js

Looking at Usage 1), and gatsby's develop.js, I believe the headers object actually isn't doing anything right now. webpack-hot-middleware has minimal documentation, but doesn't mention headers and webpack-dev-middleware does and webpack-dev-server links to a webpack-dev-middleware release with a security fix related to Access-Control-Allow-Origin.

Placing the headers object as is under assets instead solved the errors for me and also exposed me to the attack being discussed. Changing * to localhost, localhost:8000, or http://localhost did not work, but http://localhost:8000 worked as expected. That said, everything still worked on 0.0.0.0:8000, which leads me to believe this solution is still vulnerable.

What I believe to be the secure solution to this is to run gatsby develop --host domain.local (or LAN IP) --port #### as the site then becomes unavailable over 0.0.0.0. Other options include exposing the header with a user config, and/or to just warn people of the risk when running gatsby develop without the host argument. A DNS rebinding attack will always be possible as long as the server is listening on anything routed to localhost (localhost, 0.0.0.0, 127.0.0.1).

You can check for vulnerability by running gatsby develop -p 3000 (the demo site expects port 3000), opening the browser web inspector, and going to dnsrebinder.net (leaving unlinked intentionally). Eventually you'll see a not_found come back with a 404 from your development server. The vulnerability is fixed if there is no status code associated with the request.

[fpaboim]

It seems that webpack dev server is not recognizing 0.0.0.0 as localhost for hot module replacement.

running:

gatsby develop --host localhost --port 8000

seems to work though. Strange that this only happened to me with the bootstrap boilerplate, the default project creation seems to be working fine?

[KyleAMathews]

The change only happened in the past few days (and on a dot release so we inherited the breaking change without notice) so if you started a site before then you won't see the problem.

…

On Thu, Apr 27, 2017, 8:12 AM fpaboim ***@***.***> wrote: It seems that webpack dev server is not recognizing 0.0.0.0 as localhost for hot module replacement. running: gatsby develop --host localhost --port 8000 seems to work though. Strange that this only happened to me with the bootstrap boilerplate, the default project creation seems to be working fine? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#864 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEVhwX0etsJ7D9JgMXjhMxfaNr_WsgSks5r0LBGgaJpZM4NJoBx> .

[michaeljdeeb]

Ah, right. webpack-dev-middleware passed 'Access-Control-Allow-Origin': '*' prior to 5 days ago.
webpack/webpack-dev-middleware@626a35a#diff-27e39f85634d9276821c67a9bbf764b4L64

If npm list webpack-dev-middleware shows a version earlier than v1.10.2 you don't have the breaking security change.

[KyleAMathews]

Decided it'd be simplest to just use localhost as the default host 7cd0afb

The reason the default host was set to 0.0.0.0 in the past was so that Gatsby would work by default when developing on a remote server but that's a small convenience that we can drop.

[Daniel15]

It seems that webpack dev server is not recognizing 0.0.0.0 as localhost for hot module replacement.

0.0.0.0 means "all IPs on the local machine". It doesn't actually represent a routable IP address - You're not supposed to hit 0.0.0.0 directly in your browser.

[KyleAMathews]

@Daniel15 yeah, it was so the dev server would just work on local and remote hosts without having to explicitly set the IP but with the webpack change we had to drop that.