Adaptors should listen only on WOHost when it's set, as WO does #98

Summary

When WOHost is set, the adaptors should listen only on that address, as WO does. Today they always listen on every interface.

What WO does

WOClassicAdaptor resolves WOHost and, when it's set, listens only on that address (new ServerSocket( port, backlog, host )). When it isn't set, it listens on all interfaces. wotaskd passes -WOHost to every instance it launches, so a WO app under wotaskd listens only where its deployment says. With -WOHost localhost, the instance can only be reached through the local web server.

What ng does

Neither adaptor calls connector.setHost(...), so both listen on every interface whatever WOHost says:

• NGAdaptorJetty.start() (ng-adaptor-jetty)
• NGAdaptorJettyServlet (ng-adaptor-jetty-servlet)

An ng app launched by the same wotaskd, with the same arguments, is reachable directly on all of the machine's addresses unless a firewall stops it. That matters for anything that relies on the app being reachable only from where it's meant to be: the instance-request endpoint (NGWOAccessGuard) and the dev endpoints (#83).

Proposed

• WOHost set: connector.setHost( WOHost ), so the adaptor listens only on that address.
• WOHost not set: listen on all interfaces, as now and as in WO.

WOHost is currently read only by NGWOIntegrationPlugin (for lifebeats, falling back to the machine's host name since #93). The adaptors would be its second reader. The lifebeat's fallback doesn't apply to listening: an unset WOHost means "all interfaces", not "the machine's name".

Release notes

Behaviour change for anyone who sets WOHost, which in practice means wotaskd deployments: the app stops answering on addresses other than WOHost.

Related

• undur/wo-adaptor-jetty has the same gap (FIXME: WOHost? at WOAdaptorJetty.java:249), to be fixed there.
• Proper wotaskd integration: complete WOMPRequestHandler and align with the WO admin protocol #55 (proper wotaskd integration), Found while documenting: dev endpoints terminate, log and problems aren't loopback-restricted #83 (dev endpoints not loopback-restricted).