Angular-cli: Invalid Host header after updating to 1.0.1

[SanderElias]

- [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]

same here, runs on debian

[AlanCrevon]

same here on OSX.

[kolkov]

Maybe it related to?
https://github.com/webpack/webpack-dev-server/issues/882

[amiram]

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]

@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]

@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]

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

[flackjap]

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 - https://github.com/webpack/webpack-dev-server/issues/882#issuecomment-297555924

[dinvlad]

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]

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]

@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]

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

[dinvlad]

/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]

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]

@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]

@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]

@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]

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]

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]

Or you can just give disableHostCheck : false, in webpackDevServer config
in serve.js file in tasks folder of cli. node_modules/@angular/cli

[niklas-dahl]

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

[vivekamin]

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

[dinvlad]

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

[tarlepp]

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]

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

[kktam]

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]

@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.

[RomaDotDev]

ng serve --host 0.0.0.0 -ssl -p 3000
stopped working after CLI update to 1.0.1

I use CentOS 6

[elliotwesoff]

I'm not quite sure what this is and I can't seem to find any documentation anywhere. Can anyone provide a link or perhaps an explanation to why this was implemented?

P.S. using the disableHostCheck: true option in my webpack.config.js solved the issue for me.

[SanderElias]

@elliotwesoff There are some links in this thread, but this blogpost explains it the best in my opinion.

This is activity caused by a webpack security fix, and not by the CLI, I reopened the issue because the missing cmd-line switches that are needed to work around this, are not exported by ng serve.

[filipesilva]

Hey all, thanks for all the information added about this issue. The blogpost @SanderElias posted in https://github.com/angular/angular-cli/issues/6070#issuecomment-298861063 covers it pretty well.

I think the CLI will have to add the --public flag as well to fix this case.

[filipesilva]

The best solution available right now for users affected by this problem is to downgrade to 1.0.0.

[filipesilva]

Actually, now that I'm re-reading all the comments again, @amiram and @flackjap suggest using the existing --host flag (e.g. ng serve --host app.myapp.com).

If a current flag is enough, there's no need to add a new one. If this doesn't work for some setups please let me know.

[wulfsberg]

If you're using the ---host parameter to Angular-CLI, you obviously want the test server to serve on that address (possibly 0.0.0.0). It seems redundant to have to give additional parameters for that, even if it internally means that Angular-CLI needs to push extra parameters to the webpack dev server.

[amiram]

If you mean that an existence of --host will configure webpack to ignore the host header, then it is fine. It's not convenient to edit the command each time and write the ip address. The command is in package.json so it is common for all the team but each has a different address for the web server.

[SanderElias]

@filipesilva I upgraded another project to give this an another spin. Here are the results:

1 --host 0.0.0.0 always ends in invalid host header
2 --host <public ip> works as long as the client connects using the same ip-number, using a hostname doesn't work
3 --host <name> works as long as the client connects using the same name. This might need changing the OS host files, or your local DNS server setup.

So, the problem is mostly the --host 0.0.0.0. When the --public switch is added, you can add a name, without changing anything in your system's settings. I think this is preferable over my 3rth option.

Without the --public, it needs the disableHostCheck which might be a security issue, so this should not be enabled without an explicit setting and/or a warning.

[rahianeja]

@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]

@rahianeja This issue has been solved and closed. https://github.com/angular/angular-cli/pull/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]

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]

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

[kimfrithiof]

@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]

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

[kimfrithiof]

@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).

[kimfrithiof]

@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]

@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]

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]

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.

[toanhd]

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[bot]]

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._}