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

Change default host to 0.0.0.0 in development mode #1369

Open
ibnesayeed opened this Issue Nov 30, 2017 · 10 comments

Comments

Projects
None yet
6 participants
@ibnesayeed

ibnesayeed commented Nov 30, 2017

We might want to revisit #634 to revert that decision as it is coming in the way. While I agree that "Software should be secure by default", but I am not sure how much I would buy the argument of protecting my development application from being accessed by someone in a "Coffee Shop".

In contrast, in a pair coding session, I would much prefer my colleagues in the same network (perhaps on the coffee table) to be able to access and test the app on their machines while I make changes.

Now, that more and more people are using containers (such as Docker) for their development environment (where the context of localhost is jailed inside the container, hence not accessible from the host machine), running the development server on localhost by default causes more trouble than it solves. This is against Ruby's mantras of "Optimize for programmer happiness" and "The Principle of Least Surprise". This is especially causing more issues when the documentation does not reflect the situation accurately. Due to the following line, one would assume that their application running inside a Docker container would easily be accessible from the host machine if appropriate ports are bound.

-o # set the host (default is 0.0.0.0)
@jkowens

This comment has been minimized.

Show comment
Hide comment
@jkowens

jkowens Nov 30, 2017

Member

I agree the documentation for command line option could be improved. The documentation for the :bind setting explains that the default is localhost for development and 0.0.0.0 for all other environments.

http://sinatrarb.com/configuration.html#bind---server-hostname-or-ip-address

Member

jkowens commented Nov 30, 2017

I agree the documentation for command line option could be improved. The documentation for the :bind setting explains that the default is localhost for development and 0.0.0.0 for all other environments.

http://sinatrarb.com/configuration.html#bind---server-hostname-or-ip-address

@ibnesayeed

This comment has been minimized.

Show comment
Hide comment
@ibnesayeed

ibnesayeed Nov 30, 2017

Yes, I saw the :bind documentation later, but by that time I already got enough surprises and wasted quite some time in figuring out why it won't work for me. Since, :bind is a config option that would require code change, which may not be desired when someone is using a script that would otherwise work. For me, -o flag was a better option which I can supply when running inside a container, but the documentation was not accurate there. After explicitly specifying -o 0.0.0.0, I was able to get it working, so I thought the default might have been changed later and documentation was not updated accordingly.

Correcting the documentation here to reflect the current behavior is the easy part, which I can perhaps make a PR for. However, I really wanted to encourage a discussion around changing the default behavior. Sinatra used to be one of those things that anyone with basic Ruby knowledge can just create a simple Ruby file containing the code on its landing page and execute that script to get it working without diving any further in the documentation.

require 'sinatra'
get '/frank-says' do
  'Put this in your pipe & smoke it!'
end

That element of "obviousness" is being hurt here. Especially, when use of Docker for development environment is rising day by day.

ibnesayeed commented Nov 30, 2017

Yes, I saw the :bind documentation later, but by that time I already got enough surprises and wasted quite some time in figuring out why it won't work for me. Since, :bind is a config option that would require code change, which may not be desired when someone is using a script that would otherwise work. For me, -o flag was a better option which I can supply when running inside a container, but the documentation was not accurate there. After explicitly specifying -o 0.0.0.0, I was able to get it working, so I thought the default might have been changed later and documentation was not updated accordingly.

Correcting the documentation here to reflect the current behavior is the easy part, which I can perhaps make a PR for. However, I really wanted to encourage a discussion around changing the default behavior. Sinatra used to be one of those things that anyone with basic Ruby knowledge can just create a simple Ruby file containing the code on its landing page and execute that script to get it working without diving any further in the documentation.

require 'sinatra'
get '/frank-says' do
  'Put this in your pipe & smoke it!'
end

That element of "obviousness" is being hurt here. Especially, when use of Docker for development environment is rising day by day.

@codenoid

This comment has been minimized.

Show comment
Hide comment
@codenoid

codenoid Dec 18, 2017

here

set :bind, Proc.new { development? ? 'localhost' : '0.0.0.0' }

codenoid commented Dec 18, 2017

here

set :bind, Proc.new { development? ? 'localhost' : '0.0.0.0' }

@codenoid

This comment has been minimized.

Show comment
Hide comment
@codenoid

codenoid Dec 18, 2017

we have set :bind, '0.0.0.0' too

codenoid commented Dec 18, 2017

we have set :bind, '0.0.0.0' too

@ibnesayeed

This comment has been minimized.

Show comment
Hide comment
@ibnesayeed

ibnesayeed Dec 18, 2017

I was not talking about the number of ways it can be achieved, but suggesting that the default out of the box experience can be improved.

ibnesayeed commented Dec 18, 2017

I was not talking about the number of ways it can be achieved, but suggesting that the default out of the box experience can be improved.

@benatkin

This comment has been minimized.

Show comment
Hide comment
@benatkin

benatkin Feb 6, 2018

create-react-app binds to 0.0.0.0 by default, in development mode, and I think that's a mistake. I was curious what others thought and I find that the opinions expressed in #634 match mine. It should be documented somewhere easy to find how to bind to 0.0.0.0 in development mode but I very strongly think binding to localhost should be the default. Besides, some browser features are only available with https or localhost, and the number is increasing:

Note: As with almost all new APIs, CSS Paint API is only available over HTTPS (or localhost).

benatkin commented Feb 6, 2018

create-react-app binds to 0.0.0.0 by default, in development mode, and I think that's a mistake. I was curious what others thought and I find that the opinions expressed in #634 match mine. It should be documented somewhere easy to find how to bind to 0.0.0.0 in development mode but I very strongly think binding to localhost should be the default. Besides, some browser features are only available with https or localhost, and the number is increasing:

Note: As with almost all new APIs, CSS Paint API is only available over HTTPS (or localhost).

@ibnesayeed

This comment has been minimized.

Show comment
Hide comment
@ibnesayeed

ibnesayeed Feb 6, 2018

Besides, some browser features are only available with https or localhost, and the number is increasing:

As per my understanding this has nothing to do with 0.0.0.0 vs. 'localhost' or '127.0.0.1'. A service listening on 0.0.0.0 can happily be accessed from localhost. In fact 0.0.0.0 is not a resolvable interface, so it is not used when interacting with the service.

As far as the secure-by-default argument is concerned, I don't oppose that, but putting unnecessary hyper-security in every place comes in the way of smooth user experience. This is against the Ruby's philosophy of developers' happiness. How about adding two-factor authentication by default in development mode and leaving the production mode as it is so that when someone is developing in a coffee house, no one can access their super secret product until it is released? I would perhaps be concerned about securing many other things if I have to develop while using public WiFi of a coffee house. There are many more popular apps and frameworks which listen on 0.0.0.0 interface by default, create-react-app is not an exception.

ibnesayeed commented Feb 6, 2018

Besides, some browser features are only available with https or localhost, and the number is increasing:

As per my understanding this has nothing to do with 0.0.0.0 vs. 'localhost' or '127.0.0.1'. A service listening on 0.0.0.0 can happily be accessed from localhost. In fact 0.0.0.0 is not a resolvable interface, so it is not used when interacting with the service.

As far as the secure-by-default argument is concerned, I don't oppose that, but putting unnecessary hyper-security in every place comes in the way of smooth user experience. This is against the Ruby's philosophy of developers' happiness. How about adding two-factor authentication by default in development mode and leaving the production mode as it is so that when someone is developing in a coffee house, no one can access their super secret product until it is released? I would perhaps be concerned about securing many other things if I have to develop while using public WiFi of a coffee house. There are many more popular apps and frameworks which listen on 0.0.0.0 interface by default, create-react-app is not an exception.

@namusyaka namusyaka added this to the v2.0.2 milestone Feb 6, 2018

@namusyaka namusyaka modified the milestones: v2.0.2, v2.0.3, v2.0.4 Jun 5, 2018

@dentarg

This comment has been minimized.

Show comment
Hide comment
@dentarg

dentarg Aug 23, 2018

I don't think the default for development should be changed back to 0.0.0.0. If you are dealing with Docker, I think it is reasonable to know about changing the binding for your application.

If you are developing on an open Wi-Fi in a coffee shop, I think it is a big chance that you don't know about the risks with it, so I agree with the opinion that Sinatra should pick the secure option for its default.

dentarg commented Aug 23, 2018

I don't think the default for development should be changed back to 0.0.0.0. If you are dealing with Docker, I think it is reasonable to know about changing the binding for your application.

If you are developing on an open Wi-Fi in a coffee shop, I think it is a big chance that you don't know about the risks with it, so I agree with the opinion that Sinatra should pick the secure option for its default.

@codenoid

This comment has been minimized.

Show comment
Hide comment
@codenoid

codenoid Aug 23, 2018

yeah, the "development" mode should be use "localhost"

codenoid commented Aug 23, 2018

yeah, the "development" mode should be use "localhost"

@ibnesayeed

This comment has been minimized.

Show comment
Hide comment
@ibnesayeed

ibnesayeed Aug 23, 2018

If you are dealing with Docker, I think it is reasonable to know about changing the binding for your application.

Agreed on this part. In my case, I was well aware of it as I consider myself a Docker expert, but the documentation of Sinatra was inaccurate, so I wasted a lot of time when I filed this ticket.

If you are developing on an open Wi-Fi in a coffee shop, I think it is a big chance that you don't know about the risks with it, so I agree with the opinion that Sinatra should pick the secure option for its default.

I really want to understand the risks involved. Rather than just tossing opinions back and forth and mentioning big terms like security and risks (which can be very much real), let's asses potential risks and see if those are significant enough to bear the cost of inconvenience and unexpected surprises?

ibnesayeed commented Aug 23, 2018

If you are dealing with Docker, I think it is reasonable to know about changing the binding for your application.

Agreed on this part. In my case, I was well aware of it as I consider myself a Docker expert, but the documentation of Sinatra was inaccurate, so I wasted a lot of time when I filed this ticket.

If you are developing on an open Wi-Fi in a coffee shop, I think it is a big chance that you don't know about the risks with it, so I agree with the opinion that Sinatra should pick the secure option for its default.

I really want to understand the risks involved. Rather than just tossing opinions back and forth and mentioning big terms like security and risks (which can be very much real), let's asses potential risks and see if those are significant enough to bear the cost of inconvenience and unexpected surprises?

@namusyaka namusyaka modified the milestones: v2.0.4, v2.0.5 Sep 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment