Skip to content

feat: add CAMOFOX_NET_INTERFACE to bind server to specific network interface#8071

Closed
aadamowski wants to merge 2 commits into
jo-inc:masterfrom
aadamowski:master
Closed

feat: add CAMOFOX_NET_INTERFACE to bind server to specific network interface#8071
aadamowski wants to merge 2 commits into
jo-inc:masterfrom
aadamowski:master

Conversation

@aadamowski

Copy link
Copy Markdown

This adds a new environment variable CAMOFOX_NET_INTERFACE that allows configuring which network interface the server should listen on.

By default, it listens on all interfaces (empty string), but can be configured to listen only on loopback (127.0.0.1) for improved security.

Fixes security issue where server was always listening on all network interfaces, which could expose the service to unauthorized access from other machines on the same network.

Usage:

  CAMOFOX_NET_INTERFACE=127.0.0.1 npm start  # Loopback only (secure)

  CAMOFOX_NET_INTERFACE=0.0.0.0 npm start    # All interfaces (explicit)

  npm start                                  # All interfaces (default)

Testing:

  • Unit tests: npm test -- tests/unit/config.test.js tests/unit/serverBinding.test.js
  • Added 6 new tests covering configuration parsing and server binding behavior
  • Integration tests verify actual Express server binds to correct interfaces
  • Functional testing performed with these exact commands:
    • Launch loopback: CAMOFOX_PORT=9380 CAMOFOX_NET_INTERFACE=127.0.0.1 npm start
    • Verify binding: ss -tlpn 'sport = 9380' # Shows 127.0.0.1:9380
    • Test access: curl -s http://127.0.0.1:9380/health
    • Launch default: CAMOFOX_PORT=9381 npm start
    • Verify binding: ss -tlpn 'sport = 9381' # Shows *:9381
    • Test access: curl -s http://127.0.0.1:9381/health

All tests pass, backward compatibility preserved.

Aleksander Adamowski added 2 commits July 16, 2026 22:59
…terface

This adds a new environment variable CAMOFOX_NET_INTERFACE that allows
configuring which network interface the server should listen on.

By default, it listens on all interfaces (empty string), but can be
configured to listen only on loopback (127.0.0.1) for improved security.

Fixes security issue where server was always listening on all network
interfaces, which could expose the service to unauthorized access from
other machines on the same network.

Usage:
  CAMOFOX_NET_INTERFACE=127.0.0.1 npm start  # Loopback only (secure)
  CAMOFOX_NET_INTERFACE=0.0.0.0 npm start  # All interfaces (explicit)
  npm start                                  # All interfaces (default)

Testing:
- Unit tests: npm test -- tests/unit/config.test.js tests/unit/serverBinding.test.js
- Added 6 new tests covering configuration parsing and server binding behavior
- Integration tests verify actual Express server binds to correct interfaces
- Functional testing performed with these exact commands:
  * Launch loopback: CAMOFOX_PORT=9380 CAMOFOX_NET_INTERFACE=127.0.0.1 npm start
  * Verify binding: ss -tlpn 'sport = 9380'  # Shows 127.0.0.1:9380
  * Test access: curl -s http://127.0.0.1:9380/health
  * Launch default: CAMOFOX_PORT=9381 npm start
  * Verify binding: ss -tlpn 'sport = 9381'  # Shows *:9381
  * Test access: curl -s http://127.0.0.1:9381/health

All tests pass, backward compatibility preserved.
The server started log message now includes the host/interface that the
server is bound to, which is especially useful when using the new
CAMOFOX_NET_INTERFACE configuration.

Before: host field was missing from log output
After: host field shows the actual bound interface (127.0.0.1 or 0.0.0.0)

This makes it easier to verify that the server is bound to the expected
network interface without needing to use external tools.

Also updates the server:started event to include host information for
plugins that may need it.
@skyfallsin

Copy link
Copy Markdown
Contributor

Thank you — this is now superseded by merged #8096. Current master supports configurable binding via CAMOFOX_BIND_HOST, forwards it through launched server subprocesses, documents the setting, and includes the effective listener address in startup logs and the server:started event. We kept the existing all-interface default for container compatibility.

@skyfallsin skyfallsin closed this Jul 20, 2026
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 this pull request may close these issues.

2 participants