Ionic serve and live reload need security (expose all code to anyone on same network).

[sachingarg05]

Ionic serve and live reload need security, currently it exposes all code to anyone on same network. Its very helpful to be able to bind to external IP and open the URL on a bunch of ios and android devices and different browsers and have all of them refresh automatically with every code change. But this also opens it up to everyone else on the network.

It needs multiple sub-features, but the simplest and easiest to add should be this:

• Add basic http auth support. Developer will need to type in the a username/password only once when it run it for the first time. And it will allow them to allow access to others if they want to, change credentials in command-line parameters, etc... (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization)

These can be optionally added later:

• Add https support, even if with just a self-signed certificate. Will secure against network sniffers, and as a side-effect also allow testing for https compatibility of actual app.
• Maybe add a url parameter ?token=aaaaaa with a random token to allow both security and easy sharing. I have seen some tools do this, but personally I would prefer http basic auth + https.

[imhoffd]

This is a feature request, because the intended use case for ionic serve and livereload is on home/office networks.

Basic Auth would be quite a shock to anyone using ionic serve, as it would pop-up a username/password combo instead of just seeing a working app. I'd like to explore the second two ideas more.

HTTPS in ionic serve is already a request here: https://github.com/ionic-team/ionic-cli/issues/2671 I need to explore it a bit more, because self-signed certificates are still rejected, even on localhost, which would require some annoying configuration, getting in the way of just seeing the working app.

A token might be a fun idea. We'd need to check the request query params before serving a response. We'd need to validate the session from then on as to not screw with the angular router.

[sachingarg05]

It is more critical than a "CLI Future" feature. Even in small office networks, everyone can't have access to other's code. Think of a consultancy or agency environment with multiple ongoing projects for different clients. No one except the developers working on one client's projects should be able to access the code. "ionic serve" running on every dev box all day makes it an extremly easy target.

My preference is for http auth as it seems easiest to implement and will mostly stay out of the way - only need to enter credentials once in a session, and dev can choose to have them saved by the browser for future sessions.

To keep the first run experience as seemless as it is right now, it can be kept 'off' by default with a command line parameter to turn it on. Maybe with a console message to inform users about the secure options - be it auth, token or https.

[imhoffd]

FWIW ionic serve --address=localhost binds to localhost, not 0.0.0.0 (which is the documented default). I added a sentence in the help page for serve about that.

Also, I was playing around with basic auth in ionic serve and actually really liked the result. I made a (hidden) --auth flag to send in the auth password, then the dev logs in with ionic as user name and that password.

Unfortunately right now it only works for Ionic 1. (app-scripts runs its own server so I'd have to go in and duplicate code). Would you like to test?

npm i -g ionic@canary ionic serve --auth="my password"

[imhoffd]

BTW there's now a --local flag which is easier than --address=localhost.

@sachingarg05 @Tiberriver256 I took this out for CLI 4 because I refactored a lot, so it would need to be re-implemented. Also, for v4 projects we're not at all in control of the dev server as the Ionic CLI uses the Angular CLI in v4. So we'd need to figure something out for that as well...

[imhoffd]

for clarification: CLI 4 isn't out yet. It's in RC.

[sachingarg05]

Goal is not to safeguard by not using external network, but to be able to use external network to test on multiple devices etc... - without having all the code accessible by everybody on the network.

If ionic cli is now going to use angular cli for some of the work, I think the ionic cli now only needs to make sure it does not hide or block any of the features that angular cli provides. Angular's cli itself seems to be using webpack's cli for serving, so overall its all good.

I can see that angular's cli supports https using --ssl. Does this mean ionic v4 cli will also support https? https://github.com/angular/angular-cli/wiki/serve

[imhoffd]

Yeah, we don't hide/block features, but when multiple commands are wrapped, such as ionic cordova run <platform> -l (which runs the Angular CLI and Cordova CLI at the same time), it becomes difficult to redirect which options go where.

I have an issue for HTTPS support in CLI v4: https://github.com/ionic-team/ionic-cli/issues/3305