Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subdomains not working in 1.0.0 #2233

Closed
anomaly44 opened this issue May 19, 2017 · 22 comments
Closed

Subdomains not working in 1.0.0 #2233

anomaly44 opened this issue May 19, 2017 · 22 comments

Comments

@anomaly44
Copy link

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
Copy link
Contributor

gaearon commented May 19, 2017

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
Copy link
Author

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
Copy link
Contributor

gaearon commented May 19, 2017

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
Copy link
Author

I see, thanks for clarifying.

@Timer
Copy link
Contributor

Timer commented May 19, 2017

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
Copy link
Contributor

gaearon commented May 19, 2017

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

@mbaumbach
Copy link

mbaumbach commented May 19, 2017

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.

@gaearon gaearon added this to the 1.x milestone May 19, 2017
@ArnaudD
Copy link

ArnaudD commented May 19, 2017

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
Copy link
Contributor

gaearon commented May 19, 2017

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

@mbaumbach
Copy link

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
Copy link
Contributor

gaearon commented May 20, 2017

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

@gaearon
Copy link
Contributor

gaearon commented May 20, 2017

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.

@gaearon gaearon closed this as completed May 20, 2017
@Timer Timer modified the milestones: 1.0.2, 1.x May 21, 2017
@anomaly44
Copy link
Author

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

@gaearon
Copy link
Contributor

gaearon commented May 21, 2017

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
Copy link
Author

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
Copy link
Contributor

gaearon commented May 21, 2017

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.

@gaearon gaearon reopened this May 21, 2017
@gaearon gaearon modified the milestones: 1.0.x, 1.0.2 May 21, 2017
@Timer
Copy link
Contributor

Timer commented May 21, 2017

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

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

@SpaceK33z
Copy link
Contributor

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
Copy link
Contributor

gaearon commented Sep 9, 2017

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

@gaearon gaearon closed this as completed Sep 9, 2017
@naw
Copy link

naw commented Jan 12, 2018

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.

@Timer Timer reopened this Jan 12, 2018
@Timer Timer modified the milestones: 1.0.x, 2.0.0 Jan 12, 2018
@Timer Timer modified the milestones: 2.0.x, 2.x Sep 26, 2018
@Timer Timer removed this from the 2.x milestone Nov 2, 2018
@stale
Copy link

stale bot commented Dec 2, 2018

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 stale bot added the stale label Dec 2, 2018
@stale
Copy link

stale bot commented Dec 8, 2018

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.

@stale stale bot closed this as completed Dec 8, 2018
@lock lock bot locked and limited conversation to collaborators Jan 9, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants