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

127.0.0.1 by default vs 0.0.0.0 #440

Closed
nol166 opened this issue Apr 5, 2019 · 9 comments · Fixed by #857
Closed

127.0.0.1 by default vs 0.0.0.0 #440

nol166 opened this issue Apr 5, 2019 · 9 comments · Fixed by #857

Comments

@nol166
Copy link
Contributor

nol166 commented Apr 5, 2019

  • code-server version: v1.604-vsc1.32.0
  • OS Version: macOS 10.14.4 (18E226)

Description

It has been discussed that using 127.0.0.1 might be better than using 0.0.0.0 for the default host for security reasons when running code-server. A user should have to explicitly set 0.0.0.0 as the host if they want to use it with the -h flag

Steps to Reproduce

  1. Start code server INFO Starting webserver... {"host":"0.0.0.0","port":8443}
@MichaelDesantis
Copy link
Contributor

@nol166 is there any record of this discussion that you can link to this issue?

@nol166
Copy link
Contributor Author

nol166 commented Apr 5, 2019

@nhooyr Discussed it this morning and asked me to make this issue

https://superuser.com/questions/949428/whats-the-difference-between-127-0-0-1-and-0-0-0-0

@coadler
Copy link
Member

coadler commented Apr 5, 2019

I think the overwhelming use case of code-server would be to access it over the internet, not from the same machine. If this is a security issue why not just remove the --no-auth flag from the docker one-liner?

@coadler
Copy link
Member

coadler commented Apr 5, 2019

I think a better solution would be to just add a warning. Changing the default behavior would most likely break a lot of scripts/deployments

@nol166
Copy link
Contributor Author

nol166 commented Apr 5, 2019

@coadler That might be a better solution if it will screw up deployments. Thoughts @nhooyr?

@nhooyr
Copy link
Contributor

nhooyr commented Apr 5, 2019

Yea I agree it would be a bad idea to change the behaviour. I guess what we really want is to listen on localhost if the --no-auth or --allow-http flags are passed as at that point listening on 0.0.0.0 is potentially insecure.

@coadler
Copy link
Member

coadler commented Apr 5, 2019

That seems sensible to me. I could see this affecting people behind reverse proxies that handle auth/tls upstream though, so we should be sure to document the change on the next release

@nol166
Copy link
Contributor Author

nol166 commented Apr 5, 2019

updated the pr

@MichaelDesantis
Copy link
Contributor

PR is here for people from the future following this thread #441

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants