Repository navigation
Allowing different HOST headers to be used in ng serve #6349
Description
Bug Report or Feature Request (mark with an x)
- [ ] bug report -> please search issues before submitting
- [ x ] feature request
Allow ng serve to accept requests with host headers that are different to the --host setting. This is needed when accessing the server via a reverse proxy.
Versions.
@angular/cli: 1.0.3
node: 6.10.1
os: linux x64
@angular/common: 4.1.2
@angular/compiler: 4.1.2
@angular/core: 4.1.2
@angular/forms: 4.1.2
@angular/http: 4.1.2
@angular/platform-browser: 4.1.2
@angular/platform-browser-dynamic: 4.1.2
@angular/router: 4.1.2
@angular/cli: 1.0.3
@angular/compiler-cli: 4.1.2
Linux Ubuntu 16.04.2 LTS
Repro steps.
ng new my-dream-app
cd my-dream-app/
ng serve
Configure reverse proxy (Apache/Nginx/HAProxy etc)
e.g. http://myapp.example.com reverse proxies to http://localhost:4200
Browse to http://myapp.example.com
Resulting page displays:
Invalid Host Header
The log given by the failure.
No error log is produced
Desired functionality.
I would like to see a command-line option that specifies a list of allowed HOST: header values.
Mention any other details that might be useful.
It is possible to work around this problem by editing the hosts file on your OS so that myapp.example.com points to an IP address that the server is listening on. This way, the 'expected' HOST: header is correct and ng serve is listening on the correct IP address.
However this is not an ideal solution as it requires editing the system-wide hosts file. This may not always be possible or desirable. It is common to allow for different HOST: headers to be used in server applications (e.g. Apache, Nginx etc) for virtual hosting.
I understand that ng serve is not meant for production purposes, so virtual hosting does not need to be a consideration, but sometimes developers also need to use a reverse proxy when working remotely rather than on their local machine (e.g. local machine is Windows and you don't want to run node locally).
After researching this issue more, I found that --host 0.0.0.0 was a common solution to this problem but no longer works due to a regression introduced in 1.0.1. due to stricter host name checking in WebPack. I see other issues related to it ( #6070 ), but they talk about disabling host checking (bad) or configuring public hosts (Using --public in webpack-dev-server or --piblic-host in angular-cli v1.1.0.beta.1 or newer.)
I tried installing Angular-cli 1.1.0-rc.0 and using --public-host http://public.host.com and --host 0.0.0.0 or --host <local IP Addr> but it still returns the Invalid Host header error when I browse to http://public.host.com
In one of the many threads I have read on this in the last few days, someone mentioned that Django has a configuration to allow multiple hosts and indeed it does. But it's done as a part of the configuration of the app by definign an array of allowed hosts. Can something like this be done?
Activity
Tommyf commentedon May 17, 2017
So I was looking around more. There is a veritable spiders web of issues pertaining to problems since the host checking was implemented in webpack-dev-server.
And I just noticed this webpack/webpack-dev-server#899 which allows for passing in a list of allowed hosts in webpack-dev-server.
Can angular-cli somehow implement a similar list of allowed hosts and pass this on to webpack?
lighter commentedon May 17, 2017
I have same problem.
ryanper commentedon May 17, 2017
I have a similar issue, I am also using service workers so using ng serve with ssl so will need to check how this will work. I am no expert but happy to look at this with some guidance.
Tommyf commentedon May 17, 2017
I too am happy to work on this (with guidance).
ryanper commentedon May 17, 2017
Looks like some work has already been done on this in v1.1.0-beta.1, will install and try this out.
Yep, this seems to work for me though using it with ssl may be an issue, or related to something else.
Tommyf commentedon May 17, 2017
I mentioned using v1.1.0-rc.0 which includes that commit.
What I am asking for is different. In that commit, one needs to
--disable-host-checkwhich is bad as it just circumvents the security measures that were put in place in webpack-dev-server.Also in that commit is the
--public-hostoption. Although this is tecnically an 'allowed host' it's not as flexible as having a configuration setting with an array of allowed hosts. There are multiple use cases where only allowing a single 'public' host may not be sufficient, for example, branding based on URL, or needing to used different reverse proxies for different locations.As an aside, the
--public-hostwas not working for me in v1.1.0.rc.0. I still need to use my hosts file or use--disable-host-check. I will double check though.clydin commentedon May 18, 2017
The
--public-hostoption expects a hostname. The use of a URL was most likely the cause of the issue observed.Until
webpack-dev-serveradds support for configuring multiple hosts, there's not much that can done on that front, unfortunately.Realistically,
ng serveis meant to be a basic development server. If a development setup requires a more exotic configuration, a custom server used in combination withng build --watchmay be more appropriate.Also, there's nothing inherently bad about
--disable-host-check. It's a tool that can be quite useful if used appropriately. Regardless of the use of the option,ng serveis not intended to be publicly accessible.Tommyf commentedon May 18, 2017
If I use a hostname instead of a URL for
--public-host, I get the following error:'live-reload-client' must be a full URL.I agree that this cannot be done until the multiple hosts is added to a
webpack-dev-serverrelease. It looks like it's being added in webpack/webpack-dev-server#899 , but i'm not sure if/when that will be released.Can this be revisited once the above is indeed released in
webpack-dev-server?ryanper commentedon May 18, 2017
Opps sorry @Tommyf you did mention v1.1.0-rc.0 my bad.
With regard to the full url, these combination of parameters worked for me
a) "ng serve --host host-ip-address --public-host http://host-ip-address" ( had to add http:// )
b) "ng serve --host 0.0.0.0 --disable-host-check",
I am happy with the --disable-host-check flag for local development, but I can appreciate the need to secure it in larger development teams where a proper web server would most likely be used as clydin suggested.
Tommyf commentedon May 18, 2017
@ryanper in that example, you have the same IP address used for --host and --public-host? If that's the case, then this is not the scenario I am talking about.
The scenario I am talking about is this:
ng serve --host local-ip-address --public-host http://public-ip-address-or-dnsWhere
local-ip-addressis on a private network and not accessibly directly from the web and you have a reverse proxy that maps the public ip to the local one. In the above instance, you only getInvalid Host headerunless you add--disable-host-checkalso.In this scenario, running the following
ng serve --host 0.0.0.0 --disable-host-checkwill load the page, but the websocket for live updates will not connect as it tries to use
http://localhost:4200which is obviously not accessible from the net :)mikkoh85 commentedon May 18, 2017
Can you tell me what is this about?
When I run
ng serve --host 0.0.0.0 --disable-host-checkThe option '--disable-host-check' is not registered with the serve command. Run `ng serve --help` for a list of supported options.appears. And it gives that sameInvalid Host header. I tried to update package.json from 4.1.1 everything to 4.1.2 and hitnpm iand the same "is not registered" comes just like before.I have these installed globally:
clydin commentedon May 18, 2017
@Tommyf the scenario you're describing is really not recommended. 'ng serve' is not a production ready or security hardened server; and is not intended to be.
The settings being discussed are intended to enable the creation of internal production representative development environments. Docker is quite popular for this.
@mikkoh85 the option will be available in version 1.1 of the CLI. A release candidate is available currently.
8 remaining items
JSMike commentedon Jul 28, 2017
this already exists: #6173
This issue should be closed.
haydenk commentedon Aug 1, 2017
I can see how this would be useful in development...
but I hope you're not running ng serve in production.
glebmachine commentedon Aug 1, 2017
briansanchez commentedon Aug 29, 2017
this works like a charm:
ng serve --host 207.68.230.134 --disable-host-checkDisable the 'host' header check
andela-andrewmakenzi commentedon Nov 2, 2017
There are two ways of doing this :
disableHostCheck=trueto devServer settings in the webpack.config.js file then run ng s to serve that app, hostChecking will be disabled ORng serve --host 0.0.0.0 -port 4200 --disable-host-checkIt is important to note that if you disable host checking, your server is susceptible to DNS rebinding attacks, which might not matter depending on what you are trying to do.
haydenk commentedon Jan 7, 2018
Why is this doing a host check at all? Wouldn't, nay shouldn't, this only be used during local development of the web application?
glebmachine commentedon Jan 7, 2018
dineshmaths1 commentedon Sep 17, 2018
Am using Angular CLI: 6.2.2 , Node: 8.11.1 and OS: darwin x64 This is my etc hosts 127.0.0.1 dinesh.mysocialapi.com
This is my comment node_modules/@angular/cli/bin/ng serve --host 0.0.0.0 --disableHostCheck true
am getting this error how to fix ? Loading failed for the with source “http://dinesh.mysocialapi.com/vendor.js”. dinesh.mysocialapi.com:34
leventguney commentedon Jan 27, 2019
I have edited the serve block under architect block in angular.json file to define publicHost property and it works. I can use ng serve directly and it works with my host name without complaining invalid host header
"serve": {
"builder": "@angular-devkit/build-angular:dev-server",
"options": {
"browserTarget": "my-app:build",
"publicHost":"myapp.com"
},
"configurations": {
"production": {
"browserTarget": "my-app:build:production"
}
}
},
clydin commentedon Sep 6, 2019
Please note that a DNS Rebinding attack allows a malicious website to access resources within the local network including localhost. So it is not a matter of trusting localhost but rather trusting every website visited from the computer.
angular-automatic-lock-bot commentedon Oct 10, 2019
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.