loco-rs / loco

🚂 🦀 The one-person framework for Rust for side-projects and startups
https://loco.rs
Apache License 2.0
3.88k stars 166 forks source link

0.0.0.0 not working to expose ports #704

Open BWStearns opened 1 month ago

BWStearns commented 1 month ago

Description

I need to expose a webapp to the local network. The non-local device cannot see the webservice. I started a new project using 0.7.0 and modified the development.yaml file like below.

# development.yaml
# Web server configuration
server:
  # Port on which the server will listen. the server binding is 0.0.0.0:{PORT}
  port: 5150
  # The UI hostname or IP address that mailers will point to.
  host: http://0.0.0.0

(I also tried my machine's hostname instead of 0.0.0.0).

My second device cannot access the server via the hostname of the server or the local ip address.

The start logging makes me think it might be ignoring the 0.0.0.0 host input in favor of just localhost?

                https://loco.rs

environment: development
     logger: debug
compilation: debug
      modes: server

listening on localhost:5150

Edit:

A node application started on 0.0.0.0 is accessible from the second device so I have confirmed that the second device can access services on the host machine.

BWStearns commented 1 month ago

Ah. Starting it with cargo loco start -b 0.0.0.0 did the trick. I had assumed that host would act as the bind argument in the absence of an argument. Not sure if this is actually a bug or a misunderstanding.

trevoranderson commented 4 weeks ago

It's a little confusing but you can set it in the development.yaml under the server's binding key I believe, as well.

BWStearns commented 4 weeks ago

Ah yeah, good call. For anyone stumbling across this you can see it in use here

jondot commented 4 weeks ago

Let me try to explain the original intention of these fields:

host: - for "visibility" use cases or out-of-band use cases. For example, some times you want to display the current server host (in terms of domain name, etc.), which serves for visibility. And some times, as in the case of emails -- your server address is "out of band", meaning when I open my gmail account and I have your email -- I have to click what looks like your external address or visible address (official domain name, etc), and not an internal "host" address which is what may be the wrong thing to do (imagine an email link pointing to "http://127.0.0.1/account/verify")

port: as the name says, for changing ports, mostly when behind a load balancer, etc.

binding: for changing what the IP interface "binds" to, mostly, you want to be behind a load balancer like ngnix, so you bind to a local address (when the LB is also there). However you can also bind to "world". You can set the binding: field via config, or via the CLI -- which is what Rails is encouraging to do.

If it's still confusing -- I'll be happy to clear any confusion because we'd like this to be straight forward for operators of a service. Please do let me know.

BWStearns commented 4 weeks ago

I won't have time for a few weeks but once I get a minute I'll try to update the defaults/docs to reflect common cases.