Add 'allowedHosts' option

[orteth01]

What kind of change does this PR introduce?
feature/bugfix

Did you add or update the examples/?
no

Summary
Host checking was added by default in v2.4.3 for security reasons. Users now have to specify the host/URL being used to access the dev-server more info here

This PR allows users to specify multiple hosts that that will pass the check. Recommended by @edmorley here: #882 (comment)

Does this PR introduce a breaking change?
no

Example usage in webpack config:

devServer: {
    allowedHosts: [
        'exampleHost.com',
        'differentExampleHost.com',
        ...
    ]
}

subdomain wildcard:

mimicking django's ALLOWED_HOSTS, a value beginning with "." can be used as a subdomain wildcard. '.example.com' will match example.com, www.example.com, and any other subdomain of example.com.

devServer: {
    allowedHosts: [
        '.example.com'
    ]
}

[codecov]

Codecov Report

Merging #899 into master will increase coverage by 0.93%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #899      +/-   ##
==========================================
+ Coverage    71.3%   72.23%   +0.93%     
==========================================
  Files           4        4              
  Lines         453      461       +8     
  Branches      133      138       +5     
==========================================
+ Hits          323      333      +10     
+ Misses        130      128       -2

Impacted Files	Coverage Δ
lib/Server.js	79.69% <100%> (+0.51%)	⬆️
lib/OptionsValidationError.js	60.86% <0%> (+1.73%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1a26ab4...0085961. Read the comment docs.

[mgol]

Django docs say:

A value beginning with a period can be used as a subdomain wildcard: '.example.com' will match example.com, www.example.com, and any other subdomain of example.com.

Could this be added as well?

[orteth01]

@mgol I didn't realize that there were already a few tests for Server.prototype.checkHost
https://github.com/webpack/webpack-dev-server/blob/master/test/Validation.test.js#L65-L118

I can either add tests for allowedHosts there or I can remove those tests because the tests that I added cover those cases. Which do you prefer?

[mgol]

@orteth01 I guess it makes sense to nest that under existing tests (a separate inner describe sounds good).

Note, though, that I'm just a user, not a member of Webpack's core team so you might want to wait for someone on the team to decide. I'm just providing my own feedback.

[orteth01]

I guess it makes sense to nest that under existing tests (a separate inner describe sounds good).

Yea that makes more sense, I think. I've gone with that option. thanks, @mgol

[orteth01]

There seem to be a few open issues that this PR would remedy. Any thoughts, @SpaceK33z ??

[ssilve1989]

What's the status on this?

[orteth01]

What's the status on this?

@ssilve1989 waiting on review from one of Webpack's core team members

[prencher]

@SpaceK33z @sokra I hate to be that guy, but this is preventing us from moving to a more secure setup -- The entire point of the change that prompted this PR. Can we please get movement?

I am happy to assist if I can.

[Justus-Maier]

Can I put an IP address with wildcards in here too? I sometimes get new IP from DHCP and I would like to share my current work with my collegues (just open a browser). Can this be done without me registering a local private domain?

[orteth01]

Can I put an IP address with wildcards in here too?

Currently, you can add an ip address as an allowed host but not with wildcards.

Only the subdomain wildcard is supported, meaning that only the first part of your allowed host can be dynamic. In theory I guess you could have something like this

devServer: {
    allowedHosts: [
        '.123.123'
    ]
}

which would allow any IP's that take the form *.*.123.123. However, I think that would not be recommended

[mgol]

@orteth01 For IPs I'd expect a wildcard going in a different direction, e.g. 192.168..

[orteth01]

For IPs I'd expect a wildcard going in a different direction, e.g. 192.168..

@mgol Would adding this wildcard be secure? I can certainly add support for a wildcard at the end of a specified host I just want to make sure that it is safe to do so.

[edmorley]

As I mentioned in some of the other threads, it should be safe to whitelist all IP-addresses-like hosts names by default, which would save people having to whitelist them manually.

[orteth01]

it should be safe to whitelist all IP-addresses-like hosts names by default

@edmorley it seems like a separate PR would be appropriate for that. I'll create an issue.

[shellscape]

@orteth01 merged the PR, as its a solid feature and has been in waiting for quite some time, but we still need example/readme updates for this. we've got a little bit of time before we release, would be great if you would be able to add that.

[orteth01]

we still need example/readme updates for this

@shellscape I'm more than happy to help with documentation! I'm assuming that I should update this readme. Are there any other places where I should add information regarding this feature?

[shellscape]

@orteth01 awesome. yes, please do update that readme. It's also suggested to create an example directory to demo the option.

[Justus-Maier]

@orteth01 please also add some documentation for the disabling flag of the allowedHosts feature:
config.devServer.disableHostCheck = true
With security warnings obviously ;D
#887

[Mario-Eis]

Can this be set via command line?

[orteth01]

Can this be set via command line?

@Mario-Eis not currently. i'll try to get a PR open by the end of the week.