create-react-app: Subdomains not working in 1.0.0
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?
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 4
- Comments: 22 (12 by maintainers)
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.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 settingallowedHosts
to".localhost"
, for example, but there isn’t a way to pass in this config via create-react-app.I have a proposed solution here: https://github.com/facebookincubator/create-react-app/pull/2288. What do you think?
Here is a quick and dirty workaround if you need to run your dev app on domains other than localhost :
Install concurrently and http-proxy
Add proxy-server.js
Replace the
start
script in yourpackage.json
by thisWe will need https://github.com/webpack/webpack-dev-server/pull/899 to make this happen. 😄
A separate PR just to add
.localhost
support (or making this the default behavior) might also be warranted.