Post-release verification note for #995 (shipped in v2.3.2)
#995 admits private-address clients to owner pairing while api.lan_auth is off, reading r.RemoteAddr. Verified sound for the fleet: the Linux compose (and the RPi image) run network_mode: host, so RemoteAddr is the genuine client address, and netip classification is correct incl. IPv4-mapped IPv6 (empirically checked: ::ffff:203.0.113.9 → not private, CGNAT excluded).
The macOS compose is the exception: it publishes the port on a bridge network, so the container sees Docker Desktop's gateway (a private address) as the source for every client. On that topology the gate cannot tell LAN from WAN — anyone who can reach the Mac's :8080 (e.g. through a router port-forward) passes the private-address check.
Narrow exposure: macOS is the development topology, and it takes a deliberate port-forward to expose :8080 beyond the LAN. The #950 error message already treats Docker Desktop networking as special ("a published Docker port is not loopback").
Suggested fix
An explicit switch, e.g. app_link.lan_owner_pairing: false, so a NAT-ed deployment can restore the strict gate without turning on the house password; plus a warning comment in docker-compose.macos.yml. Auto-detecting NAT from inside the container is not reliable enough to gate a credential on.
🤖 Generated with Claude Code
Post-release verification note for #995 (shipped in v2.3.2)
#995 admits private-address clients to owner pairing while
api.lan_authis off, readingr.RemoteAddr. Verified sound for the fleet: the Linux compose (and the RPi image) runnetwork_mode: host, so RemoteAddr is the genuine client address, andnetipclassification is correct incl. IPv4-mapped IPv6 (empirically checked:::ffff:203.0.113.9→ not private, CGNAT excluded).The macOS compose is the exception: it publishes the port on a bridge network, so the container sees Docker Desktop's gateway (a private address) as the source for every client. On that topology the gate cannot tell LAN from WAN — anyone who can reach the Mac's :8080 (e.g. through a router port-forward) passes the private-address check.
Narrow exposure: macOS is the development topology, and it takes a deliberate port-forward to expose :8080 beyond the LAN. The #950 error message already treats Docker Desktop networking as special ("a published Docker port is not loopback").
Suggested fix
An explicit switch, e.g.
app_link.lan_owner_pairing: false, so a NAT-ed deployment can restore the strict gate without turning on the house password; plus a warning comment indocker-compose.macos.yml. Auto-detecting NAT from inside the container is not reliable enough to gate a credential on.🤖 Generated with Claude Code