Default host to localhost when in development mode. #514

Merged
merged 5 commits into from Apr 22, 2013

4 participants

@postmodern

Running Rack apps on 0.0.0.0 in development mode will allow malicious users on the local network (ex: a Coffee Shop or a Conference) to abuse or potentially exploit the app. Safer to default host to localhost when in development mode.

Also default the :Host option to localhost, when in development, in Rack::Handler::WEBrick, Rack::Handler::Mongrel, Rack::Handler::Thin.

postmodern added some commits Feb 9, 2013
@postmodern postmodern Default host to localhost when in development mode.
* Running Rack apps on 0.0.0.0 in development mode will allow malicious
  users on the local network (ex: a Coffee Shop or a Conference) to abuse
  or potentially exploit the app. Safer to default host to localhost when in
  development mode.
28b0144
@postmodern postmodern Rack::Handler::WEBrick: default the host to localhost in development …
…mode.
5a9169d
@postmodern postmodern Rack::Handler::Mongrel: default the host to localhost in development …
…mode.
5d2edd8
@postmodern postmodern Rack::Handler::Thin: default the host to localhost in development mode. 8377df0
@raggi
Official Rack repositories member

Using a hostname can cause issues on some systems where servers don't properly support ipv6. Should we prefer 127.0.0.1?

@postmodern

Using 127.0.0.1 would assume the system supports IPv4. Better to use localhost and let /etc/hosts map it to the correct address/interface.

@cypher

Either way, right now the valid_options returns incorrect documentation for the default host value where applicable (it says localhost right now, at least for Thin and Mongrel). So if this pull request is rejected, that method should be updated to use the correct default host.

@raggi Would it avoid the issues you mentioned if we use Socket.ip_address_list to detect the IP for localhost?

@postmodern

Fixed valid_options. I noticed there is some repetition among the valid_options methods. Perhaps they could be extracted to a common Handler class/module?

@brynary

Wouldn't a better default be localhost in production too? For example, in the common configuration of Ruby behind Nginx on an EC2 server. 0.0.0.0 seems better as an opt-in behavior.

@postmodern

@brynary Good idea. I don't know how that might affect Phusion Passenger or Heroku (they default to using WEBrick). In the past, I would configure Thin to explicitly listen on localhost:9000.

@brynary
@raggi raggi merged commit 15796c4 into rack:master Apr 22, 2013

1 check passed

Details default The Travis build passed
@raggi
Official Rack repositories member

Thanks

@p8952 p8952 added a commit to p8952/rack that referenced this pull request Jan 6, 2015
@p8952 p8952 Update to reflect changes in #514 076711a
@lucasfais lucasfais referenced this pull request in azukiapp/azk Jan 8, 2015
Closed

Improve generator for ruby apps using rack gem #218

@tenderlove tenderlove added a commit that referenced this pull request Feb 19, 2015
@p8952 p8952 Update to reflect changes in #514 374b315
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment