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

Invalid Host header after updating to 1.0.1 #6070

Closed
SanderElias opened this issue Apr 25, 2017 · 49 comments · Fixed by #6173
Closed

Invalid Host header after updating to 1.0.1 #6070

SanderElias opened this issue Apr 25, 2017 · 49 comments · Fixed by #6173
Assignees
Labels
effort1: easy (hours) freq2: medium needs: more info Reporter must clarify the issue P1 Impacts a large percentage of users; if a workaround exists it is partial or overly painful severity3: broken

Comments

@SanderElias
Copy link

SanderElias commented Apr 25, 2017

- [x ] bug report -> please search issues before submitting
- [ ] feature request

Versions.

1.0.1

Repro steps.

update to 1.0.1
ng serve
browser will read: Invalid Host header, and do nothing

The log given by the failure.

none

Desired functionality.

serve my application.

Mention any other details that might be useful.

Downgrading to 1.0.0 fixed the issue. (BTW, running on ubuntu and debian, same issue)

@MichalBu
Copy link

same here, runs on debian

@AlanCrevon
Copy link

same here on OSX.

@kolkov
Copy link

kolkov commented Apr 25, 2017

Maybe it related to?
webpack/webpack-dev-server#882

@amiram
Copy link

amiram commented Apr 25, 2017

It's indeed due to a security fix added lately to webpack-dev-server. You must start with
ng serve --host your.ip.addr.ess

@SanderElias
Copy link
Author

@amiram I had to add some trickery to my hosts file, and serve from a name, but it is indeed the curlpit.
Closing as it's not a CLI issue!

@amiram
Copy link

amiram commented Apr 25, 2017

@SanderElias there is a new option in webpack disableHostCheck that will also solve it. Can I set it if I'm using angular cli?

@SanderElias
Copy link
Author

@amiram Nope, it's not exported to cmd-line yet afaik. Seems even impossible from webpack cmd-line itself for now.

@flackjap
Copy link

In the details of this Webpack security update, there's an important note:

The Host header of the request have to match the listening adress or the host provided in the public option.

It means what it means. If you were using just a webpack-dev-server and localhost hostname or 127.0.0.1 to develop/test an app in your browser, you should be fine.

But if you were using it behind a hostname (e.g. myapp.com) while the NG CLI or Webpack dev server served your app from the default address, and you proxied requests to it from, let's say, Nginx, then the whole HTTP header forwarding path must be matched. I left an example in the previously linked issue - webpack/webpack-dev-server#882 (comment)

@dinvlad
Copy link

dinvlad commented Apr 27, 2017

Seems like specifying --public <hostname> option for webpack-dev-server works for people behind proxies. Would it be possible to add it to ng serve?

@vivekamin
Copy link

I have multitenant system .SO in 1.0.0 version when I was adding subdomain It was working. But now It is giving me Invalid host header.
localhost(success)
asd.localhost(Invalid host header)
How to allow any subdomain?

@SanderElias
Copy link
Author

SanderElias commented Apr 28, 2017

@vivekamin edit your hosts file is the easiest. The dev server is not meant to be used in production. This a secutiry measure taken by the webpack team. There is little no nothing the CLI team can do, execpt from exposing the switched spoken about above!

@vivekamin
Copy link

vivekamin commented Apr 28, 2017

@SanderElias which hosts file? Can you please elaborate. Is it nginx hosts files? How to do It in development environment ?

@dinvlad
Copy link

dinvlad commented Apr 28, 2017

/etc/hosts if you're on Linux. That's inconvenient though, if the host is always migrating, like in some cloud environments.. Besides, there could be DNS complications depending on the network setup.

Adding --public seems like a better option - no hosts need to be edited, and security is uncompromised.

@AaronLangley
Copy link

AaronLangley commented Apr 28, 2017

This is a problem for me too. I use two separate IDEs and applications, one for Angular and one for the web services. The Angular app will deploy to S3 and the services to Elastic Beanstalk, and I simulate this locally with myapp.lvh.me:4200 and myservices.lvh.me:4300 was working great until I upgraded to Angular 4 and latest angular-cli

@vivekamin
Copy link

@AaronLangley Degrade to Angular-CLI 1.0.0 which has Angular V4, will solve problem. I am still figuring out the way for development purspose.

@vivekamin
Copy link

@dinvlad I am developing multitenant Sys .So subdomain may change whatever. How can I put a regex for same in hosts files. I am confused.

@AaronLangley
Copy link

@vivekamin - maybe a child object/section in .angular-cli.json that maps to webpack.config.js ?

Was just looking at this SO post for reactjs
http://stackoverflow.com/questions/43619644/i-am-getting-an-invalid-host-header-message-when-running-my-react-app-in-a-we

@SanderElias SanderElias reopened this Apr 28, 2017
@SanderElias
Copy link
Author

I'm reopening this issue, because it's seems a major inconvienece to developers that the needed switches are not available in the CLI.
To mitegate this issue, the ng server command needs to be able to port the --pubic <hostname> flag, and perhaps even the --disableHostCheck (although that last one really needs a severe warning, perhaps even a confirmation every time!)

@flackjap
Copy link

Until this gets resolved you can just change the following line in node_modules/webpack-dev-server/lib/Server.js (line 402):

if(this.disableHostCheck) return true;

change to

return true;

@vivekamin
Copy link

vivekamin commented Apr 28, 2017 via email

@niklas-dahl
Copy link
Contributor

Even using ng serve --host 0.0.0.0 dosnt work anymore :(

@vivekamin
Copy link

It's working with - - host 0.0.0.0. What's your use case?

@dinvlad
Copy link

dinvlad commented Apr 28, 2017

That doesn't work. At least behind a proxy.

@tarlepp
Copy link

tarlepp commented Apr 28, 2017

Having same problem within my dev env. I run my IDE on linux VM, and then access to that from my windows machine. With 1.0.0 angular-cli this could be solved just by using host 0.0.0.0, but now this won't work :(

It would be nice if there was a simple option for ng serve to make this work just like previously.

@tarlepp
Copy link

tarlepp commented Apr 30, 2017

imho changing code under node_modules is the worst solution for this...

@kktam
Copy link

kktam commented Apr 30, 2017

I checked the version of webpack I used and already have the fix at line 402. However angular app still does not work in current verison of cloud9 ide.

Below is my package.json

{
  "name": "mean-app",
  "version": "0.0.0",
  "license": "MIT",
  "scripts": {
    "ng": "ng",
    "start": "ng serve",
    "build": "ng build",
    "test": "ng test",
    "lint": "ng lint",
    "e2e": "ng e2e"
  },
  "private": true,
  "dependencies": {
    "@angular/common": "^4.0.0",
    "@angular/compiler": "^4.0.0",
    "@angular/core": "^4.0.0",
    "@angular/forms": "^4.0.0",
    "@angular/http": "^4.0.0",
    "@angular/platform-browser": "^4.0.0",
    "@angular/platform-browser-dynamic": "^4.0.0",
    "@angular/router": "^4.0.0",
    "core-js": "^2.4.1",
    "rxjs": "^5.1.0",
    "zone.js": "^0.8.4"
  },
  "devDependencies": {
    "@angular/cli": "1.0.1",
    "@angular/compiler-cli": "^4.0.0",
    "@types/jasmine": "2.5.38",
    "@types/node": "~6.0.60",
    "codelyzer": "~2.0.0",
    "jasmine-core": "~2.5.2",
    "jasmine-spec-reporter": "~3.2.0",
    "karma": "~1.4.1",
    "karma-chrome-launcher": "~2.0.0",
    "karma-cli": "~1.0.1",
    "karma-jasmine": "~1.1.0",
    "karma-jasmine-html-reporter": "^0.2.2",
    "karma-coverage-istanbul-reporter": "^0.2.0",
    "protractor": "~5.1.0",
    "ts-node": "~2.0.0",
    "tslint": "~4.5.0",
    "typescript": "~2.2.0"
  }
}

@dinvlad
Copy link

dinvlad commented May 1, 2017

@kktam, my current workaround is to add 0.0.0.0 <workspace>-<username>.c9users.io to /etc/hosts file, and to run ng serve -H <workspace>-<username>.c9users.io to serve the app.

filipesilva added a commit to filipesilva/angular-cli that referenced this issue May 3, 2017
Two new flags are added to `ng serve`:
- `--public-host` (aliased by `--live-reload-client): Specify the URL that the browser client will use.
- `--disable-host-check`: Don't verify connected clients are part of allowed hosts.

Setting `--disable-host-check` will output a warning:
```
WARNING Running a server with --disable-host-check is a security risk. See https://medium.com/webpack/webpack-dev-server-middleware-security-issues-1489d950874a for more information.
```

See angular#6070 for more context about this change.

Fix angular#6070
filipesilva added a commit to filipesilva/angular-cli that referenced this issue May 3, 2017
Two new flags are added to `ng serve`:
- `--public-host` (aliased by `--live-reload-client): Specify the URL that the browser client will use.
- `--disable-host-check`: Don't verify connected clients are part of allowed hosts.

Setting `--disable-host-check` will output a warning:
```
WARNING Running a server with --disable-host-check is a security risk. See https://medium.com/webpack/webpack-dev-server-middleware-security-issues-1489d950874a for more information.
```

See angular#6070 for more context about this change.

Fix angular#6070
filipesilva added a commit to filipesilva/angular-cli that referenced this issue May 4, 2017
Two new flags are added to `ng serve`:
- `--public-host` (aliased by `--live-reload-client): Specify the URL that the browser client will use.
- `--disable-host-check`: Don't verify connected clients are part of allowed hosts.

Setting `--disable-host-check` will output a warning:
```
WARNING Running a server with --disable-host-check is a security risk. See https://medium.com/webpack/webpack-dev-server-middleware-security-issues-1489d950874a for more information.
```

See angular#6070 for more context about this change.

Fix angular#6070
filipesilva added a commit to filipesilva/angular-cli that referenced this issue May 8, 2017
Two new flags are added to `ng serve`:
- `--public-host` (aliased by `--live-reload-client): Specify the URL that the browser client will use.
- `--disable-host-check`: Don't verify connected clients are part of allowed hosts.

Setting `--disable-host-check` will output a warning:
```
WARNING Running a server with --disable-host-check is a security risk. See https://medium.com/webpack/webpack-dev-server-middleware-security-issues-1489d950874a for more information.
```

See angular#6070 for more context about this change.

Fix angular#6070
filipesilva added a commit to filipesilva/angular-cli that referenced this issue May 9, 2017
Two new flags are added to `ng serve`:
- `--public-host` (aliased by `--live-reload-client): Specify the URL that the browser client will use.
- `--disable-host-check`: Don't verify connected clients are part of allowed hosts.

Setting `--disable-host-check` will output a warning:
```
WARNING Running a server with --disable-host-check is a security risk. See https://medium.com/webpack/webpack-dev-server-middleware-security-issues-1489d950874a for more information.
```

See angular#6070 for more context about this change.

Fix angular#6070
filipesilva added a commit to filipesilva/angular-cli that referenced this issue May 9, 2017
Two new flags are added to `ng serve`:
- `--public-host` (aliased by `--live-reload-client): Specify the URL that the browser client will use.
- `--disable-host-check`: Don't verify connected clients are part of allowed hosts.

Setting `--disable-host-check` will output a warning:
```
WARNING Running a server with --disable-host-check is a security risk. See https://medium.com/webpack/webpack-dev-server-middleware-security-issues-1489d950874a for more information.
```

See angular#6070 for more context about this change.

Fix angular#6070
filipesilva added a commit that referenced this issue May 9, 2017
Two new flags are added to `ng serve`:
- `--public-host` (aliased by `--live-reload-client): Specify the URL that the browser client will use.
- `--disable-host-check`: Don't verify connected clients are part of allowed hosts.

Setting `--disable-host-check` will output a warning:
```
WARNING Running a server with --disable-host-check is a security risk. See https://medium.com/webpack/webpack-dev-server-middleware-security-issues-1489d950874a for more information.
```

See #6070 for more context about this change.

Fix #6070
dimitrovs added a commit to dimitrovs/angular-cli that referenced this issue May 28, 2017
The 0.0.0.0 host format will never work with current webpack version and will always show "invalid host header". Instead, a valid domain or public IP has to be specified. See angular#6070 .
@rahianeja
Copy link

@flackjap Adding return true to checkHost does work for me, bu return an error : Could not connect to REST server. Please check your configuration details

@flackjap
Copy link

@rahianeja This issue has been solved and closed. #6173
Why don't you just use --disable-host-check ?

If you still have to use the older version, then change the disableHostCheck to false, in webpackDevServer config file.

@jrohatiner
Copy link

solution for me in cloud9:
open node_modules/webpack-dev-server/lib server.js
edit line 451 change false to true
edit line 473 change false to true
this allows "public host name" of listening address and the allowedHost === hostname
must accept that public hostname and allowedHost are exactly ===

@dinvlad
Copy link

dinvlad commented Aug 25, 2017

@jrohatiner no need for that, I use mine in Cloud9 too without any modifications to the source code. Just use --public-host parameter.

@kimfrithiof
Copy link

@rahianeja @flackjap Did you manage to solve your problem? I'm having the same thing. I can access my app with the --disable-host-check from the internet but I get the "Error: Could not connect to REST server. Please check your configuration details". It works locally with no issues.

@flackjap
Copy link

flackjap commented Oct 6, 2017

Where do you get that error from? Angular CLI? Browser? Something else?

@kimfrithiof
Copy link

@flackjap Sorry for being unspecific. I'm following the tutorial to setup a hyperledger app over here. Part of that is generating a REST server and an Angular Skeleton application with Yeoman ontop. I have addedd the --disable-host-check which solves the problem of "Invalid host header" but I'm now running in to an error in the browser when I try to interact with the REST API from the app. The rest API works by itself and the interaction works when I use it on the local machine (localhost:4200).

servererror

@kimfrithiof
Copy link

@flackjap @rahianeja I solved it. Was an easy fix. I needed to edit the file: my-app/src/app/configuration.ts. The line
public ApiIP: string = "localhost";
Change that to your external IP.

@kiwi-koder
Copy link

@kimfrithiof I am having the same issue as you however changing the line
public ApiIP: string = "localhost";
to my external IP still did not work. The error reappeared when I went to post the asset

@flackjap
Copy link

I don't know what you guys are trying to do, but it seems that it has nothing to do with Angular CLI.
You have some API routing problems as I can see, and you are probably just trying to hit the same URL where you got your Angular app served, which, obviously can't handle your API requests as it's not supposed to.

@99sono
Copy link

99sono commented Dec 3, 2017

This situation has happened to me while trying to have a docker apache httpd work as a reverse proxy to my localhost nodejs .

The message popped up in my browser saying that the hostname was invalid, but not clarifying what hostname was being used.
After modefying the Server.js to do a console.log of the invalid name it was clear that the invalid name was:
webpack: Compiled successfully.
hostname being rejeted is: docker.for.mac.localhost

A hurdle for development.
Normally, this situation would not apply on a productive environment, since every code may be running on a container with a proper hostname.
But when in your local development machine you might want to run some code from your main HOST OS - you may end up with docker machines being allowed to connect to your main operating system. In Mac you get that very convenient hostname for this effect.

I am going to modify the
if(hostname === "127.0.0.1" || hostname === "localhost") return true;

To contain the docker Mac localhost.

dond2clouds pushed a commit to d2clouds/speedray-cli that referenced this issue Apr 23, 2018
Two new flags are added to `ng serve`:
- `--public-host` (aliased by `--live-reload-client): Specify the URL that the browser client will use.
- `--disable-host-check`: Don't verify connected clients are part of allowed hosts.

Setting `--disable-host-check` will output a warning:
```
WARNING Running a server with --disable-host-check is a security risk. See https://medium.com/webpack/webpack-dev-server-middleware-security-issues-1489d950874a for more information.
```

See angular#6070 for more context about this change.

Fix angular#6070
@toanhd
Copy link

toanhd commented Nov 18, 2018

Until this gets resolved you can just change the following line in node_modules/webpack-dev-server/lib/Server.js (line 402):

if(this.disableHostCheck) return true;

change to

return true;

this saved me after many hours of surfing for the solution

@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 9, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
effort1: easy (hours) freq2: medium needs: more info Reporter must clarify the issue P1 Impacts a large percentage of users; if a workaround exists it is partial or overly painful severity3: broken
Projects
None yet
Development

Successfully merging a pull request may close this issue.