Subdomains not working in 1.0.0

[anomaly44]

Description

Since 1.0.0 we cannot visit subdomains on the dev server anymore. This is usfeful for devs who use subdomains to serve different data based on subdomains with CRA.

Expected behavior

Visiting the app on http://test.localhost:3000/ should display the app the same as the usual: http://localhost:3000/

Actual behavior

Instead of the app we get: Invalid Host header

Reproducible Demo

create a new react app and visit any subdomain.

Extra

• Would it be possible to add an option to the package json to use
  disableHostCheck: true
  in the webpackDevServer.config ?
• is it possible to add an option to open the browser on a subdomain?

[gaearon]

I am concerned about adding disableHostCheck: true, this kinda goes back against the point of fixing that security issue. I wonder if WebpackDevServer supports (or could support) a wildcard for this.

cc @SpaceK33z, we’ll probably need someone from Webpack side to help us understand implications of this.

[anomaly44]

Thanks for the fast reply.
I have a limited understanding of the security issue. But I guess the problem is other websites accessing your dev server and stealing your assets? Since I find it weird that a dev server might pose some security risks, since it should not be used in production anyway, that is the only issue I can think of.

An option to add wildcards to the development environment would be a decent solution for most people using subdomains I guess. As long as everything can stay dynamic in production, since it would not be an option to add a new wildcard every time a user creates or changes a new subdomain entity.

[gaearon]

Since I find it weird that a dev server might pose some security risks, since it should not be used in production anyway, that is the only issue I can think of.

It's more of a security risk if you use the proxy feature since you could potentially proxy to a process like Werkzeug that lets you run arbitrary code in its debugger.

[anomaly44]

I see, thanks for clarifying.

[Timer]

We will need webpack/webpack-dev-server#899 to make this happen. 😄

A separate PR just to add .localhost support (or making this the default behavior) might also be warranted.

[gaearon]

Seems like this is blocked on WDS then. I don't want to relax the check completely.

[mbaumbach]

I'm sure there's a few ways to hit this, but one way we hit this was trying to expose our local server via ngrok. So it may be useful to find a way to resolve this for non .localhost domains too.

[ArnaudD]

Here is a quick and dirty workaround if you need to run your dev app on domains other than localhost :

1. Install concurrently and http-proxy

   yarn add concurrently http-proxy || npm install --save-dev concurrently http-proxy
   

2. Add proxy-server.js

   var http = require('http');
   var httpProxy = require('http-proxy');
   
   httpProxy.createServer({
     changeOrigin: true,
     hostRewrite: true,
     autoRewrite: true,
     ws: true,
     target: 'http://localhost:3000'
   }).listen(process.env.PORT || 8080);

3. Replace the start script in your package.json by this

   {
     // ...
     "scripts": {
       "start": "concurrently \"node proxy-server.js\" \"PORT=3000 react-scripts start\"",
       // ...

[gaearon]

Hmm. I wonder if the proxy feature would just work for this?

[mbaumbach]

Our setup is using the built-in proxy feature (in the package.json) for an external API server and ngrok to expose the site outside of localhost and we hit the invalid host header. I tried without proxy to make sure that wasn't the culprit.

I may have to try out @ArnaudD suggestion, though we aren't hurting to upgrade react-scripts, I'm just an early adopter by nature. :)

[gaearon]

I have a proposed solution here: #2288.
What do you think?

[gaearon]

Please update to react-scripts@1.0.2.
It fixes this issue for users who don't use the proxy feature.

If you do use the proxy feature, please follow these instructions.

[anomaly44]

For me this still doesnt fix it when i try to go to: http://test.localhost:3000/
Am I missing something?

[gaearon]

Have you updated to 1.0.2? Are you using the proxy feature? If you do, have you followed the new instructions in the migration guide for 1.0.2?

[anomaly44]

yes, updated to 1.0.2
yes I m using the proxy feature in my package json:
"proxy": "http://localhost:3333/v1",

What host do I need to specify in .env.development if I want to visit my app on http://test.localhost:3000/ (or http://name1.localhost:3000/, or http://name2.localhost:3000/) ?

guess i m missing something, because in a blank test project, visiting these 'subdomains' does indeed work.

[gaearon]

Let's reopen the issue for subdomain use case specifically, as we should indeed support any subdomains of localhost by default. I believe we're waiting for a WDS pull request to land for this.

But in the meantime you can add DANGEROUSLY_DISABLE_HOST_CHECK=true to your env file if this is blocking you.

[Timer]

I believe we're waiting for a WDS pull request to land for this.

webpack/webpack-dev-server#899 (which also allows subdomains)

[SpaceK33z]

The PR mentioned above was merged and released in 2.7.0, and react-scripts already uses that version. So it should work now?

[gaearon]

I'd expect so. Let's close this. If it doesn't work happy to reopen.

[naw]

Even though the allowedHosts feature landed in WDS, there is no way to use that feature from an unejected create-react-app, as far as I know.

This means if you want to use the proxy feature (to forward requests to a backend API, for example), WDS will check the host, and subdomains (e.g. subdomain.localhost) will not be allowed. This could be allowed with a WDS config by setting allowedHosts to ".localhost", for example, but there isn't a way to pass in this config via create-react-app.

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[stale]

This issue has been automatically closed because it has not had any recent activity. If you have a question or comment, please open a new issue.